Cara mendeteksi dan mencegah pertumbuhan tak terduga dari database SQL Server TempDB

Setiap contoh SQL Server berisi sistem database SQL Server yang disebut TempDB. Ini tipikal untuk semua koneksi database, dan hampir setiap kueri menggunakan database TempDB. Ini seperti hati untuk contoh SQL Server. Secara praktis, kami tidak dapat bekerja tanpa database TempDB.

Mari kita lihat ringkasan singkat operasi di mana SQL Server menggunakan TempDB.

• Pesan menurut dan Kelompokkan menurut klausa
• Pembuatan indeks dan pembuatan ulang indeks online
• Penyimpanan tabel Temp dan variabel tabel ada di database TempDB.
• Isolasi snapshot dan baca isolasi snapshot yang dilakukan
• Perintah DBCC
• Hash menggabungkan kursor statis, transaksi yang berjalan lama.
• Kueri XML
• Objek internal yang dibuat oleh mesin database SQL Server.
• Penyimpanan versi
• Beberapa kumpulan catatan aktif (MARS)

Anda dapat membaca lebih lanjut tentang TempDB di artikel ini.

SQL Server membuat ulang database TempDB ini pada mesin database Restart layanan. Restart ini dapat disebabkan oleh restart otomatis atau manual dari SQL Service. Kami dapat meminta sys.databases untuk melihat tanggal pembuatan TempDB yang juga merupakan waktu mulai layanan database:

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

Konfigurasi database SQL Server TempDB dan praktik terbaik

Terkadang, kami melihat pertumbuhan tak terduga dari database TempDB. Langkah pertama untuk menghindari ini adalah mengonfigurasinya sesuai praktik terbaik. Di bagian ini, mari kita lihat konfigurasi TempDB versi SQL Server yang berbeda.

Konfigurasikan TempDB untuk beberapa File DATA dengan pertumbuhan yang merata

Sesuai praktik terbaik, kita harus memiliki banyak file data dengan pertumbuhan semua file yang merata. Jumlah file tergantung pada prosesor logis.

Untuk versi SQL Server sebelum 2016, kami tidak memiliki konfigurasi yang tersedia selama proses instalasi.

Secara default, ini hanya membuat satu data dan file log dengan konfigurasi berikut:

Konfigurasi database SQL Server TempDB 2014 SQL Server

SQL Server 2016 menyediakan peningkatan untuk konfigurasi TempDB selama proses instalasi sesuai dengan praktik terbaik:

Konfigurasi SQL Server 2016 dan seterusnya TempDB

TempDB database SQL Server pertumbuhan otomatis tidak merata

SQL Server menggunakan metode round-robin untuk mengisi beberapa file data jika tidak memiliki ukuran yang sama. Terkadang, kita melihat bahwa satu file tumbuh besar, tetapi file lain tetap tumbuh minimum. Dalam kasus file yang tidak rata, SQL Server menggunakan file yang lebih besar untuk sebagian besar kueri, dan akan terus bertambah:

1. Gunakan pertumbuhan otomatis file TempDB yang sama (seperti yang dibahas pada poin sebelumnya).
2. Aktifkan tanda pelacakan 1117 untuk menumbuhkan semua file data bersama-sama dalam database.

Poin kedua diperbaiki secara otomatis di SQL Server 2016 dan seterusnya, namun Anda harus mengaktifkannya di versi sebelumnya. Kami tidak memerlukan tanda pelacakan ini di SQL Server 2016 dan yang lebih tinggi.

Skenario pertumbuhan TempDB

Di bagian ini, kita akan melihat beberapa skenario untuk pertumbuhan TempDB database SQL Server. Dalam contoh SQL saya, saya memiliki delapan file data dengan konfigurasi berikut:

Sekarang, jalankan kueri berikut untuk membuat tabel sementara dan melakukan penyisipan data. Lokasi penyimpanan tabel sementara adalah database TempDB. Kueri ini menggunakan operator CROSS JOIN dengan beberapa kolom dan selanjutnya mengurutkan hasilnya menggunakan klausa ORDER BY.

Catatan: Jangan jalankan kueri ini di sistem produksi; Saya menggunakannya untuk tujuan demo saja.

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;


Kueri ini akan memakan waktu lama dan dapat mengakibatkan penggunaan CPU yang tinggi juga di sistem Anda. Saat kueri berjalan, buka jendela kueri lain dan gunakan sys.dm_db_task_space_usage DMV untuk mendapatkan informasi alokasi halaman dan aktivitas deallokasi berdasarkan tugas. Kami menggabungkan DMV ini dengan DMV lain untuk mendapatkan informasi yang diperlukan untuk database SQL Server 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;
Pada output, kita melihat jumlah halaman objek internal dan ukurannya (kbytes_used_internal) untuk ID sesi 55. Pengoptimal kueri SQL Server mengeksekusi kueri ini dalam model paralel; oleh karena itu, kita dapat melihat beberapa ID sesi 71 di output:

Anda juga dapat melihat perkiraan rencana eksekusi, dan seperti yang ditunjukkan di bawah ini, kami mendapatkan dua operator mahal:

• Paralelisme:47,3%
• Urutkan:52,3%

Pada operator sortir, kita dapat melihat perkiraan biaya operator yang tinggi 138.576.5:

Kueri berikut menggunakan DMV sys.dm_db_file_space_usage dan menggabungkannya dengan sys.master_files untuk memeriksa jumlah halaman yang dialokasikan dan tidak dialokasikan di database SQL Server TempDB saat kueri dijalankan:

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


Kami dapat memantau eksekusi kueri, penggunaannya dalam database TempDB dan jika diperlukan, matikan proses untuk segera membebaskan ruang. Kami juga harus mengoptimalkan kueri yang menyebabkan pertumbuhan TempDB besar-besaran.

Memantau penggunaan TempDB database SQL Server menggunakan peristiwa yang diperpanjang

Peristiwa yang diperluas berguna untuk pemantauan database TempDB. Kami dapat menambahkan acara tambahan berikut menggunakan kueri:

• database_file_size_change
• databases_log_file_used_size_changed

Buat acara yang diperluas

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

Mulai sesi acara yang diperpanjang

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

Sekarang, jalankan beban kerja Anda untuk menggunakan database TempDB dan kembangkan file data. Peristiwa diperpanjang menangkap pertumbuhan file data dan kueri yang menyebabkan pertumbuhan ini.

Anda dapat melihat file sesi acara yang diperluas dalam mode GUI SSMS atau menggunakan kueri berikut untuk memantau pertumbuhan TempDB.

Pantau Pertumbuhan TempDB

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;

Isolasi Foto

Anda mungkin menggunakan isolasi snapshot untuk kueri Anda. Dalam model isolasi ini, SQL Server menyimpan versi baris yang diperbarui dari setiap transaksi di TempDB. Dalam kasus transaksi besar atau berjalan lama, Anda dapat melihat database TempDB yang sangat besar.

Anda dapat menjalankan transaksi dengan perintah SET dan menentukan isolasi Snapshot:

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

Anda juga dapat menanyakan sys.databases tampilan sistem untuk memeriksa apakah ada database pengguna yang memiliki isolasi snapshot.

Kueri untuk mengaktifkan isolasi snapshot pada database AdventureWorks

ALTER DATABASE AdventureWorks
SET ALLOW_SNAPSHOT_ISOLATION ON
GO


Kueri untuk memeriksa database pengguna dengan isolasi snapshot

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


Pada tangkapan layar berikut, Anda dapat melihat bahwa database AdventureWorks memiliki isolasi snapshot. Database TempDB juga memiliki isolasi snapshot, tetapi dalam kueri, kami melewatkan database_id kurang dari 4:

Kita dapat menggunakan DMV sys.dm_db_file_space_usage untuk memantau penyimpanan versi di 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;


Di sini, kita dapat melihat ukuran toko Versi adalah 67968 KB. Untuk transaksi besar atau berjalan lama, Anda dapat melihat ukuran TempDB database SQL Server yang sangat besar karena penyimpanan versi ini:

Kasus lain yang mungkin menyebabkan penyimpanan versi berukuran besar adalah Always on read-only replika Sekunder. Jika Anda menjalankan kueri apa pun di database sekunder, maka secara otomatis menggunakan tingkat isolasi snapshot. Seperti yang Anda ketahui, tingkat isolasi snapshot menyalin versi baris di TempDB.

Anda harus memantau penghitung kinerja berikut:

• SQLServer:Transactions\Waktu Transaksi Terpanjang – Ini menangkap transaksi aktif yang paling diperpanjang.
• SQLServer:Transactions\Version Store Size (KB) – Ini menangkap ukuran saat ini dari semua toko versi di TempDB.
• SQLServer:Transactions\Version Cleanup rate (KB/s ) – Anda dapat menggunakan penghitung ini untuk menunjukkan tingkat pembersihan versi di TempDB
• SQLServer:Transactions\Version Generation rate (KB/s) – Anda dapat menangkap kecepatan pengambilan versi toko menggunakan penghitung ini.

Anda harus memantau pertumbuhan TempDB untuk versi di Always di database sekunder juga. Matikan sesi yang berjalan lama sehingga dapat menghapus versi dan mendapatkan kembali ruang di database TempDB.

Kesimpulan

Pada artikel ini, kami mempelajari tentang praktik terbaik database TempDB database SQL Server dan berbagai metode untuk mendeteksi, mencegah pertumbuhan yang tidak terduga. Anda harus memantau TempDB secara teratur dan mengonfigurasi berbagai peringatan agar proaktif.

• Pemantauan ukuran TempDB
• Pemantauan ruang drive
• Transaksi jangka panjang