Database Sistem SQL Server – Pemeliharaan Tempdb

Dalam artikel saya sebelumnya tentang Database Sistem SQL Server, kita mempelajari tentang setiap database sistem yang datang sebagai bagian dari instalasi SQL Server. Artikel saat ini akan fokus pada masalah yang sering dihadapi seputar database tempdb dan cara mengatasinya dengan benar.

SQL Server TempDB

Seperti yang ditunjukkan oleh nama database sistem ini, tempdb memegang objek sementara dibuat oleh SQL Server. Mereka berhubungan dengan beberapa operasi dan bertindak sebagai area kerja Global untuk semua pengguna yang terhubung ke instance SQL Server.

Basis data Tempdb akan menampung jenis objek di bawah ini saat pengguna melakukan operasinya:

• Objek sementara dibuat secara eksplisit oleh pengguna. Mereka dapat berupa tabel dan indeks sementara Lokal atau Global, Variabel Tabel, tabel yang digunakan dalam fungsi bernilai Tabel, dan Kursor.
• Objek internal yang dibuat oleh mesin Database seperti
  • Tabel kerja yang menyimpan hasil antara untuk spool, kursor, sortir, dan objek besar sementara (LOB).
  • Berkas kerja saat melakukan operasi Hash Join atau Hash agregat.
  • Hasil sortir menengah saat membuat atau membangun kembali indeks jika SORT_IN_TEMPDB disetel ke AKTIF, dan operasi lain seperti kueri GROUP BY, ORDER BY, atau SQL UNION.
• Version Stores yang mendukung fitur versi Row, baik Common version store atau Online Index build version store menggunakan file database tempdb.

Database Tempdb dibuat setiap kali SQL Server Service dimulai. Oleh karena itu, waktu pembuatan database tempdb dapat dianggap sebagai perkiraan waktu startup Layanan SQL Server. Kami dapat mengidentifikasinya dari sys.databases DMV menggunakan kueri yang ditunjukkan di bawah ini:

SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'

Namun, startup sebenarnya dari SQL Server Service melibatkan memulai semua database sistem dalam urutan tertentu. Ini mungkin terjadi sedikit lebih awal dari waktu pembuatan tempdb. Kita dapat memperoleh nilai menggunakan sys.databases DMV dengan mengeksekusi kueri di bawah ini pada sys.dm_os_sys_info DMV .

SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info

ms_ticks kolom menentukan jumlah milidetik sejak komputer atau Server dimulai. sqlserver_start_time_ms_ticks kolom menentukan jumlah milidetik sejak ms_ticks nomor saat Layanan SQL Server dimulai.

Kami dapat menemukan info lebih lanjut tentang urutan database yang dimulai saat memulai layanan SQL Server di SQL Server Error Log.

Di SSMS, luaskan Manajemen > Log Kesalahan SQL Server > buka saat ini catatan eror. Terapkan Mulai meningkatkan basis data filter dan klik Tanggal untuk mengurutkannya dalam urutan menaik:

Kita dapat melihat bahwa database master telah dimulai terlebih dahulu saat memulai layanan SQL Server. Kemudian semua database pengguna dan semua database sistem lainnya diikuti. Akhirnya, tempdb dimulai. Anda juga dapat mengambil informasi ini secara terprogram dengan menjalankan xp_readerrorlog prosedur sistem:

Catatan :Kedua pendekatan di atas mungkin tidak menampilkan informasi yang diperlukan jika Layanan SQL Server tidak dimulai ulang baru-baru ini, dan Log Kesalahan SQL Server didaur ulang yang mungkin telah mendorong log kesalahan yang lebih lama ke file yang lebih lama. Dalam hal ini, kami mungkin perlu memindai data di seluruh file Log Kesalahan SQL Server yang Diarsipkan.

Masalah yang Sering Dihadapi di Database SQL TempDB

Karena tempdb menyediakan area kerja global untuk semua sesi atau aktivitas pengguna, tempdb dapat menjadi hambatan kinerja untuk operasi pengguna jika tidak dikonfigurasi dengan hati-hati. Dalam artikel saya sebelumnya, kami telah membahas praktik terbaik yang direkomendasikan untuk diterapkan di database tempdb. Namun, bahkan setelah menerapkannya, kami mungkin sering mengalami masalah:

1. Pertumbuhan file yang tidak merata di seluruh file data tempdb.
2. File data Tempdb berkembang menjadi nilai yang sangat besar dan perlu mengecilkan Tempdb.

Pertumbuhan File Tidak Merata di Seluruh File Data TempDB

Mulai dari SQL Server 2000, rekomendasi default adalah memiliki beberapa file data berdasarkan jumlah inti Logis yang tersedia di Server.

Ketika kita memiliki beberapa file data, misalnya 4 file data tempdb seperti pada gambar di bawah ini, pertumbuhan otomatis file data tempdb akan terjadi sebesar 64 MB secara round-robin mulai dari tempdev> temp2> temp3> temp4> tempdev> dan seterusnya.

Jika salah satu ukuran file tidak dapat tumbuh secara otomatis karena suatu alasan, itu akan menghasilkan ukuran file tertentu yang sangat besar dibandingkan dengan file lain. Ini menyebabkan kelebihan beban tambahan yang ditempatkan pada file besar dan dampak kinerja negatif pada database tempdb.

Kami perlu memastikan secara manual bahwa semua file data tempdb berukuran merata kapan saja secara manual untuk menghindari pertengkaran atau masalah kinerja hingga SQL Server 2014. Microsoft mengubah perilaku ini mulai dari SQL Server 2016 dan versi yang lebih baru dengan menerapkan beberapa fitur yang akan dibahas nanti dalam artikel ini.

Untuk mengatasi masalah kinerja di atas, SQL Server telah memperkenalkan 2 Trace Flags bernama 1117 dan 1118 untuk menghindari masalah pertengkaran seputar tempdb.

• Melacak Bendera 1117 – memungkinkan pertumbuhan otomatis semua file dalam satu Filegroup
• Jejak Bendera 1118 – mengaktifkan UNIFORM FULL EXTENTS untuk tempdb

Trace Flag 1117

Tanpa Trace Flag 1117 diaktifkan, setiap kali tempdb dikonfigurasi dengan beberapa file data yang berukuran sama dan file data perlu tumbuh secara otomatis, SQL Server secara default akan mencoba meningkatkan ukuran file secara round-robin jika semua file. Jika ukuran file data tidak merata, maka SQL Server akan mencoba meningkatkan ukuran file data tempdb terbesar dan akan menggunakan file yang lebih besar ini untuk sebagian besar operasi pengguna yang mengakibatkan masalah pertikaian tempdb.

Untuk mengatasi masalah ini, SQL Server memperkenalkan Trace Flag 1117. Setelah diaktifkan, jika satu file dalam filegroup perlu tumbuh secara otomatis, itu akan otomatis menumbuhkan semua file dalam filegroup tersebut. Ini menyelesaikan masalah pertikaian tempdb. Namun, masalahnya adalah setelah flag Trace 1117 diaktifkan, pertumbuhan otomatis juga dikonfigurasi untuk semua database pengguna.

Trace Flag 1118

Trace Flag 1118 digunakan untuk mengaktifkan UNIFORM FULL EXTENTS. Mari kita mundur selangkah untuk memahami bagaimana SQL Server menyimpan data dari dasar.

Halaman adalah unit penyimpanan dasar di SQL Server dengan ukuran 8 Kilobyte (KB).

Luas adalah kumpulan 8 halaman yang berdekatan secara fisik dengan ukuran 64KB(8*8KB). Berdasarkan berapa banyak objek atau pemilik yang menyimpan data dalam suatu Extent, Extent dapat diklasifikasikan menjadi:

• Ekstensi Seragam adalah 8 halaman bersebelahan yang digunakan atau diakses oleh satu objek atau pemilik;
• Campur Ekstensi – adalah 8 halaman bersebelahan yang digunakan atau diakses oleh minimal 2 dan maksimal 8 objek atau pemilik

Mengaktifkan Trace Flag 1118 akan memungkinkan tempdb memiliki luasan seragam yang menghasilkan kinerja yang lebih baik.

Cara Mengaktifkan Tanda Pelacakan 1117 &1118

Trace Flags dapat diaktifkan melalui beberapa pendekatan. Anda dapat menentukan cara yang sesuai dari opsi di bawah ini:

Parameter Startup Layanan SQL Server

Tersedia secara permanen bahkan setelah Layanan SQL dimulai ulang. Cara yang disarankan adalah mengaktifkan Trace Flags 1117 dan 1118 melalui parameter startup Layanan SQL Server .

Buka Pengelola Konfigurasi Server SQL dan klik Layanan SQL Server untuk membuat daftar layanan yang tersedia di server itu:

1. Klik kanan pada SQL Server (MSSQLSERVER) > Properti > Parameter Startup .
2. Jenis –T ke dalam bidang kosong untuk menunjukkan Bendera Jejak .
3. Berikan nilai 1117 dan 1118 seperti yang ditunjukkan di bawah ini.
4. Klik Tambahkan agar Trace Flags ditambahkan sebagai parameter Startup.

Kemudian klik Oke agar tanda jejak ditambahkan secara permanen untuk contoh SQL Server ini. Mulai ulang Layanan SQL Server agar perubahan diterapkan.

DBCC TRACEON (, -1)

Aktifkan tanda pelacakan secara global. Layanan SQL Server akan kehilangan tanda jejak saat Layanan dimulai ulang. Untuk mengaktifkan tanda pelacakan secara global, jalankan skrip di bawah ini di jendela kueri baru:

DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);

DBCC TRACEON ()

Aktifkan tanda pelacakan di tingkat sesi. Ini hanya berlaku untuk sesi saat ini yang dibuat oleh pengguna. Untuk mengaktifkan tanda pelacakan di tingkat sesi, jalankan skrip di bawah ini di jendela kueri baru:

DBCC TRACEON(1117);
DBCC TRACEON(1118);

Untuk melihat daftar tanda pelacakan yang diaktifkan dalam instance SQL Server, kita dapat menggunakan DBCC TRACESTATUS perintah:

DBCC TRACESTATUS();

Seperti yang dapat kita lihat, Trace Flags 1117 dan 1118 diaktifkan secara Global dalam instance saya bersama dengan Session .

Untuk mematikan Trace Flag, kita dapat menggunakan perintah DBCC TRACEOFF seperti:

DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);

Peningkatan TempDB SQL Server 2016

Di seluruh versi SQL Server SQL Server 2000 hingga SQL Server 2014, kami harus mengaktifkan Trace Flags 1117 dan 1118 bersama dengan pemantauan lengkap tempdb untuk menghindari masalah pertengkaran tempdb. Mulai dari SQL Server 2016 dan versi yang lebih baru, pelacakan Bendera 1117 dan 1118 diterapkan secara default.

Namun, berdasarkan pengalaman pribadi saya, lebih baik untuk melakukan pra-pertumbuhan tempdb ke ukuran besar untuk menghindari kebutuhan pertumbuhan otomatis beberapa kali dan untuk menghilangkan ukuran file yang tidak merata atau file tunggal yang digunakan oleh SQL Server secara ekstensif .

Kami dapat memverifikasi bagaimana Trace Flag 1117 dan 1118 diimplementasikan di SQL Server 2016:

Melacak Bendera 1117 yang menyetel Pertumbuhan Otomatis semua File dalam filegroup sekarang properti Filegroup . Kita dapat mengonfigurasinya saat membuat Filegroup baru atau memodifikasi yang sudah ada.

Untuk memverifikasi properti auto-grow dari Filegroup , jalankan skrip di bawah ini dari sys.filegroups DMV :

SELECT name Filegroup_Name, is_autogrow_all_files 
FROM sys.filegroups

Untuk memodifikasi properti pertumbuhan otomatis dari database Filegroup Utama dari AdventureWorks , kami menjalankan skrip di bawah ini dengan AUTOGROW_ALL_FILES untuk menumbuhkan semua file secara otomatis atau AUTOGROW_SINGLE_FILE untuk memungkinkan pertumbuhan otomatis hanya untuk satu file data.

ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE 
-- AUTOGROW_ALL_FILES is the default behavior
GO

Melacak Bendera 1118 yang menyetel properti Uniform Extent dari file data diaktifkan secara default untuk tempdb dan semua database pengguna mulai dari SQL Server 2016 . Kami tidak dapat mengubah properti untuk tempdb, karena sekarang hanya mendukung opsi Uniform Extent.

Untuk database Pengguna, kita dapat memodifikasi parameter ini. Master, model, dan msdb database Sistem mendukung ekstensi Campuran secara default dan juga tidak dapat diubah.

Untuk mengubah nilai properti alokasi Halaman Campuran untuk database Pengguna, gunakan skrip di bawah ini:

ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON 
-- OFF is the default behavior
GO

Untuk memverifikasi properti alokasi halaman Campuran, kita dapat menanyakan is_mixed_page_allocation_on kolom dari sys.databases DMV dengan nilai sebagai 0, menunjukkan alokasi halaman tingkat seragam, dan 1 untuk menunjukkan alokasi halaman tingkat campuran.

SELECT name, is_mixed_page_allocation_on
FROM sys.databases

File Data TempDB Bertumbuh ke Nilai Besar yang Membutuhkan TempDB Kecilkan

Di SQL Server 2014 atau versi yang lebih lama, jika bendera Trace 1117 dan 1118 tidak dikonfigurasi dengan benar bersama dengan beberapa file data yang dibuat untuk database tempdb, beberapa file tersebut pasti akan tumbuh besar. Jika itu terjadi, DBA biasanya mencoba mengecilkan file data tempdb. Tapi itu adalah tidak pantas pendekatan untuk menangani skenario ini.

Ada opsi lain yang tersedia untuk mengecilkan tempdb.

Mari kita pertimbangkan perintah DBCC yang tersedia untuk Kecilkan tempdb dan dampak dari melakukan operasi ini.

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE perintah console bekerja dengan menyusutkan bagian akhir Data\Log Files .

Agar berhasil mengecilkan database, perintah membutuhkan ruang kosong di akhir file. Jika ada transaksi aktif di akhir file, file database tidak dapat dikecilkan.

Dampak menjalankan DBCC SHRINKDATABASE adalah bahwa ia akan mencoba untuk mengosongkan ruang kosong yang tersedia di akhir setiap file data atau file log yang mungkin telah dicadangkan untuk pertumbuhan data tabel di masa mendatang. Oleh karena itu, menjalankan perintah ini dapat mengakibatkan ukuran file yang tidak merata yang menyebabkan masalah pertikaian tempdb.

Sintaks untuk mengecilkan basis data pengguna misalnya basis data Adventureworks adalah

DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);

DBCC SHRINKFILE

DBCC SHRINKFILE perintah console bekerja mirip dengan DBCC SHRINKDATABASE, tetapi mengecilkan Data Database atau file Log yang ditentukan .

Jika Anda mengidentifikasi bahwa file Data tempdb tertentu sangat besar, kami dapat mencoba mengecilkan item tertentu menggunakan DBCC SHRINKFILE seperti yang ditunjukkan di bawah ini.

Berhati-hatilah saat menggunakan perintah ini di tempdb karena jika suatu file menyusut ke nilai yang lebih rendah atau lebih tinggi dari file data lain, file data tertentu itu tidak akan digunakan secara efektif. Atau, itu akan digunakan lebih sering yang mengarah ke masalah pertikaian tempdb.

Sintaks untuk menjalankan operasi DBCC SHRINKFILE pada file data AdventureWorks hingga 1GB (1024 MB) adalah:

DBCC SHRINKFILE (AdventureWorks, 1024);  
GO 

DBCC DROPCLEANBUFFERS

DBCC DROPCLEANBUFFERS perintah console digunakan untuk menghapus semua buffer bersih dari kumpulan Buffer dan objek columnstore dari kumpulan objek columnstore .

Cukup jalankan perintah di bawah ini:

DBCC DROPCLEANBUFFERS

PROCCACHE GRATIS DBCC

DBCC FREEPROCCACHE perintah menghapus semua cache rencana eksekusi prosedur tersimpan .

Cache Rencana Eksekusi Prosedur digunakan oleh SQL Server untuk menjalankan panggilan prosedur yang sama lebih cepat. Setelah menjalankan DBCC FREEPROCCACHE, Cache Rencana dihapus. Dengan demikian, SQL Server harus membuat cache itu lagi ketika prosedur tersimpan dijalankan dalam contoh. Ini meninggalkan dampak negatif yang serius saat dijalankan dalam instans DB Produksi.

Tidak disarankan untuk menjalankan DBCC FREEPROCCACHE pada instans basis data Produksi!

Sintaks untuk menjalankan DBCC FREEPROCCACHE di bawah ini:

DBCC FREEPROCCACHE

DBCC FREESESSIONCACHE

DBCC FREESESSIONCACHE perintah mengosongkan cache koneksi kueri Distribusi dari contoh SQL Server . Akan sangat membantu ketika ada banyak kueri terdistribusi yang dijalankan pada contoh SQL Server tertentu.

Sintaks untuk mengeksekusi DBCC FREESESSIONCACHE adalah:

DBCC FREESESSIONCACHE

DBCC FREESYSTEMCACHE

DBCC FREESYSTEMCACHE perintah menghapus semua entri cache yang tidak digunakan dari semua cache . SQL Server melakukan ini secara default untuk membuat lebih banyak memori tersedia untuk operasi baru. Namun, kita dapat menjalankannya secara manual menggunakan perintah di bawah ini:

DBCC FREESYSTEMCACHE

Seperti yang kita ketahui, tempdb menyimpan semua objek pengguna sementara atau objek internal termasuk Cache Rencana Eksekusi, data kumpulan Buffer, Cache Sesi, dan Cache Sistem. Oleh karena itu, menjalankan 6 perintah DBCC di atas akan membantu menghapus file data tempdb yang mencegah proses penyusutan normal.

Meskipun kami telah melalui langkah-langkah tentang cara mengecilkan tempdb melalui berbagai pendekatan, praktik terbaik yang direkomendasikan untuk menangani database tempdb tercantum di bawah ini:

a. Mulai ulang Layanan SQL Server jika memungkinkan untuk membuat ulang file data tempdb secara merata. Dampak potensialnya adalah, kami akan kehilangan semua rencana Eksekusi dan informasi cache lainnya yang dibahas di atas.

b. Pra-tumbuhkan file data tempdb ke ukuran file besar yang tersedia di drive yang menyimpan file data tempdb. Ini akan mencegah SQL Server meningkatkan ukuran file secara tidak merata di SQL Server versi 2014 dan sebelumnya.

c. Jika Layanan SQL Server tidak dapat dimulai ulang karena RTO atau RPO, coba perintah DBCC di atas setelah memahami dampaknya dengan jelas.

d. Mengecilkan database tempdb atau file data bukanlah pendekatan yang disarankan dan karenanya jangan pernah melakukannya di lingkungan Produksi Anda kecuali jika tidak ada opsi lain.

Kesimpulan

Kami telah mempelajari lebih lanjut tentang internal tentang cara kerja tempdb sehingga kami dapat mengonfigurasi tempdb untuk kinerja yang lebih baik menghindari masalah pertikaian pada tempdb. Kami juga telah melalui masalah yang sering dihadapi di tempdb, langkah-langkah yang tersedia di SQL Server di berbagai versi dan cara menanganinya secara efisien. Selain itu, kami telah memeriksa mengapa Menyusut database tempdb atau file data bukanlah pendekatan yang disarankan saat menangani database tempdb.