Membuat file log lebih kecil harus benar-benar dicadangkan untuk skenario di mana ia mengalami pertumbuhan tak terduga yang Anda tidak harapkan terjadi lagi. Jika file log akan tumbuh dengan ukuran yang sama lagi, tidak terlalu banyak dilakukan dengan menyusutkannya sementara. Sekarang, tergantung pada tujuan pemulihan database Anda, ini adalah tindakan yang harus Anda ambil.
Pertama, ambil cadangan penuh
Jangan pernah melakukan perubahan apa pun pada basis data Anda tanpa memastikan Anda dapat memulihkannya jika terjadi kesalahan.
Jika Anda peduli tentang pemulihan point-in-time
(Dan dengan pemulihan point-in-time, maksud saya Anda peduli untuk dapat memulihkan apa pun selain cadangan penuh atau diferensial.)
Mungkin basis data Anda dalam FULLmode pemulihan. Jika tidak, maka pastikan:
ALTER DATABASE testdb SET RECOVERY FULL;
Bahkan jika Anda mengambil cadangan penuh reguler, file log akan tumbuh dan berkembang sampai Anda melakukan backup log - ini adalah untuk perlindungan Anda, tidak perlu menggerogoti ruang disk Anda. Anda harus melakukan pencadangan log ini cukup sering, sesuai dengan tujuan pemulihan Anda. Misalnya, jika Anda memiliki aturan bisnis yang menyatakan Anda mampu kehilangan tidak lebih dari 15 menit data jika terjadi bencana, Anda harus memiliki pekerjaan yang membuat cadangan log setiap 15 menit. Berikut ini adalah skrip yang akan menghasilkan nama file timestamped berdasarkan waktu saat ini (tetapi Anda juga dapat melakukan ini dengan paket pemeliharaan dll., Jangan pilih opsi menyusut apa pun dalam paket 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;
Catatan yang \\backup_share\harus pada mesin yang berbeda yang mewakili perangkat penyimpanan dasar yang berbeda. Membackup ini ke mesin yang sama (atau ke mesin lain yang menggunakan disk dasar yang sama, atau VM berbeda yang ada di host fisik yang sama) tidak benar-benar membantu Anda, karena jika mesin meledak, Anda telah kehilangan database Anda dan cadangannya. Bergantung pada infrastruktur jaringan Anda, mungkin lebih masuk akal untuk membuat cadangan secara lokal dan kemudian mentransfernya ke lokasi lain di belakang layar; dalam kedua kasus, Anda ingin mengeluarkannya dari mesin basis data utama secepat mungkin.
Sekarang, setelah Anda memiliki cadangan log reguler berjalan, itu harus masuk akal untuk mengecilkan file log menjadi sesuatu yang lebih masuk akal daripada apa pun yang dihancurkan hingga sekarang. Ini tidak berarti berjalan SHRINKFILEberulang-ulang sampai file log adalah 1 MB - bahkan jika Anda sering mencadangkan log, itu masih perlu mengakomodasi jumlah dari setiap transaksi bersamaan yang dapat terjadi. Kejadian autogrow file log itu mahal, karena SQL Server harus menghapus file (tidak seperti file data ketika inisialisasi file instan diaktifkan), dan transaksi pengguna harus menunggu saat ini terjadi. Anda ingin melakukan rutinitas susut-susut-susut sesedikit mungkin, dan Anda tentu tidak ingin membuat pengguna Anda membayar untuk itu.
Perhatikan bahwa Anda mungkin perlu mencadangkan log dua kali sebelum psikiater dimungkinkan (terima kasih Robert).
Jadi, Anda perlu membuat ukuran praktis untuk file log Anda. Tidak ada orang di sini yang dapat memberi tahu Anda apa itu tanpa mengetahui lebih banyak tentang sistem Anda, tetapi jika Anda telah sering menyusutkan 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 acara autogrowth 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 uji, dan Anda tidak peduli tentang pemulihan titik-waktu, maka Anda harus memastikan bahwa database Anda dalam SIMPLEmode pemulihan.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Menempatkan database dalam SIMPLEmode pemulihan akan memastikan bahwa SQL Server menggunakan kembali sebagian dari file log (pada dasarnya menghapus transaksi tidak aktif) alih-alih tumbuh untuk menyimpan catatan semua transaksi (seperti halnya FULLpemulihan hingga Anda membuat cadangan log). CHECKPOINTPeristiwa akan membantu mengendalikan log dan memastikan bahwa itu tidak perlu tumbuh kecuali jika Anda menghasilkan banyak aktivitas t-log antara CHECKPOINTs.
Selanjutnya, Anda harus memastikan sepenuhnya 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 setiap 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 menggunakan ruang disk yang Anda dibebaskan hanya sementara? Jika Anda memerlukan perbaikan segera, maka Anda dapat menjalankan yang berikut:
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, atur ukuran dan tingkat pertumbuhan yang sesuai. Seperti contoh dalam kasus pemulihan point-in-time, Anda dapat menggunakan kode dan logika yang sama untuk menentukan ukuran file apa yang sesuai dan mengatur parameter autogrowth yang masuk akal.
Beberapa hal yang tidak ingin Anda lakukan
Cadangkan log dengan TRUNCATE_ONLYopsi laluSHRINKFILE . Pertama, TRUNCATE_ONLYopsi ini sudah usang dan tidak lagi tersedia di versi SQL Server saat ini. Kedua, jika Anda berada dalam FULLmodel pemulihan, ini akan menghancurkan rantai log Anda dan memerlukan cadangan lengkap baru.
Lepaskan database, hapus file log, dan pasang 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 "shrink database" . 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 mandiri, menggunakan DBCC SHRINKFILEatau ALTER DATABASE ... MODIFY FILE(contoh di atas).
Kecilkan file log ke 1 MB . Ini terlihat menggoda karena, hei, SQL Server akan membiarkan saya melakukannya dalam skenario tertentu, dan lihat semua ruang yang dibebaskannya! Kecuali jika basis data Anda hanya baca (dan itu, Anda harus menandainya menggunakan itu ALTER DATABASE), ini benar-benar hanya akan menyebabkan banyak peristiwa pertumbuhan yang tidak perlu, karena log harus mengakomodasi transaksi saat ini terlepas dari model pemulihan. Apa gunanya membebaskan ruang itu untuk sementara waktu, hanya agar SQL Server dapat mengembalikannya 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 yang tertusuk dengan bantuan pita. Anda harus berurusan dengan file log yang bermasalah secara langsung, bukan hanya menambahkan masalah potensial lainnya. Selain mengarahkan beberapa aktivitas log transaksi ke drive lain, file log kedua benar-benar tidak berguna bagi Anda (tidak seperti file data kedua), karena hanya satu file yang dapat digunakan pada satu waktu. Paul Randal juga menjelaskan mengapa banyak file log dapat menggigit Anda nanti .
Bersikap proaktif
Alih-alih mengecilkan file log Anda ke sejumlah kecil dan membiarkannya terus-menerus autogrow dengan harga kecil sendiri, atur ke beberapa ukuran yang cukup besar (yang akan mengakomodasi jumlah set transaksi bersamaan terbesar Anda) dan tetapkan autogrow yang masuk akal menetapkan sebagai mundur, sehingga tidak harus tumbuh beberapa kali untuk memuaskan transaksi tunggal dan sehingga akan relatif jarang untuk itu harus tumbuh selama operasi bisnis normal.
Pengaturan terburuk yang mungkin terjadi di sini adalah pertumbuhan 1 MB atau pertumbuhan 10%. Cukup lucu, ini adalah default untuk SQL Server (yang saya keluhkan dan minta perubahan tidak berhasil ) - 1 MB untuk file data, dan 10% untuk file log. Yang pertama jauh terlalu kecil di hari ini dan usia, dan yang terakhir mengarah ke acara yang lebih lama setiap kali (katakanlah, file log Anda adalah 500 MB, pertumbuhan pertama adalah 50 MB, pertumbuhan berikutnya adalah 55 MB, pertumbuhan berikutnya adalah 60,5 MB , dll. - dan pada I / O lambat, percayalah, Anda akan benar-benar memperhatikan kurva ini).
Bacaan lebih lanjut
Tolong jangan berhenti di sini; sementara banyak saran yang Anda lihat di sana tentang menyusutkan file log secara inheren buruk dan bahkan berpotensi bencana, ada beberapa orang yang lebih peduli tentang integritas data daripada membebaskan ruang disk.
Sebuah posting blog yang saya tulis pada tahun 2009, ketika saya melihat beberapa posting "inilah cara mengecilkan file log" muncul .
Sebuah posting blog Brent Ozar menulis empat tahun lalu, menunjuk ke banyak sumber, sebagai tanggapan terhadap artikel Majalah SQL Server yang seharusnya tidak dipublikasikan .
Sebuah posting blog oleh Paul Randal menjelaskan mengapa pemeliharaan t-log penting dan mengapa Anda juga tidak perlu mengecilkan file data Anda .
Mike Walsh memiliki jawaban yang bagus yang mencakup beberapa aspek ini juga, termasuk alasan mengapa Anda mungkin tidak dapat segera mengecilkan file log Anda .
