Menjalankan perintah DBCC Shrink adalah masalah yang cukup kontroversial di komunitas SQL Server. Dalam artikel ini, kami akan meninjau detail tentang perintah ini dan memberikan gambaran singkat tentang penggunaannya dan juga memperingatkan Anda tentang risiko menjalankan perintah ini. Sebagai DBA, sejumlah database diserahkan dari tim atau vendor lain, dan tidak selalu kita dapat mengelola database yang kita buat. Sebagai DBA, setiap kali kita terlibat dalam migrasi atau proyek baru, kita perlu memastikan bahwa kita merencanakan transisi yang mulus dari database ke produksi dan penggunaan reguler dengan hati-hati. Pada tahap inilah kita perlu memperhitungkan ukuran database. Dapatkah Anda bayangkan, Anda membuat aplikasi database tanpa mempertimbangkan perkiraan pertumbuhan untuk tahun pertama atau lebih. Bagaimana kalau Anda membuat database SQL Server dengan ukuran sangat kecil sehingga perlu bertambah setiap hari meningkatkan peringatan kapasitas disk di tengah malam? Ini mungkin terdengar konyol, tetapi kenyataannya, hal ini terjadi, dan terkadang hal ini tidak dapat Anda kendalikan.
Beberapa poin yang perlu dipertimbangkan untuk DBA Proaktif
Sebelum mengambil alih dukungan basis data produksi, pastikan untuk memeriksa dengan pendahulu Anda tentang perkiraan pertumbuhan basis data. Apakah ukuran awal database yang akan Anda kelola cukup besar? Jangan terlalu khawatir jika ukuran database saat ini jauh lebih besar dari data yang dimilikinya saat ini. Ingat, Anda tidak ingin panggilan kapasitas disk itu pada pukul 3:00 pagi ketika Anda sebenarnya bisa menghindarinya dengan memiliki database berukuran benar. Ini adalah tren umum bagi administrator database di seluruh industri untuk mengorbankan hidup mereka larut malam pada isu-isu duniawi yang seharusnya tidak terjadi di tempat pertama. Juga, bersama dengan ukuran basis data, ingatlah kapasitas disk server. Anda tidak ingin ukuran disk menjadi terlalu kecil daripada yang dapat ditampung oleh database. Ini semua adalah hal-hal sederhana yang berguna pada saat perencanaan. Namun, seperti yang Anda ketahui, tidak selalu profesional database yang menginstal atau mengonfigurasi database sejak awal. Poin penting yang perlu diperhatikan adalah untuk mendapatkan dasar-dasar yang benar dengan database Anda dalam hal ukuran dan Anda mungkin tidak perlu menjalankan perintah ini. Namun, seperti biasa, sebagai DBA, ada kalanya hal-hal mungkin tidak berada dalam kendali Anda dan selama waktu ini Anda dapat menggunakan perintah file DBCC Shrink untuk penggunaan yang efisien.
Kapan saya bisa menggunakan DBCC ShrinkFile?
Anda baru saja menerima peringatan ruang disk tepat di tengah tidur Anda dan Anda harus memenuhi SLA yang ketat. Tingkat prioritas adalah P2 dan SLA dapat segera dilanggar. Dan Anda menyadari bahwa memperluas disk tidak akan terjadi dalam waktu dekat, baik, dalam hal ini, simpan perintah DBCC ShrinkFile Anda agar Anda dapat menggunakannya untuk merebut kembali ruang. Seperti namanya, itu mengecilkan file data atau file log database. Namun sebelum Anda mulai menjalankan perintah DBCC ShrinkFile, coba periksa dulu mengapa file database tumbuh.
- Apakah file bertambah karena beberapa transaksi yang berjalan lama?
- Apakah ada pemblokiran di server?
- Apakah ada rilis aplikasi besar yang belum Anda ketahui? (Ini paling sering terjadi)
- Apakah ada masalah replikasi basis data atau pencerminan yang menyebabkan pertumbuhan basis data?
Penting untuk mendapatkan jawaban atas pertanyaan-pertanyaan ini secepat mungkin. Umumnya, ada satu jawaban untuk semua pertanyaan ini dan itu adalah alat gratis hebat yang disebut sp_whoisactive. Tidak ada kata-kata untuk menggambarkan penggunaan besar alat ini dan saya telah menggunakannya beberapa kali untuk memperbaiki banyak masalah terkait produksi. Anda dapat mengunduh kode terbaru dari tautan ini:http://whoisactive.com/ . Mudah dan sederhana untuk digunakan dan mengembalikan output dalam waktu singkat. Jika Anda adalah DBA berpengalaman, Anda sudah memilikinya.
DBCC ShrinkFile dengan contoh
Sintaks untuk DBCC ShrinkFile sederhana dan mudah, lihat contoh di bawah ini.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Contoh di atas mengecilkan FileName milik YOURDATABASE menjadi 1024 MB. Anda dapat melakukan operasi yang sama menggunakan SQL Server Management Studio (SSMS). Klik kanan database, buka Tugas , pilih Perkecil , lalu File .
Setelah Anda mengeklik File , Anda akan mendapatkan jendela ini.
Di sini, Anda memiliki opsi untuk memilih jenis file:Data, Log atau Filestream Data dan lakukan "Shrink action" sesuai kebutuhan. Lebih mudah menggunakan perintah DBCC itu sendiri untuk tujuan menyusut.
Menggunakan DBCC ShrinkFile dengan opsi tambahan
Anda dapat menjalankan perintah DBCC ShrinkFile dengan opsi tambahan – emptyfile, notruncate atau truncateonly.
File Kosong
Anda dapat menggunakan perintah file kosong seperti di bawah ini.
use YOURDATABASE go dbcc shrinkfile(FileName,emptyfile)
Ini akan membantu memindahkan data ke file lain dalam grup file yang sama. Setelah selesai, Anda akan dapat menghapus file database jika tidak lagi diperlukan. Namun, ada beberapa hal yang perlu diperhatikan dengan opsi file kosong ini karena Anda tidak akan dapat berbuat banyak untuk mengosongkan konten file data primer dengan ID file 1. Untuk mendapatkan nomor ID file, jalankan skrip ini.
select file_id, name,physical_name from sys.database_files
Di sini, dalam contoh ini, nama filenya adalah “mo” dan file_id adalah 1. Saat Anda mencoba mengosongkan file mo yang memiliki file_id 1, Anda akan menemukan pesan kesalahan ini.
Ini karena ada informasi sistem di dalam file asli, yang tidak dapat dikosongkan. Namun, jika Anda mencoba perintah yang sama pada file data lain “mo2data”, perintah file kosong akan berhasil.
Tidak dijalankan
Seperti namanya, tidak ada ruang yang dilepaskan kembali ke OS. Ini lebih seperti operasi internal di dalam file di mana halaman didistribusikan kembali di dalam file itu sendiri tanpa mengubah ukuran keseluruhan file database. Karena itu, ada kemungkinan besar untuk terjadinya fragmentasi. Lihat contoh di bawah.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,notruncate); GO
Terpotong saja
Seperti namanya, ruang kosong akan dilepaskan kembali ke OS dari akhir file. Sejauh ini, ini adalah operasi teraman yang dapat Anda jalankan menggunakan DBCC ShrinkFile. Lihat contoh di bawah.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,truncateonly); GO
Apa yang harus dilakukan ketika DBCC ShrinkFile pada log transaksi tidak berfungsi seperti yang diharapkan? Lihat metode aman ini untuk memperbaiki masalah
Ada kalanya perintah ini mungkin tidak berfungsi seperti yang diharapkan. Dengan asumsi Anda memiliki situasi di mana Anda mencoba untuk mengecilkan file log dari database dan tampaknya tidak berhasil. Berikut adalah beberapa langkah yang dapat Anda ambil untuk memahami mengapa psikiater tidak bekerja seperti yang diharapkan. Anda akan melihat bahwa file menyusut akan ditampilkan sebagai berhasil, namun, tidak ada pengurangan ukuran file log. Dalam hal ini, jalankan perintah ini untuk memeriksa beberapa hal tentang penggunaan file log.
select name,log_reuse_wait_desc,* from sys.databases
Dari tangkapan layar, Anda dapat melihat bahwa kolom log_reuse_wait_desc sedang menunggu di pencadangan log.
Di sini, Anda dapat melihat bahwa pencadangan log untuk database perlu dilakukan sebelum Anda benar-benar dapat mengecilkan file log. Jika ini ada di database produksi, coba lakukan pencadangan log di drive lain yang tersedia ruang. Untuk melakukan pencadangan log, gunakan contoh perintah di bawah ini.
backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn' with init,stats,compression
Setelah Anda menjalankan perintah backup, jalankan kembali perintah di bawah ini untuk melihat status kolom log_reuse_wait_desc.
select name,log_reuse_wait_desc,* from sys.databases
Dari tangkapan layar, Anda dapat melihat bahwa status kolom log_reuse_wait_desc telah berubah menjadi “Tidak Ada”.
Di sini, Anda dapat melihat bahwa status untuk kolom “log_reuse_wait_desc” telah berubah menjadi “Tidak Ada”. Dalam kasus Anda, itu mungkin masih ditampilkan sebagai "LOG_BACKUP". Lanjutkan untuk melakukan pencadangan log untuk database hingga status berubah menjadi "Tidak Ada". Alasan Anda mungkin masih melihat status “LOG_BACKUP” bahkan setelah melakukan pencadangan log transaksi adalah karena tidak ada VLF yang mungkin telah dihapus setelah Anda menjalankan pencadangan log transaksi. VLF adalah singkatan dari Virtual log files dan merupakan bagian dari arsitektur internal log transaksi. File log transaksi terdiri dari VLF ini. Anda bisa mendapatkan informasi tentang VLF dengan menjalankan perintah ini.
select * from sys.dm_db_log_info(5)
Di sini 5 mewakili database_id. Tangkapan layar output ditampilkan. Jumlah baris yang dikembalikan mewakili jumlah sebenarnya dari file log Virtual (VLF) dalam database. Anda dapat memeriksa kolom “vlf_status” untuk memeriksa status file log virtual. Nilai 2 berarti aktif. Dengan perintah ini, Anda dapat memeriksa tanda internal dalam file log transaksi untuk memahami mengapa log transaksi tidak dibebaskan bahkan setelah melakukan pencadangan log.
Sebelumnya, perintah yang digunakan adalah DBCC LOGINFO yang memberikan informasi serupa.
Apa yang harus dilakukan ketika DBCC ShrinkFile pada log transaksi tidak berfungsi seperti yang diharapkan? Sesuatu yang dapat Anda lakukan di lingkungan non-prod. Namun, tidak disarankan pada lingkungan produksi
Anda akan menemukan di beberapa situs web yang merekomendasikan untuk mengubah model pemulihan menjadi yang sederhana dan kemudian menjalankan file menyusut untuk melepaskan ruang kembali ke OS. Ingatlah bahwa mengubah model pemulihan menjadi yang sederhana akan memengaruhi pemulihan basis data Anda karena Anda tidak akan dapat memulihkan ke titik waktu tertentu. Ini sekali lagi tergantung pada SLA bisnis Anda. Anda dapat mengubah model pemulihan menggunakan T-SQL (di bawah) atau menggunakan GUI.
alter database DB_NAME set recovery simple
Menggunakan GUI, ubah model pemulihan seperti yang ditunjukkan. Klik kanan database, buka "Properties", klik "Options". Di bawah “Opsi”, pilih “Model Pemulihan”.
Anda akan melihat bahwa hanya mengubah model pemulihan ke Sederhana tidak akan melepaskan ruang kembali ke OS. Anda perlu menjalankan perintah DBCC ShrinkFile secara eksplisit untuk mengecilkan file dan mendapatkan kembali ruang. Lihat contoh skrip di bawah ini. Perintah ini akan mengecilkan FileName Anda menjadi 1024 MB.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Opsi basis data Kecilkan Otomatis
Anda akan melihat bahwa ada opsi yang dikenal sebagai "Penyusutan Otomatis" di dalam properti database. Cukup klik kanan database untuk melihat properti database. Di bawah bagian opsi, Anda akan melihat opsi ini seperti yang ditunjukkan. Dari pengaturan basis data model, Anda dapat melihat bahwa opsi "Penyusutan Otomatis" dinonaktifkan secara default. Jadi, setiap kali database baru dibuat, opsi ini juga dalam status dinonaktifkan. Mungkin ada beberapa kasus di mana profesional database tanpa sadar membiarkan opsi ini diaktifkan tanpa menyadari konsekuensi negatif dari membiarkannya aktif.
Jalankan perintah ini untuk memeriksa status opsi ini untuk database di server.
select name,is_auto_shrink_on,* from sys.databases
Anda akan melihat keluaran ini.
Jika kebetulan, Anda melihat bahwa itu diaktifkan, Anda dapat menonaktifkannya baik dengan menggunakan GUI atau Anda dapat menjalankan perintah di bawah ini terhadap database.
ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF
Saran pemeliharaan lainnya
Lihat beberapa tip tambahan ini untuk menghindari masalah pertumbuhan basis data, yang karenanya Anda perlu menjalankan perintah DBCC ShrinkFile.
- Pastikan model pemulihan database Anda selaras dengan SLA bisnis. Jika bisnis Anda tidak memerlukan pemulihan tepat waktu untuk database pengujian, biarkan saja dalam model pemulihan sederhana. Saya telah melihat beberapa kali di mana model pemulihan database selesai ketika semuanya baik-baik saja dengan pemulihan menggunakan cadangan lengkap terbaru
- Pastikan pemantauan yang tepat, terutama dengan pertumbuhan basis data. Anda harus diperingatkan ketika pemanfaatan file log mencapai 85%. Ini akan memberi Anda waktu untuk menyelesaikan masalah ruang
- Pastikan pencadangan log reguler dibuat jika basis data dalam model pemulihan penuh dan Anda harus diberi tahu jika ada pencadangan log yang gagal
- Pastikan ada cukup ruang pada drive basis data untuk menghindari masalah kekurangan ruang
- Untuk database yang bisa diarsipkan, kembangkan beberapa strategi arsip sehingga Anda bisa memindahkan data lama ke database lain untuk membuat laporan dan membuat database itu hanya-baca. Ini akan memberi Anda lebih banyak kontrol dalam hal ukuran basis data
- Pastikan untuk melakukan pemeriksaan integritas secara rutin pada database Anda menggunakan DBCC CheckDB. Untuk informasi lebih lanjut, lihat artikel ini:https://codingsight.com/dbcc-checkdb-overview/
Kesimpulan
- Dari artikel ini, Anda mendapatkan pemahaman yang baik tentang penggunaan perintah DBCC ShrinkFile
- Anda telah mempelajari tentang risiko menjalankan perintah DBCC ShrinkFile
- Anda telah mempelajari berbagai opsi yang dapat kami sediakan menggunakan perintah DBCC ShrinkFile
- Anda melihat opsi yang dapat kami coba jika log transaksi tidak menyusut menggunakan perintah DBCC ShrinkFile
- Anda telah mempelajari tentang setelan penciutan otomatis default dalam properti database
- Anda juga mempelajari saran pemeliharaan database lainnya untuk menjaga database Anda tetap sehat
- Terakhir, pastikan untuk siap dalam hal apa pun untuk hari-hari LIBUR yang mungkin tidak berada dalam kendali Anda
