Saat tahun 2014 berakhir, saya memulai serangkaian posting tentang pemeriksaan kesehatan SQL Server proaktif, berdasarkan yang saya tulis kembali pada awal tahun ini – Masalah Kinerja:Pertemuan Pertama. Dalam posting itu, saya membahas apa yang saya cari pertama kali ketika memecahkan masalah kinerja di lingkungan yang tidak dikenal. Dalam rangkaian posting ini, saya ingin berbicara tentang apa yang saya cari ketika saya menghubungi pelanggan jangka panjang saya. Kami menyediakan layanan DBA Jarak Jauh, dan salah satu tugas rutin kami adalah audit kesehatan "mini" bulanan terhadap lingkungan mereka. Kami memiliki pemantauan di tempat dan, biasanya, saya sedang mengerjakan proyek, jadi saya berada di lingkungan secara teratur. Tetapi sebagai langkah tambahan untuk memastikan kami tidak melewatkan apa pun, sebulan sekali kami memeriksa data yang sama yang kami kumpulkan dalam audit kesehatan standar kami dan mencari sesuatu yang tidak biasa. Itu bisa banyak hal, bukan? Ya! Jadi, mari kita mulai dengan luar angkasa.
Wah, luar angkasa? Ya, ruang. Jangan khawatir, saya akan membahas topik lain.
Yang harus diperiksa
Mengapa saya mulai dengan luar angkasa? Karena itu adalah sesuatu yang sering saya lihat diabaikan, dan jika Anda kehabisan ruang disk untuk file database Anda, Anda menjadi sangat terbatas dalam apa yang dapat Anda lakukan di database Anda. Perlu menambahkan data tetapi tidak dapat menumbuhkan file karena disk penuh? Maaf, sekarang pengguna tidak dapat menambahkan data. Tidak mengambil cadangan log karena suatu alasan, sehingga log transaksi mengisi drive? Maaf, sekarang Anda tidak dapat mengubah data apa pun. Ruang sangat penting. Kami memiliki tugas yang memantau ruang kosong pada disk dan file, tetapi saya masih memverifikasi hal berikut untuk setiap audit, dan membandingkan nilainya dengan nilai bulan sebelumnya:
- Ukuran setiap file log
- Ukuran setiap file data
- Ruang kosong di setiap file data
- Ruang kosong di setiap drive dengan file database
- Ruang kosong di setiap drive dengan file cadangan
Pertumbuhan File Log
Sebagian besar masalah yang saya lihat terkait dengan ruang disk adalah karena pertumbuhan file log. Pertumbuhan biasanya terjadi karena salah satu dari dua alasan:
- Basis data dalam pemulihan LENGKAP dan pencadangan log transaksi tidak diambil karena alasan tertentu
- Seseorang menjalankan satu transaksi yang sangat besar yang menghabiskan semua ruang log yang ada, memaksa file untuk berkembang
Saya juga melihat file log tumbuh sebagai bagian dari pemeliharaan indeks. Untuk pembangunan kembali, setiap alokasi dicatat dan untuk indeks besar, yang dapat menghasilkan sejumlah besar log. Bahkan dengan pencadangan log transaksi biasa, log masih dapat tumbuh lebih cepat daripada pencadangan yang dapat terjadi. Untuk mengelola log, Anda perlu menyesuaikan frekuensi pencadangan, atau memodifikasi metodologi pemeliharaan indeks.
Anda perlu menentukan mengapa file log bertambah, yang bisa jadi rumit kecuali Anda melacaknya. Saya memiliki pekerjaan yang berjalan setiap jam untuk memotret ukuran dan penggunaan file log:
USE [Baselines];
GO
IF (NOT EXISTS (SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'SQLskills_TrackLogSpace'))
BEGIN
CREATE TABLE [dbo].[SQLskills_TrackLogSpace](
[DatabaseName] [VARCHAR](250) NULL,
[LogSizeMB] [DECIMAL](38, 0) NULL,
[LogSpaceUsed] [DECIMAL](38, 0) NULL,
[LogStatus] [TINYINT] NULL,
[CaptureDate] [DATETIME2](7) NULL
) ON [PRIMARY];
ALTER TABLE [dbo].[SQLskills_TrackLogSpace] ADD DEFAULT (SYSDATETIME()) FOR [CaptureDate];
END
CREATE TABLE #LogSpace_Temp (
DatabaseName VARCHAR(100),
LogSizeMB DECIMAL(10,2),
LogSpaceUsed DECIMAL(10,2),
LogStatus VARCHAR(1)
);
INSERT INTO #LogSpace_Temp EXEC('dbcc sqlperf(logspace)');
INSERT INTO Baselines.dbo.SQLskills_TrackLogSpace
(DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus)
SELECT DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus
FROM #LogSpace_Temp;
DROP TABLE #LogSpace_Temp; Saya menggunakan informasi ini untuk menentukan kapan file log mulai bertambah, dan saya mulai melihat-lihat log dan riwayat pekerjaan untuk melihat informasi tambahan apa yang dapat saya temukan. Pertumbuhan log harus statis – log harus berukuran dan dikelola dengan tepat melalui pencadangan (jika berjalan dalam pemulihan LENGKAP), dan jika file perlu lebih besar, saya perlu memahami alasannya, dan mengubah ukurannya sesuai.
Jika Anda menghadapi masalah ini, dan Anda belum secara proaktif melacak peristiwa pertumbuhan file, Anda mungkin masih dapat mengetahui apa yang terjadi. Peristiwa pertumbuhan otomatis ditangkap oleh SQL Server; Aaron Bertrand dari SQL Sentry membuat blog tentang ini pada tahun 2007, di mana ia menunjukkan cara menemukan kapan peristiwa ini terjadi (selama masih cukup baru untuk tetap ada di jejak default).
Ukuran dan Ruang Kosong di File Data
Anda mungkin pernah mendengar bahwa file data Anda harus berukuran sebelumnya sehingga tidak harus tumbuh secara otomatis. Jika Anda mengikuti panduan ini, Anda mungkin belum pernah mengalami peristiwa di mana file data tumbuh secara tidak terduga. Tetapi jika Anda tidak mengelola file data Anda, maka Anda mungkin mengalami pertumbuhan yang terjadi secara teratur – disadari atau tidak (terutama dengan pengaturan pertumbuhan default sebesar 10% dan 1 MB).
Ada trik untuk melakukan pra-ukuran file data – Anda tidak ingin ukuran database terlalu besar, karena ingat, jika Anda mengembalikan, katakanlah, lingkungan dev atau QA, file berukuran sama, bahkan jika mereka kembali tidak penuh data. Tetapi Anda masih ingin mengelola pertumbuhan secara manual. Saya menemukan bahwa DBA memiliki waktu tersulit dengan database baru. Pengguna bisnis tidak tahu tentang tingkat pertumbuhan dan berapa banyak data yang ditambahkan, dan database itu sedikit longgar di lingkungan Anda. Anda perlu memperhatikan file-file ini sampai Anda memiliki pegangan pada ukuran dan pertumbuhan yang diharapkan. Saya menggunakan kueri yang memberikan informasi tentang ukuran dan ruang kosong:
SELECT
[file_id] AS [File ID],
[type] AS [File Type],
substring([physical_name],1,1) AS [Drive],
[name] AS [Logical Name],
[physical_name] AS [Physical Name],
CAST([size] as DECIMAL(38,0))/128. AS [File Size MB],
CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128. AS [Space Used MB],
(CAST([size] AS DECIMAL(38,0))/128) - (CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128.) AS [Free Space],
[max_size] AS [Max Size],
[is_percent_growth] AS [Percent Growth Enabled],
[growth] AS [Growth Rate],
SYSDATETIME() AS [Current Date]
FROM sys.database_files; Setiap bulan, saya memeriksa ukuran file data dan ruang yang digunakan, kemudian memutuskan apakah ukurannya perlu ditingkatkan. Saya juga memantau jejak default untuk peristiwa pertumbuhan, karena ini memberi tahu saya kapan tepatnya pertumbuhan terjadi. Dengan pengecualian database baru, saya selalu dapat menjadi yang terdepan dalam pertumbuhan file otomatis dan menanganinya secara manual. Oke, hampir selalu. Tepat sebelum liburan tahun lalu, saya diberitahu oleh departemen TI pelanggan tentang ruang kosong yang rendah pada drive (tahan pemikiran itu untuk bagian berikutnya). Sekarang, notifikasi didasarkan pada ambang batas kurang dari 20% gratis. Drive ini lebih dari 1TB, jadi ada sekitar 150GB kosong ketika saya memeriksa drive. Itu belum darurat, tapi saya perlu memahami ke mana perginya ruang itu.
Dalam memeriksa file database untuk satu database, saya dapat melihat bahwa mereka penuh – dan bulan sebelumnya setiap file memiliki lebih dari 50GB gratis. Saya kemudian menggali ke dalam ukuran tabel, dan menemukan bahwa dalam satu tabel, lebih dari 270 juta baris telah ditambahkan dalam 16 hari terakhir – dengan total lebih dari 100GB data. Ternyata ada modifikasi kode dan kode baru mencatat lebih banyak informasi daripada yang dimaksudkan. Kami dengan cepat menyiapkan pekerjaan untuk membersihkan baris dan memulihkan ruang kosong di file (dan mereka memperbaiki kodenya). Namun, saya tidak dapat memulihkan ruang disk – saya harus mengecilkan file, dan itu bukan pilihan. Saya kemudian harus menentukan berapa banyak ruang yang tersisa di disk dan memutuskan apakah itu jumlah yang saya rasa nyaman atau tidak. Tingkat kenyamanan saya bergantung pada mengetahui berapa banyak data yang ditambahkan per bulan – tingkat pertumbuhan yang khas. Dan saya hanya tahu berapa banyak data yang ditambahkan karena saya memantau penggunaan file dan dapat memperkirakan berapa banyak ruang yang dibutuhkan untuk bulan ini, untuk tahun ini, dan untuk dua tahun ke depan.
Ruang Berkendara
Saya sebutkan sebelumnya bahwa kami memiliki pekerjaan untuk memantau ruang kosong pada disk. Ini didasarkan pada persentase, bukan jumlah tetap. Aturan umum saya adalah mengirim pemberitahuan ketika kurang dari 10% disk kosong, tetapi untuk beberapa drive, Anda mungkin perlu mengaturnya lebih tinggi. Misalnya, dengan drive 1 TB, saya mendapat pemberitahuan ketika ada kurang dari 100GB gratis. Dengan drive 100GB, saya mendapat pemberitahuan ketika ada kurang dari 10GB gratis. Dengan drive 20GB… yah, Anda tahu ke mana saya akan pergi dengan ini. Ambang batas itu perlu mengingatkan Anda sebelum ada masalah. Jika saya hanya memiliki 10GB gratis pada drive yang menampung file log, saya mungkin tidak memiliki cukup waktu untuk bereaksi sebelum muncul sebagai masalah bagi pengguna – tergantung pada seberapa sering saya memeriksa ruang ukuran bebas dan apa masalahnya adalah.
Sangat mudah menggunakan xp_fixeddrives untuk memeriksa ruang kosong, tetapi saya tidak akan merekomendasikan ini karena tidak didokumentasikan dan penggunaan prosedur tersimpan yang diperluas secara umum telah ditinggalkan. Itu juga tidak melaporkan ukuran total setiap drive, dan mungkin tidak melaporkan semua jenis drive yang mungkin digunakan database Anda. Selama Anda menjalankan SQL Server 2008R2 SP1 atau lebih tinggi, Anda dapat menggunakan sys.dm_os_volume_stats yang jauh lebih nyaman untuk mendapatkan informasi yang Anda butuhkan, setidaknya tentang drive tempat file database ada:
SELECT DISTINCT vs.volume_mount_point AS [Drive], vs.logical_volume_name AS [Drive Name], vs.total_bytes/1024/1024 AS [Drive Size MB], vs.available_bytes/1024/1024 AS [Drive Free Space MB] FROM sys.master_files AS f CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs ORDER BY vs.volume_mount_point;
Saya sering melihat masalah dengan ruang drive pada volume yang meng-host tempdb. Saya telah kehilangan hitungan berapa kali saya memiliki klien dengan pertumbuhan tempdb yang tidak dapat dijelaskan. Terkadang hanya beberapa GB; terbaru itu 200GB. Tempdb adalah binatang yang rumit – tidak ada formula yang harus diikuti saat mengukurnya, dan terlalu sering ditempatkan pada drive dengan sedikit ruang kosong yang tidak dapat menangani kejadian gila yang disebabkan oleh pengembang pemula atau DBA. Mengukur ukuran file data tempdb mengharuskan Anda menjalankan beban kerja untuk siklus bisnis "normal" guna menentukan seberapa banyak menggunakan tempdb, lalu menyesuaikan ukurannya.
Baru-baru ini saya mendengar saran tentang cara untuk menghindari kehabisan ruang pada drive:buat database tanpa data, dan ukuran file sehingga mereka menghabiskan banyak ruang yang ingin Anda "sisihkan." Kemudian, jika Anda mengalami masalah, cukup jatuhkan database dan biola, Anda memiliki ruang kosong lagi. Secara pribadi, saya pikir ini menciptakan semua jenis masalah lain dan tidak akan merekomendasikannya. Tetapi jika Anda memiliki administrator penyimpanan yang tidak suka melihat ratusan GB yang tidak digunakan di drive, ini akan menjadi salah satu cara untuk membuat drive "terlihat" penuh. Itu mengingatkan saya pada sesuatu yang saya dengar seorang teman baik saya berkata:“Jika saya tidak dapat bekerja dengan Anda, saya akan bekerja di sekitar Anda.”
Cadangan
Salah satu tugas utama DBA adalah melindungi data. Cadangan adalah salah satu metode yang digunakan untuk melindunginya, dan dengan demikian, drive yang menyimpan cadangan tersebut merupakan bagian integral dari kehidupan DBA. Agaknya Anda menyimpan satu atau lebih cadangan online, untuk segera memulihkan jika diperlukan. Bantuan menjalankan SLA dan DR Anda menentukan berapa banyak cadangan yang Anda simpan online, dan Anda harus memastikan Anda memiliki ruang yang tersedia. Saya menganjurkan agar Anda juga tidak menghapus cadangan lama sampai pencadangan saat ini berhasil diselesaikan. Terlalu mudah untuk jatuh ke dalam perangkap menghapus cadangan lama, lalu menjalankan cadangan saat ini. Tetapi apa yang terjadi jika pencadangan saat ini gagal? Dan, apa yang terjadi jika Anda menggunakan kompresi? Tunggu sebentar ... cadangan terkompresi lebih kecil kan? Mereka lebih kecil, pada akhirnya. Tapi tahukah Anda bahwa ukuran file .bak biasanya lebih besar dari ukuran akhirnya? Anda dapat menggunakan bendera pelacakan 3042 untuk mengubah perilaku ini, tetapi Anda harus berpikir bahwa dengan pencadangan, Anda memerlukan banyak ruang. Jika cadangan Anda 100GB, dan Anda menyimpan 3 hari secara online, Anda memerlukan 300GB untuk 3 hari pencadangan, dan mungkin jumlah yang sehat (2X ukuran basis data saat ini) gratis untuk cadangan berikutnya. Ya, ini berarti bahwa pada waktu tertentu Anda akan memiliki lebih dari 100GB gratis di drive ini. Tidak apa-apa. Ini lebih baik daripada pekerjaan penghapusan berhasil, dan pekerjaan pencadangan gagal, dan mengetahui tiga hari kemudian Anda tidak memiliki cadangan sama sekali (hal itu pernah terjadi pada pelanggan di pekerjaan saya sebelumnya).
Sebagian besar basis data menjadi lebih besar dari waktu ke waktu, yang berarti cadangan menjadi lebih besar juga. Jangan lupa untuk secara teratur memeriksa ukuran file cadangan dan mengalokasikan ruang tambahan sesuai kebutuhan – memiliki kebijakan “gratis 200GB” untuk database yang telah berkembang menjadi 350GB tidak akan banyak membantu. Jika persyaratan ruang berubah, pastikan untuk mengubah peringatan terkait juga.
Menggunakan Performance Advisor
Ada beberapa pertanyaan yang disertakan dalam posting ini yang dapat Anda gunakan untuk memantau ruang, jika Anda perlu menggulung proses Anda sendiri. Tetapi jika Anda memiliki SQL Sentry Performance Advisor di lingkungan Anda, ini menjadi jauh lebih mudah dengan Custom Conditions. Ada beberapa kondisi stok yang disertakan secara default, tetapi Anda juga dapat membuatnya sendiri.
Di dalam klien SQL Sentry, buka Navigator, klik kanan Shared Groups (Global), dan pilih Add Custom Condition → SQL Sentry. Berikan nama dan deskripsi untuk kondisi tersebut, lalu tambahkan perbandingan numerik, dan ubah jenisnya menjadi Kueri Repositori. Masukkan kueri:
SELECT MIN(FreeSpace*100.0/Size) FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk;
Ubah Sama dengan Kurang dari, dan tetapkan Nilai Eksplisit 10. Terakhir, ubah Frekuensi Evaluasi Default menjadi sesuatu yang lebih jarang daripada setiap 10 detik. Sekali sehari atau sekali setiap 12 jam mungkin merupakan nilai yang baik – Anda tidak perlu memeriksa ruang kosong lebih dari sekali sehari, tetapi Anda dapat memeriksanya sesering yang Anda suka. Tangkapan layar di bawah ini menunjukkan konfigurasi akhir:
Setelah Anda mengklik simpan untuk ketentuan tersebut, Anda akan ditanya apakah Anda ingin menetapkan tindakan untuk ketentuan khusus tersebut. Opsi Kirim ke Saluran Peringatan dipilih secara default, tetapi Anda mungkin ingin melakukan tugas lain, seperti Jalankan Pekerjaan – katakanlah, untuk menyalin cadangan lama ke lokasi lain (jika itu adalah drive dengan ruang kosong).
Seperti yang saya sebutkan sebelumnya, default ruang kosong 10% untuk semua drive mungkin tidak sesuai untuk setiap drive di lingkungan Anda. Anda dapat menyesuaikan kueri untuk berbagai instance dan drive, misalnya:
SELECT Alert = MAX(CASE WHEN Name = N'C:' AND [FreeSpace%] < 10 THEN 1 WHEN Name = N'S:' AND [FreeSpace%] < 25 THEN 1 WHEN Name = N'T:' AND [FreeSpace%] < 20 THEN 1 ELSE 0 END) FROM ( SELECT d.Name, d.FreeSpace * 100.0/d.Size AS [FreeSpace%] FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk AS d INNER JOIN SQLSentry.dbo.EventSourceConnection AS c ON d.DeviceID = c.DeviceID WHERE c.ObjectName = N'HANK\SQL2012' -- replace with your server/instance ) AS s;
Anda dapat mengubah dan memperluas kueri ini seperlunya untuk lingkungan Anda, lalu mengubah perbandingan dalam kondisi yang sesuai (pada dasarnya mengevaluasi ke true jika hasilnya pernah 1):
Jika Anda ingin melihat Performance Advisor beraksi, silakan unduh uji coba.
Perhatikan bahwa untuk kedua kondisi ini, Anda hanya akan diberi tahu satu kali, meskipun beberapa drive berada di bawah ambang batas Anda. Dalam lingkungan yang kompleks, Anda mungkin ingin condong ke sejumlah besar kondisi yang lebih spesifik untuk memberikan peringatan yang lebih fleksibel dan disesuaikan, daripada kondisi "menangkap semua".
Ringkasan
Ada banyak komponen penting dalam lingkungan SQL Server, dan ruang disk adalah salah satu yang perlu dipantau dan dipelihara secara proaktif. Dengan sedikit perencanaan, ini mudah dilakukan, dan ini mengurangi banyak hal yang tidak diketahui dan pemecahan masalah yang reaktif. Baik Anda menggunakan skrip Anda sendiri atau alat pihak ketiga, memastikan ada banyak ruang kosong untuk file database dan pencadangan adalah masalah yang mudah dipecahkan, dan sepadan dengan usaha.
