Membuat file log lebih kecil harus benar-benar dicadangkan untuk skenario di mana ia mengalami pertumbuhan tak terduga yang tidak Anda harapkan terjadi lagi. Jika file log akan bertambah ke ukuran yang sama lagi, tidak banyak yang dapat dilakukan dengan mengecilkannya untuk sementara. Sekarang, tergantung pada tujuan pemulihan database Anda, ini adalah tindakan yang harus Anda ambil.
Pertama, ambil cadangan penuh
Jangan pernah membuat perubahan apa pun pada database Anda tanpa memastikan Anda dapat memulihkannya jika terjadi kesalahan.
Jika Anda peduli dengan pemulihan tepat waktu
(Dan dengan pemulihan point-in-time, maksud saya Anda peduli untuk dapat memulihkan apa pun selain cadangan lengkap atau diferensial.)
Agaknya database Anda dalam FULL mode pemulihan. Jika tidak, maka pastikan:
ALTER DATABASE testdb SET RECOVERY FULL;
Bahkan jika Anda mengambil cadangan penuh secara teratur, file log akan tumbuh dan berkembang sampai Anda melakukan log backup - ini untuk perlindungan Anda, bukan untuk menghabiskan ruang disk Anda dengan sia-sia. Anda harus melakukan pencadangan log ini cukup sering, sesuai dengan tujuan pemulihan Anda. Misalnya, jika Anda memiliki aturan bisnis yang menyatakan bahwa Anda dapat kehilangan data tidak lebih dari 15 menit jika terjadi bencana, Anda harus memiliki pekerjaan yang mencadangkan log setiap 15 menit. Berikut adalah skrip yang akan menghasilkan nama file yang diberi cap waktu berdasarkan waktu saat ini (tetapi Anda juga dapat melakukan ini dengan rencana pemeliharaan dll., hanya saja, jangan memilih salah satu opsi penyusutan dalam rencana pemeliharaan, itu mengerikan).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
Perhatikan bahwa \\backup_share\ harus berada di mesin berbeda yang mewakili perangkat penyimpanan dasar yang berbeda. Mencadangkan ini ke mesin yang sama (atau ke mesin berbeda yang menggunakan disk dasar yang sama, atau VM berbeda yang ada di host fisik yang sama) tidak terlalu membantu Anda, karena jika mesin meledak, Anda kehilangan database dan cadangannya. Bergantung pada infrastruktur jaringan Anda, mungkin lebih masuk akal untuk mencadangkan secara lokal dan kemudian mentransfernya ke lokasi berbeda di belakang layar; dalam kedua kasus, Anda ingin mengeluarkannya dari mesin database utama secepat mungkin.
Sekarang, setelah Anda menjalankan pencadangan log reguler, sebaiknya mengecilkan file log menjadi sesuatu yang lebih masuk akal daripada apa pun yang diledakkan hingga sekarang. Ini tidak berarti menjalankan SHRINKFILE berulang-ulang hingga file log berukuran 1 MB - meskipun Anda sering mencadangkan log, log tetap perlu mengakomodasi jumlah transaksi bersamaan yang dapat terjadi. Peristiwa autogrow file log mahal, karena SQL Server harus menghilangkan file (tidak seperti file data ketika inisialisasi file instan diaktifkan), dan transaksi pengguna harus menunggu saat ini terjadi. Anda ingin melakukan rutinitas grow-shrink-grow-shrink ini sesedikit mungkin, dan Anda tentu tidak ingin membuat pengguna Anda membayarnya.
Perhatikan bahwa Anda mungkin perlu mencadangkan log dua kali sebelum psikiater dapat dilakukan (terima kasih Robert).
Jadi, Anda perlu membuat ukuran praktis untuk file log Anda. Tidak seorang pun di sini dapat memberi tahu Anda apa itu tanpa mengetahui lebih banyak tentang sistem Anda, tetapi jika Anda sering mengecilkan file log dan telah tumbuh lagi, tanda air yang baik mungkin 10-50% lebih tinggi daripada yang terbesar. . Katakanlah itu mencapai 200 MB, dan Anda ingin setiap peristiwa pertumbuhan otomatis berikutnya menjadi 50 MB, maka Anda dapat menyesuaikan ukuran file log dengan cara ini:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
Perhatikan bahwa jika file log saat ini> 200 MB, Anda mungkin perlu menjalankan ini terlebih dahulu:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Jika Anda tidak peduli dengan pemulihan point-in-time
Jika ini adalah database pengujian, dan Anda tidak peduli dengan pemulihan point-in-time, maka Anda harus memastikan bahwa database Anda dalam SIMPLE mode pemulihan.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Menempatkan database dalam SIMPLE mode pemulihan akan memastikan bahwa SQL Server menggunakan kembali bagian dari file log (pada dasarnya menghapus transaksi yang tidak aktif) alih-alih menyimpan catatan semua transaksi (seperti FULL pemulihan tidak sampai Anda membuat cadangan log). CHECKPOINT event akan membantu mengontrol log dan memastikannya tidak perlu bertambah kecuali Anda menghasilkan banyak aktivitas t-log antara CHECKPOINT s.
Selanjutnya, Anda harus benar-benar memastikan bahwa pertumbuhan log ini benar-benar disebabkan oleh peristiwa abnormal (misalnya, pembersihan musim semi tahunan atau membangun kembali indeks terbesar Anda), dan bukan karena penggunaan normal sehari-hari. Jika Anda mengecilkan file log ke ukuran yang sangat kecil, dan SQL Server hanya perlu menumbuhkannya lagi untuk mengakomodasi aktivitas normal Anda, apa yang Anda peroleh? Apakah Anda dapat memanfaatkan ruang disk yang Anda kosongkan hanya untuk sementara? Jika Anda memerlukan perbaikan segera, Anda dapat menjalankan yang berikut ini:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
Jika tidak, tetapkan ukuran dan tingkat pertumbuhan yang sesuai. Sesuai contoh dalam kasus pemulihan point-in-time, Anda dapat menggunakan kode dan logika yang sama untuk menentukan ukuran file yang sesuai dan menetapkan parameter pertumbuhan otomatis yang wajar.
Beberapa hal yang tidak ingin Anda lakukan
-
Cadangkan log dengan
TRUNCATE_ONLYpilihan dan kemudianSHRINKFILE. Pertama,TRUNCATE_ONLYini opsi telah ditinggalkan dan tidak lagi tersedia di versi SQL Server saat ini. Kedua, jika Anda berada diFULLmodel pemulihan, ini akan menghancurkan rantai log Anda dan memerlukan cadangan lengkap yang baru. -
Lepaskan database, hapus file log, dan lampirkan kembali . Saya tidak bisa menekankan betapa berbahayanya ini. Basis data Anda mungkin tidak muncul kembali, mungkin muncul sebagai tersangka, Anda mungkin harus kembali ke cadangan (jika ada), dll. dll.
-
Gunakan opsi "kecilkan basis data" .
DBCC SHRINKDATABASEdan opsi rencana pemeliharaan untuk melakukan hal yang sama adalah ide yang buruk, terutama jika Anda benar-benar hanya perlu menyelesaikan masalah masalah log. Targetkan file yang ingin Anda sesuaikan dan sesuaikan secara independen, menggunakanDBCC SHRINKFILEatauALTER DATABASE ... MODIFY FILE(contoh di atas). -
Perkecil file log menjadi 1 MB . Ini terlihat menggoda karena, hei, SQL Server akan membiarkan saya melakukannya dalam skenario tertentu, dan melihat semua ruang yang dibebaskannya! Kecuali database Anda hanya bisa dibaca (dan memang demikian, Anda harus menandainya menggunakan
ALTER DATABASE), ini benar-benar hanya akan menyebabkan banyak peristiwa pertumbuhan yang tidak perlu, karena log harus mengakomodasi transaksi saat ini terlepas dari model pemulihannya. Apa gunanya mengosongkan ruang itu untuk sementara, agar SQL Server dapat mengambilnya kembali secara perlahan dan menyakitkan? -
Buat file log kedua . Ini akan memberikan bantuan sementara untuk drive yang telah mengisi disk Anda, tetapi ini seperti mencoba memperbaiki paru-paru yang tertusuk dengan plester. Anda harus menangani file log yang bermasalah secara langsung daripada hanya menambahkan masalah potensial lainnya. Selain mengarahkan beberapa aktivitas log transaksi ke drive yang berbeda, file log kedua benar-benar tidak melakukan apa pun untuk Anda (tidak seperti file data kedua), karena hanya satu file yang dapat digunakan dalam satu waktu. Paul Randal juga menjelaskan mengapa beberapa file log dapat menggigit Anda nanti.
Bersikaplah proaktif
Alih-alih mengecilkan file log Anda menjadi sejumlah kecil dan membiarkannya terus tumbuh secara otomatis pada tingkat yang kecil dengan sendirinya, setel ke beberapa ukuran yang cukup besar (yang akan mengakomodasi jumlah kumpulan transaksi bersamaan terbesar Anda) dan atur pertumbuhan otomatis yang wajar ditetapkan sebagai fallback, sehingga tidak harus tumbuh beberapa kali untuk memenuhi transaksi tunggal dan relatif jarang untuk tumbuh selama operasi bisnis normal.
Kemungkinan pengaturan terburuk di sini adalah pertumbuhan 1 MB atau pertumbuhan 10%. Cukup lucu, ini adalah default untuk SQL Server (yang saya keluhkan dan meminta perubahan tetapi tidak berhasil) - 1 MB untuk file data, dan 10% untuk file log. Yang pertama terlalu kecil di zaman sekarang ini, dan yang terakhir mengarah ke peristiwa yang lebih lama dan lebih lama setiap saat (misalnya, file log Anda adalah 500 MB, pertumbuhan pertama adalah 50 MB, pertumbuhan berikutnya adalah 55 MB, pertumbuhan berikutnya adalah 60,5 MB , dll. dll. - dan pada I/O yang lambat, percayalah, Anda akan benar-benar melihat kurva ini).
Bacaan lebih lanjut
Tolong jangan berhenti di sini; sementara banyak saran yang Anda lihat di luar sana tentang mengecilkan file log pada dasarnya buruk dan bahkan berpotensi menimbulkan bencana, ada beberapa orang yang lebih peduli dengan integritas data daripada mengosongkan ruang disk.
Sebuah posting blog yang saya tulis pada tahun 2009, ketika saya melihat beberapa posting "berikut cara mengecilkan file log" bermunculan.
Sebuah posting blog Brent Ozar menulis empat tahun lalu, menunjuk ke beberapa sumber, sebagai tanggapan atas artikel Majalah SQL Server yang tidak telah diterbitkan.
Sebuah posting blog oleh Paul Randal menjelaskan mengapa pemeliharaan t-log itu penting dan mengapa Anda juga tidak boleh mengecilkan file data Anda.
Mike Walsh memiliki jawaban bagus yang mencakup beberapa aspek ini juga, termasuk alasan mengapa Anda mungkin tidak dapat segera mengecilkan file log.
