Sådan opdages og forhindres uventet vækst af SQL Server-databasen TempDB

Hver SQL Server-instans indeholder systemets SQL Server-database kaldet TempDB. Det er typisk for alle databaseforbindelser, og næsten hver forespørgsel gør brug af TempDB-databasen. Det er som et hjerte for SQL Server-instansen. Vi kan praktisk talt ikke arbejde uden TempDB-databasen.

Lad os få en hurtig oversigt over operationer, hvor SQL Server bruger TempDB.

• Bestil efter og Gruppér efter klausul
• Oprettelse af indeks og genopbygning af onlineindeks
• Opbevaring af midlertidige tabeller og tabelvariabler er i TempDB-databasen.
• Snapshot-isolering og læst committed snapshot-isolation
• DBCC-kommandoer
• Hash forbinder statiske markører, langvarige transaktioner.
• XML-forespørgsler
• Interne objekter oprettet af SQL Server-databasemotoren.
• Versionsbutikker
• Flere aktive rekordsæt (MARS)

Du kan læse mere om TempDB i denne artikel.

SQL Server genskaber denne TempDB-database ved genstart af databasemotorservice. Denne genstart kan skyldes automatisk eller manuel genstart af SQL Service. Vi kan forespørge sys.databases for at se TempDB-oprettelsesdatoen, som også er et opstartstidspunkt for databasetjenesten:

SELECT create_date AS 'SQL Service Startup Time'
FROM sys.databases
WHERE name = 'tempdb';

TempDB SQL Server-databasekonfigurationer og bedste praksis

Nogle gange bemærker vi en uventet vækst af TempDB-databasen. Det første skridt til at undgå dette er at konfigurere det i henhold til bedste praksis. Lad os i dette afsnit se TempDB-konfigurationen er forskellige versioner af SQL Server.

Konfigurer TempDB til flere DATA-filer med jævn vækst

I henhold til bedste praksis bør vi have flere datafiler med jævn vækst af alle filer. Antallet af filer afhænger af de logiske processorer.

For SQL Server-versioner før 2016 har vi ikke konfiguration tilgængelig under installationsprocessen.

Som standard opretter den kun én data- og logfil med følgende konfigurationer:

SQL Server 2014 TempDB SQL Server-databasekonfiguration

SQL Server 2016 giver forbedringer til TempDB-konfiguration under installationsprocessen i henhold til bedste praksis:

SQL Server 2016 og fremefter TempDB-konfiguration

Ujævn automatisk vækst af SQL Server-database TempDB

SQL Server bruger en round-robin-metode til at udfylde flere datafiler, hvis de ikke har samme størrelse. Nogle gange ser vi, at en fil vokser enorm, men andre filer forbliver minimal vækst. I tilfælde af ujævne filer bruger SQL Server den større fil til de fleste af forespørgslerne, og den vil fortsætte med at vokse:

1. Brug den samme automatiske vækst af TempDB-filer (som diskuteret i det foregående punkt).
2. Aktiver sporingsflag 1117 for at vokse alle datafiler sammen i en database.

Det andet punkt rettes automatisk i SQL Server 2016 og fremefter, men du bør aktivere det i tidligere versioner. Vi kræver ikke dette sporingsflag i SQL Server 2016 og nyere.

TempDB vækstscenarier

I dette afsnit vil vi se et par scenarier for SQL Server-database TempDB-vækst. I min SQL-instans har jeg otte datafiler med følgende konfiguration:

Udfør nu følgende forespørgsel for at oprette en midlertidig tabel og udføre dataindsættelse. Den midlertidige tabellagerplads er TempDB-databasen. Denne forespørgsel bruger en CROSS JOIN-operator med flere kolonner og sorterer resultaterne yderligere ved hjælp af ORDER BY-sætningen.

Bemærk: Kør ikke denne forespørgsel i produktionssystemet; Jeg bruger det kun til demoformål.

SELECT *
FROM sys.configurations
CROSS JOIN sys.configurations SCA
CROSS JOIN sys.configurations SCB
CROSS JOIN sys.configurations SCC
CROSS JOIN sys.configurations SCD
CROSS JOIN sys.configurations SCE
CROSS JOIN sys.configurations SCF
CROSS JOIN sys.configurations SCG
CROSS JOIN sys.configurations SCH
ORDER BY SCA.name,
SCA.value,
SCC.value_in_use DESC;


Denne forespørgsel vil tage lang tid og kan også resultere i højt CPU-forbrug i dit system. Mens forespørgslen kører, skal du åbne et andet forespørgselsvindue og bruge DMV sys.dm_db_task_space_usage til at få oplysninger om sideallokering og deallokeringsaktivitet efter opgaven. Vi forbinder denne DMV med andre DMV'er for at få de nødvendige oplysninger til SQL Server-databasen TempDB:

SELECT s.session_id, dbu.database_id
, dbu.internal_objects_alloc_page_count, dbu.internal_objects_dealloc_page_count
, (dbu.internal_objects_alloc_page_count - dbu.internal_objects_dealloc_page_count) * 8192 / 1024 kbytes_used_internal
, r.total_elapsed_time
FROM sys.dm_Exec_requests r
INNER JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
LEFT JOIN sys.dm_db_task_space_usage dbu ON dbu.session_id = r.session_id
AND dbu.request_id = r.request_id
WHERE internal_objects_alloc_page_count > 0
ORDER BY kbytes_used_internal DESC;
I outputtet ser vi interne objektsideantal og deres størrelser (kbytes_used_internal) for sessions-ID 55. SQL Server-forespørgselsoptimering udfører denne forespørgsel i en parallel model; derfor kan vi se flere sessions-ID 71 i outputtet:

Du kan også se den estimerede udførelsesplan, og som vist nedenfor får vi to dyre operatører:

• Parallelisme:47,3 %
• Sortering:52,3 %

I sorteringsoperatøren kan vi se høje estimerede operatøromkostninger på 138.576,5:

Følgende forespørgsel bruger DMV sys.dm_db_file_space_usage og forbinder det med sys.master_files for at kontrollere antallet af allokerede og ikke-allokerede omfangssider i SQL Server-databasen TempDB, mens forespørgslen udføres:

select mf.physical_name, mf.size as entire_file_page_count,
dfsu.unallocated_extent_page_count,
dfsu.user_object_reserved_page_count,
dfsu.internal_object_reserved_page_count,
dfsu.mixed_extent_page_count
from sys.dm_db_file_space_usage dfsu
join sys.master_files as mf
on mf.database_id = dfsu.database_id
and mf.file_id = dfsu.file_id


Vi kan overvåge udførelsen af ​​forespørgslen, dens brug i TempDB-databasen og om nødvendigt dræbe processen for at frigive pladsen med det samme. Vi bør også optimere forespørgslen, hvilket forårsager massiv TempDB-vækst.

Overvåg SQL Server-database TempDB-brug ved hjælp af udvidede hændelser

Udvidede hændelser er nyttige til TempDB-databaseovervågning. Vi kan tilføje følgende udvidede begivenheder ved hjælp af forespørgslen:

• database_file_size_change
• databases_log_file_used_size_changed

Opret udvidet begivenhed

CREATE EVENT SESSION [TempDB Usage] ON SERVER
ADD EVENT sqlserver.database_file_size_change(

ACTION(sqlserver.client_hostname,sqlserver.database_id,sqlserver.session_id,sqlserver.sql_text)),
ADD EVENT sqlserver.databases_log_file_used_size_changed(

ACTION(sqlserver.client_hostname,sqlserver.database_id,sqlserver.session_id,sqlserver.sql_text))
ADD TARGET package0.event_file(SET filename=N'TempDBUsage',max_rollover_files=(0))
WITH (STARTUP_STATE=OFF)
GO

Start udvidet begivenhedssession

ALTER EVENT SESSION [TempDBTest] ON SERVER STATE = START;

Udfør nu din arbejdsbyrde for at bruge TempDB-databasen og vokse datafilerne. De udvidede hændelser fanger datafilvækst og forespørgsel, der forårsagede denne vækst.

Du kan enten se filen med udvidet begivenhedssession i SSMS GUI-tilstand eller bruge følgende forespørgsel til at overvåge TempDB-vækst.

Overvåg TempDB-vækst

SELECT [eventdata].[event_data].[value]('(event/action[@name="session_id"]/value)[1]', 'INT') AS [SessionID],
[eventdata].[event_data].[value]('(event/action[@name="client_hostname"]/value)[1]', 'VARCHAR(100)') AS [ClientHostName],
DB_NAME([eventdata].[event_data].[value]('(event/action[@name="database_id"]/value)[1]', 'BIGINT')) AS [GrowthDB],
[eventdata].[event_data].[value]('(event/data[@name="file_name"]/value)[1]', 'VARCHAR(200)') AS [GrowthFile],
[eventdata].[event_data].[value]('(event/data[@name="file_type"]/text)[1]', 'VARCHAR(200)') AS [DBFileType],
[eventdata].[event_data].[value]('(event/@name)[1]', 'VARCHAR(MAX)') AS [EventName],
[eventdata].[event_data].[value]('(event/data[@name="size_change_kb"]/value)[1]', 'BIGINT') AS [SizeChangedKb],
[eventdata].[event_data].[value]('(event/data[@name="total_size_kb"]/value)[1]', 'BIGINT') AS [TotalSizeKb],
[eventdata].[event_data].[value]('(event/data[@name="duration"]/value)[1]', 'BIGINT') AS [DurationInMS],
[eventdata].[event_data].[value]('(event/@timestamp)[1]', 'VARCHAR(MAX)') AS [GrowthTime],
[eventdata].[event_data].[value]('(event/action[@name="sql_text"]/value)[1]', 'VARCHAR(MAX)') AS [QueryText]
FROM
(
SELECT CAST([event_data] AS XML) AS [TargetData]
FROM [sys].[fn_xe_file_target_read_file]('C:\TEMP\TempDBusage*.xel', NULL, NULL, NULL)
) AS [eventdata]([event_data])
WHERE [eventdata].[event_data].[value]('(event/@name)[1]', 'VARCHAR(100)') = 'database_file_size_change'
OR [eventdata].[event_data].[value]('(event/@name)[1]', 'VARCHAR(100)') = 'databases_log_file_used_size_changed'
AND [eventdata].[event_data].[value]('(event/@name)[1]', 'VARCHAR(MAX)') <> 'databases_log_file_used_size_changed'
ORDER BY [GrowthTime] ASC;

Snapshot-isolering

Du kan bruge snapshot-isolering til dine forespørgsler. I denne isolationsmodel gemmer SQL Server de opdaterede rækkeversioner af hver transaktion i TempDB. I tilfælde af en stor eller langvarig transaktion, kan du se en enorm TempDB-database.

Du kan udføre transaktionen med kommandoen SET og angive Snapshot-isolering:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN;
UPDATE [AdventureWorks].[Person].[Person]
SET
[Title] = 'Mr.';
COMMIT TRAN;

Du kan også forespørge sys.databases systemvisning for at kontrollere, om en brugerdatabase har snapshot-isolering.

Forespørgsel for at aktivere snapshot-isolering på AdventureWorks-databasen

ALTER DATABASE AdventureWorks
SET ALLOW_SNAPSHOT_ISOLATION ON
GO


Forespørgsel for at kontrollere brugerdatabase med snapshot-isolering

SELECT *
FROM sys.databases
WHERE(snapshot_isolation_state = 1
OR is_read_committed_snapshot_on = 1)
AND database_id > 4;


I det følgende skærmbillede kan du se, at AdventureWorks-databasen har snapshot-isolering. TempDB-databasen har også snapshot-isolering, men i forespørgslen har vi sprunget over database_id mindre end 4:

Vi kan bruge DMV sys.dm_db_file_space_usage til at overvåge versionslagret i TempDB:

SELECT GETDATE() AS runtime,
SUM(user_object_reserved_page_count) * 8 AS usr_obj_kb,
SUM(internal_object_reserved_page_count) * 8 AS internal_obj_kb,
SUM(version_store_reserved_page_count) * 8 AS version_store_kb,
SUM(unallocated_extent_page_count) * 8 AS freespace_kb,
SUM(mixed_extent_page_count) * 8 AS mixedextent_kb
FROM sys.dm_db_file_space_usage;


Her kan vi se version store størrelse er 67968 KB. For en stor eller langvarig transaktion kan du se en enorm SQL Server-database TempDB-størrelse på grund af dette versionslager:

En anden sag, der kan forårsage en enorm størrelse af versionslagret, er Altid på skrivebeskyttet sekundær replika. Hvis du udfører en forespørgsel på den sekundære database, bruger den automatisk snapshot-isolationsniveauet. Som du ved, kopierer snapshot-isolationsniveau rækkeversionen i TempDB.

Du bør overvåge følgende perfmon-tællere:

• SQLServer:Transaktioner\Længste transaktions løbetid – Det fanger den mest udvidede aktive transaktion.
• SQLServer:Transaktioner\Version Store Størrelse (KB) – Det fanger den aktuelle størrelse af alle versionslagrene i TempDB.
• SQLServer:Transaktioner\Versionsoprydningshastighed (KB/s ) – Du kan bruge denne tæller til at vise hastigheden for versionsoprydning i TempDB
• SQLServer:Transaktioner\Versionsgenereringshastighed (KB/s) – Du kan registrere versionslagringshastigheden ved hjælp af denne tæller.

Du bør også overvåge TempDB-væksten for versioneringen i Always på den sekundære database. Dræb de langvarige sessioner, så den kan rydde versionsstyringen og genvinde plads i TempDB-databasen.

Konklusion

I denne artikel lærte vi om SQL Server-databasen TempDB-databasens bedste praksis og forskellige metoder til at opdage, forhindre uventet vækst. Du bør overvåge TempDB regelmæssigt og konfigurere forskellige advarsler til at være proaktive.

• TempDB-størrelsesovervågning
• Drev-pladsovervågning
• Langevarende transaktioner