SQL Server query’s op secondaries zijn langzaam

Tijdens één van mijn leertrajecten op SQL Server onderzocht ik het gedrag van query’s op READ ONLY secondaries binnen Always-On clusters. Wat opviel was dat query’s op deze database langzamer draaiden; dus, dezelfde query draait op de primary sneller. Nu gebruik ik in het dagelijks werkleven meer secondary logshipomgevingen, waardoor mijn werk niet direct wordt geraakt, maar als SQL Server Enthousiast werd mijn interesse behoorlijk geprikkeld.

Bij mijn zoektocht op internet, kwam ik gelukkig weer bij Microsoft uit. Dit artikel verklaarde precies de exacte oorzaak van mijn testsituatie.

Hoe zie ik dat het fout gaat?

  • De query voert een index scan uit op een groot gedeelte van een tabel, die een clustered row-store index hebben.
  • De query maakt gebruik van de NOLOCK query hintDe dynamic management view sys.dm_db_index_physical_stats laat een significante fragmentatie van de index zien
  • Loskoppelen van de secondary uit het Always-On Cluster lost de performance kwestie op

Hoe zit dit nu? Wat is de oorzaak?
Op secondary databases binnen een always-on cluster wordt snapshot isolation bij query’s afgewdongen. De optie NOLOCK wordt daarbij genegeerd. Dit zorgt ervoor dat de index scan op volgorde van de index key door SQL Server wordt uitgevoerd Als de clustered index significant gefragmenteerd is, valt SQL Server terug op het lezen van één pagina per IO request. Op de primary database (waar snapshot isolation niet wordt afgedwongen) zal SQL Server nog steeds terugvallen op het lezen van meerdere pagina’s per IO request.

De oplossing?
Om dit probleem voor te blijven, is het verstandig de clustered index van de betrokken tabellen opnieuw op te bouwen. De nieuw opgebouwde indexen zullen dan via de Always-On naar de secondaries worden overgezet, waardoor de query’s net zo snel als op de primary database worden.

De Featured Image komt van deze pagina.

ASUS TUF Gaming AX4200 verbindt niet of selectief

Er is door mij heel lang gezocht naar een oplossing van verbindingsproblemen tussen een Lenovo Tinkpad P52 en een ASUS TUF Gaming AX4200. De Lenovo Thinkpad heeft een WiFi adapter die draait onder Intel(R) Wi-Fi 6 AX200 160Mhz driver. De notebook maakt wél verbinding met andere WiFi netwerken.

Na vele opties te hebben onderzocht inclusief wijzigingen maken in de instellingen van de driver, bleek de oplossing in de router te liggen. Niet zo verwonderlijk ook, want de notebook verbinden met andere WiFi punten lukte wel. Wat werkte, was het volgende

  • Maak verbinding met de ASUS router
  • Login met de credentials van de administrator
  • Scroll aan de linkerkant in het menu naar Wireless onder Advanced
  • Scroll naar Channel bandwidth onder 5GHz (!!)
  • Vink Enable 160MHz aan
  • Scroll naar de onderkant van de pagina en klik op [Apply]

De notebook zou nu met 5GHz met de router kunnen verbinden. Let op: verbinding met 2.4GHz lukte bij mij nog steeds niet.

Afbeelding [copyright by Asus]

Windows 11 Notepad werkt niet in context menu

Stel u wenst XML documenten te openen met de nieuwe Notepad van Windows 11, maar… u krijgt deze op geen enkele manier via ‘Openen met…’ (in het Engels ‘Open with…’) in uw context menu (met rechtermuis klik). De app wordt niet gevonden en handmatig toevoegen geeft allerlei foutmeldingen. Wat voor mij werkte, was de app te herstellen (in het Engels ‘Repair’). Hoe?

  • Open Instellingen (in het Engels Settings)
  • Klik in het menu op Apps
  • Klik op Installed apps
  • Zoek de app Notepad op
  • Klik op de drie puntjes rechts naast de grootte van de app
  • Selecteer Advanced options
  • Klik op de knop Repair
Hierna zal Notepad waarschijnlijk in uw context menu beschikbaar zijn, wanneer u in verkenner ‘Openen met…’ selecteert.

Wijzig Analysis Server van Multidimensional naar Tabular Model of andersom

Jarenlang zijn multi-dimensionale kubussen de standaard geweest. Uw organisatie is er nu klaar voor om tabular models in te zetten. Daarvoor moet de analysis server worden omgezet van een multidimensional instance naar een tabular instance. Hoe werkt dat?

Microsoft beschrijft in deze link dat het omzetten van de DeploymentMode property in het bestand msmdsrv.ini niet wordt ondersteund. In principe zal Microsoft SQL Server Analysis Service opnieuw op de server moeten worden geïnstalleerd, nadat de multidimensional instance is verwijderd, maar…

Het omzetten van de DeploymentMode property in het bestand msmdsrv.ini werkt wél. Voor een test- of acceptatieomgeving of om tabular models tijdelijk te testen is het omzetten van deze eigenschap dus een prima oplossing die veel tijd scheelt. Hoe werkt het precies?

  • Ga met verkenner op de analysis server naar de folder C:\Program Files\Microsoft SQL Server\[uw versie]\OLAP\Config
  • Maak een kopie van het bestand msmdsrv.ini naar bijvoorbeeld de temp-folder
  • Open het bestand in de temp-folder
  • Zoek in het bestand naar DeploymentMode
  • Wijzig de waarde naar behoefte: 0=Multidimensional en 2=Tabular
  • Sla het bestand op
  • Maak een backup van het originele bestand in de SSAS folder
  • Kopieer vervolgens het aangepaste bestand uit de temp-folder naar de SSAS-folder toe
  • Herstart de analysis server
BELANGRIJK: Het is dus nadrukkelijk niet de bedoeling deze werkwijze op een productie-server te gebruiken. Microsoft ondersteunt deze werkwijze gewoon niet.

Fouten in SQL Server Agent taken worden niet via e-mail gestuurd

Wanneer zich fouten voordoen in SQL Agent taken, is het fijn wanneer deze via e-mail worden gedeeld. Bij u blijkt dat een uitdaging en werkt het niet.

  • De SQL Server heeft voldoende rechten om e-mail via de mail-server te kunnen sturen
  • Er is een mail account in Database Mail binnen de SQL Server aangemaakt
  • Er is een profiel voor het mail account binnen Database Mail aangemaakt
  • Een testbericht vanuit Database Mail van de SQL Server komt ook gewoon aan
… en helaas: er komen geen mailberichten van de SQL Server Agent binnen.

De eerste plaats waar u kijkt, is zonder uitzondering de logbestanden! In dit geval dus het actuele logbestand van de SQL Server Agent. De kans is vrij groot dat u in de log de volgende regel tegenkomt: [476] Database Mail is not enabled for agent notifications. Cannot send e-mail to [E-mail ontvangers].

Database Mail moet nog aan de SQL Server Agent worden gekoppeld en dat gaat als volgt:

  • Start SQL Server Management Studio
  • Maak verbinding met de betrokken SQL Server
  • Rechtermuisklik op SQL Server Agent
  • Klik op Properties
  • Klik links in het geopende venster op Alert System
  • Vink Enable mail profile aan
  • Selecteer het juiste Mail system
  • Selecteer de het juiste Mail profile
  • Klik op [OK] om de nieuwe instellingen te bevestigen
Klaar!

Foutmeldingen in transactie logshipping

Ik kom regelmatig situaties tegen waarbij logshipdatabases (=secondaries) niet meer via logshipping wordt bijgewerkt. Meestal zien we dan in de geschiedenis van de LSRestore-job in de SQL Agent van de database server waar de logshipdatabase op draait een melding die aangeeft dat transactielogs niet meer kunnen worden ingelezen omdat ze ‘out-of-sequence’ of ‘too recent’ zijn. Deze situatie wordt meestal door één van onderstaande scenario’s veroorzaakt:

  • Er is een FULL backup van de database gemaakt zonder de optie COPY_ONLY.
  • Het recovery model is aangepast. Het aanpassen van het recovery model wordt in de SQL Server gelogd als Setting database option RECOVERY to SIMPLE for database ‘[naam van de database]’ (zonder blokhaken).
  • Er heeft een RESTORE plaats gevonden waarbij de database in NonRecovery is gezet
  • Er zijn transactielogs van de brondatabase verwijderd of naar een andere locatie gekopieerd. Wanneer deze transactielogs nog ergens zijn te vinden, kan worden volstaan met het plaatsen van de transactielogs in de folder van waaruit de LSRestore-job de transactielogs inleest. Voor de veiligheid worden deze transactielogs uit de bronfolder gekopieerd en niet verplaatst.

De gebruikte query om inzicht te krijgen in uitgevoerde restore jobs is

SELECT
       rh.destination_database_name AS [Database],
       CASE
             WHEN rh.restore_type = 'D' THEN 'Database'
             WHEN rh.restore_type = 'F' THEN 'File'
             WHEN rh.restore_type = 'I' THEN 'Differential'
             WHEN rh.restore_type = 'L' THEN 'Log'
       ELSE rh.restore_type END AS [Restore Type],
       rh.restore_date AS [Restore Date],
       bmf.physical_device_name AS [Source], 
       rf.destination_phys_name AS [Restore File],
       rh.user_name AS [Restored By]
FROM msdb.dbo.restorehistory rh
INNER JOIN msdb.dbo.backupset bs ON rh.backup_set_id = bs.backup_set_id
INNER JOIN msdb.dbo.restorefile rf ON rh.restore_history_id = rf.restore_history_id
INNER JOIN msdb.dbo.backupmediafamily bmf ON bmf.media_set_id = bs.media_set_id
-- WHERE destination_database_name = '[naam van de database]' -- zonder blokhaken
ORDER BY rh.restore_date DESC
GO

De gebruikte query voor inzicht in gemaakte backups is:

SELECT
       s.database_name,
       m.physical_device_name,
       CAST(CAST(s.backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS bkSize,
       CAST(DATEDIFF(second, s.backup_start_date,
       s.backup_finish_date) AS VARCHAR(4)) + ' ' + 'Seconds' TimeTaken,
       s.backup_start_date,
       CAST(s.first_lsn AS VARCHAR(50)) AS first_lsn,
       CAST(s.last_lsn AS VARCHAR(50)) AS last_lsn,
       CASE s.[type] WHEN 'D' THEN 'Full'
       WHEN 'I' THEN 'Differential'
       WHEN 'L' THEN 'Transaction Log'
       END AS BackupType,
       s.server_name,
       s.recovery_model
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() -- Remove this line for all the database
ORDER BY backup_start_date DESC, backup_finish_date;

In de meeste gevallen dient de logshipdatabse opnieuw te worden opgebouwd. Alleen wanneer de melding ‘too recent’ zich voordoet en de transactielogs die ontbreken zijn nog beschikbaar, kan de logshipdatabase met de ontbrekende transactielogs worden hersteld.

Inzicht in active directory van een domein

Om inzicht te krijgen in de active directory structuur of AD groups van een domein binnen Windows 10 wordt het volgende gedaan:

  • Open de Windows Verkenner
  • Selecteer netwerk (in het Engels network) aan de linkerkant
  • Klik in de knoppenbalk op “Search Active Directory”

Om inzicht te krijgen in de active directory structuur of AD groups van een domein binnen Windows 11 wordt het volgende gedaan:

  • Open Windows Tools
  • Selecteer netwerk (in het Engels network) aan de linkerkant
  • Klik in de knoppenbalk op “Search Active Directory”

Vervolgens kan de AD groep worden opgezocht om te kijken welke gebruikers er in die AD groep zitten.

Nieuwe standaard security in Microsoft OLE DB for SQL Server

Microsoft trekt de security-touwtjes aan! Net als in Microsoft SQL Server Management Studio heeft de driver Microsoft OLE DB for SQL Server vanaf versie 19.0.0 nu ook ‘security-by-default’. Is dat écht nieuw? Nee, deze feature zit er al sinds 15 februari 2022 in toen Microsoft versie 19.0.0 lanceerde. Ik liep er echter deze week tijdens één van mijn installaties tegen aan.

Waar wordt Microsoft OLE DB for SQL Server gebruikt?
Multidimensionale kubusdatabases en tabular models maken gebruik van deze driver om verbinding te maken naar de brondatabase van de analysis server objecten.

Is de security-by-default dan verplicht?
Nee, wanneer in de connection string van de driver Use Encryption for Data=Optional wordt toegevoegd, zal de security worden omzeild. Een voorbeeld connection string:
Provider=MSOLEDBSQL19;Data Source=[Database server];Initial Catalog=[Database];Integrated Security=SSPI;Persist Security Info=false;Use Encryption for Data=Optional

Meer informatie
Meer informatie is beschikbaar in de volgende links (in het Engels)

De database msdb groeit uit z’n voegen!

In de msdb database worden veel processen van microsoft vastgelegd, onder andere systeembrede stored procedures en ook logging van de SQL agent en database mail. Ongemerkt groeit deze database heel snel heel hard en zit deze database in no-time op enkele tientallen gigabyte grootte. Bij goed SQL server beheer hoort dat niet. Die groei moet in de perken worden gehouden.

Waardoor groeit msdb
De groei van de msdb database kent vele oorzaken. De oorzaken die de meeste groei veroorzaken zijn:

  • De historie van SQL agent jobs
  • De logs van database mail
  • De logs van backups
  • De logs van logshipping procedures

Wat kunnen we eraan doen?
Wanneer u nog geen onderhoud op de msdb database heeft gepleegd, is het handig om eerst de volgende punten vast te stellen:

  • Hoe groot is de msdb database nu?
  • Hoeveel van die ruimte is er al vrij?
  • Hoe groot is msdb database op de storage?
  • Wat zijn mijn grootste tabellen in de database?

Het vast stellen van de bovenstaande punten kan het makkelijkst via SQL Server Management Studio. Door met de rechtermuis klik op de msdb database te klikken, kan er voor Reports worden gekozen. De relevante rapporten zijn Disk Usage en Disk Usage by Table. Dit geeft een goed beeld van de database. Wanneer de database groter dan 5GB is, wijst dat al op excessieve historische logging. Per tabel kan vervolgens worden gekeken hoeveel records er in de tabel zitten en hoeveel ruimte die tabel in neemt. Met onderstaande query kan bijvoorbeeld worden gekeken hoeveel stappen er per SQL agent job zijn gedraaid in het verleden.

SELECT
	sj.name			AS [SQL Server Agent job],
	count(sjh.step_name)	AS [Aantal stappen in de historie]
FROM dbo.sysjobhistory sjh WITH (NOLOCK)
JOIN dbo.sysjobs sj ON sjh.job_id = sj.job_id
GROUP BY sj.name
ORDER BY sj.name;
[/code>]

<strong>Opschonen historische SQL agent jobs</strong>
Voor het opschonen van historische SQL agent jobs wordt de stored procedure <em>sp_purge_jobhistory</em> gebruikt. Deze stored procedure kan de hele historie van één job opruimen of de historie van alle jobs tot en met een bepaalde datum; of een combinatie hiervan. Globaal kan daar onderstaande query voor worden gebruikt
[code language="sql"]
DECLARE @Peildatum datetime = (SELECT DATEADD(MONTH,-1,GETDATE()))
EXECUTE [msdb].[dbo].[sp_purge_jobhistory]
--	@job_name = 'LSRestore_CS-DT1712014_HiX62_Support',
	@oldest_date = @Peildatum

Opschonen database mail
Voor het opschonen van database mail worden de stored procedures sysmail_delete_log_sp en sysmail_delete_mailitems_sp gebruikt. Voorbeeld query:

DECLARE @Peildatum datetime = (SELECT DATEADD(MONTH,-1,GETDATE()))
EXECUTE sysmail_delete_log_sp @logged_before = @Peildatum
EXECUTE sysmail_delete_mailitems_sp @sent_before = @Peildatum

Opruimen van de logshipping historie
Voor het opschonen van historische backup data wordt de stored procedure sp_delete_backuphistory gebruikt. Voorbeeld query:

DECLARE @Peildatum datetime = (SELECT DATEADD(MONTH,-1,GETDATE()))
EXECUTE sp_delete_backuphistory @oldest_date = @Peildatum

Opruimen van de logshipping historie
Voor het opschonen van historische logshipping data wordt de stored procedure sp_cleanup_log_shipping_history gebruikt.
LET OP: deze stored procedure draait in de master database! Voorbeeld query:

DECLARE @database nvarchar(100)
DECLARE @agent_id nvarchar(100)
DECLARE @agent_type int
DECLARE @NumberOfRecords int

DECLARE agent_cursor CURSOR FOR
	SELECT DISTINCT
		database_name,
		agent_id,
		agent_type,
		COUNT(*) AS NumberOfRecords
	FROM msdb.dbo.log_shipping_monitor_history_detail
	GROUP BY database_name,agent_id,agent_type
--	ORDER BY database_name, agent_id, agent_type

OPEN agent_cursor
FETCH NEXT FROM agent_cursor
INTO @database, @agent_id, @agent_type, @NumberOfRecords

IF @@FETCH_STATUS <> 0
PRINT 'No records'

WHILE @@FETCH_STATUS = 0
BEGIN
execute master.dbo.sp_cleanup_log_shipping_history 
	@agent_id = @agent_id,
	@agent_type = @agent_type;
	FETCH NEXT FROM agent_cursor
	INTO @database, @agent_id, @agent_type, @NumberOfRecords
END

CLOSE agent_cursor
DEALLOCATE agent_cursor

En dan…? De msdb database is nog steeds niet kleiner geworden (op de storage)
Dat klopt! Verwijderen van data uit tabellen zorgt er alleen maar voor dat er ruimte binnen de database vrijkomt, die dan eerst weer hergebruikt wordt. Met de functie SHRINKFILE kan de database ook op de storage kleiner worden gemaakt. De meningen zijn erg verdeeld of het gebruik van de functie SHRINKFILE wél of niet verstandig is. Deze discussie moet u binnen uw eigen organisatie voeren. Ik leg u in deze bijdrage alleen uit, hoe de functie wordt gebruikt. De query’s:

-- We gaan naar de msdb database
USE msdb;
GO

-- We verkleinen eerst de data file
DBCC SHRINKFILE (N'MSDBData' , 500);
GO

-- We verkleinen dan de log file
DBCC SHRINKFILE (N'MSDBLog' , 200);
GO

-- Daarna is het verstandig de indexen opnieuw op te bouwen
EXEC sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?', ' ', 80)";
GO

Het opnieuw indexeren van de tabellen is een belangrijk onderdeel van de procedure om ervoor te zorgen dat eventuele fragmentatie van de database tabellen wordt tegen gegaan.

Nu is de msdb database weer behapbaar. Om dit zo te houden, is mijn advies om alle opruimquery’s in de SQL agent op te nemen en de opruimacties maandelijks uit te voeren. Dat zou uw msdb database in topconditie moeten houden.