Mengecilkan Log Transaksi SQL Server


8

Saat ini saya harus berurusan dengan log transaksi SQL Server yang sudah di luar kendali. Penafian: Saya bukan dba dan ini bukan bidang keahlian saya jadi mohon ikut saya.

Saat ini saya memiliki file log Transaksi 115GB untuk database 500MB yang (jelas) telah dikelola dengan buruk selama beberapa waktu untuk mendapatkan status ini.

Prioritas utama adalah untuk mendapatkan kembali ruang pada disk yang diambil oleh file ini sebelum kita kehabisan! Saya telah diberitahu bahwa meningkatkan ukuran drive bukanlah suatu pilihan, bahkan untuk sementara, dan berdasarkan pada pertumbuhan masa lalu, kita perlu segera bertindak.

Seperti yang saya pahami, pendekatan terbaik adalah menjaga db dalam mode pemulihan penuh tetapi mengambil cadangan reguler dari file log, memonitor ini selama periode waktu dan menyesuaikan ukuran awal dan kenaikan sesuai. Baiklah semuanya.

Melihat kami mengambil cadangan db penuh secara teratur pada tengah malam, apakah aman bagi saya untuk sementara menempatkan database ke dalam Mode Pemulihan Sederhana (setelah salah satu dari cadangan ini berjalan), mengecilkan file log untuk mendapatkan kembali (hampir semua) ruang dan lalu masukkan kembali ke Pemulihan Penuh dengan strategi cadangan yang disebutkan di atas?

Pemikiran saya adalah jika sesuatu terjadi sekitar waktu ini, kita dapat dengan mudah mengembalikan cadangan penuh tanpa menggunakan log.

MEMPERBARUI

Beberapa detail tambahan sebagai balasan atas beberapa jawaban dan komentar:

  • Kami ingin mempertahankan kemampuan untuk melakukan pemulihan point-in-time sehingga database harus tetap dalam mode pemulihan penuh.

  • Alasan mengapa file t-log telah tumbuh begitu besar adalah karena itu tidak pernah didukung . Diverifikasi sebagai log_reuse_wait_desc mengembalikan 'LOG_BACKUP'.


Apakah Anda memeriksa setiap transaksi terbuka atau segala jenis tugas ad-hoc atau terjadwal yang akan menyebabkan log transaksi tumbuh sebesar itu? Mengidentifikasi alasannya dapat membantu Anda merencanakan pertumbuhan yang sesuai.
KASQLDBA

Segera setelah Anda beralih ke mode Sederhana, Anda tidak dapat lagi melakukan pemulihan log transaksi melewati titik itu, hingga cadangan lengkap Anda berikutnya. Bahkan jika Anda beralih kembali ke Mode Pemulihan Penuh, pencadangan / pemulihan log transaksi tidak akan mulai berfungsi lagi hingga Anda mengambil cadangan lengkap lainnya. Jadi pastikan untuk mengambil cadangan penuh segera setelah Anda beralih kembali ke pemulihan penuh.
RBarryYoung

Alasan umum untuk file log yang tidak terkendali seperti ini adalah 1) kegagalan untuk mengambil backup penuh reguler, 2) kegagalan untuk mengambil backup log transaksi reguler, atau 3) beberapa pengaturan dalam backup penuh atau log Anda (seperti hanya copy ) yang mencegah tanda cadangan normal diatur.
RBarryYoung

@RBarryYoung Kami telah memverifikasi bahwa itu karena tidak ada cadangan t-log yang diambil. Apakah Anda merekomendasikan melakukan seperti yang saya sarankan pada awalnya tetapi mengambil cadangan lengkap secara langsung setelah mengembalikan db ke pemulihan penuh untuk menghindari masalah yang Anda sebutkan? Sangat penting bagi kami untuk mendapatkan kembali ruang disk secepatnya.
Kraig Walker

AFAIK, tidak ada gunanya berada dalam mode pemulihan penuh jika Anda tidak melakukan pencadangan log. Jika Anda tidak berencana melakukan pencadangan log maka biarkan saja dalam mode sederhana. Cadangan penuh Anda masih akan dapat dipulihkan dengan cara apa pun, Anda baru saja menang; t tidak dapat melakukan pemulihan / roll-forward, tetapi Anda tetap tidak dapat melakukannya tanpa cadangan log.
RBarryYoung

Jawaban:


4

Log transaksi untuk database itu berisi semua transaksi sejak cadangan log transaksi terakhir, atau terakhir kali diaktifkan dari mode pemulihan sederhana. Jalankan berikut ini untuk mendapatkan jawaban pasti mengapa SQL Server tidak dapat memotong log dan selanjutnya mengapa log tumbuh.

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

Jika Anda ingin pemulihan waktu, tinggalkan DB dalam model pemulihan penuh dan sering-seringlah membuat cadangan log. Setiap cadangan log akan berisi semua transaksi sejak cadangan log terakhir. Proses pencadangan log juga bertanggung jawab untuk membersihkan log dan menandai ruang untuk digunakan kembali yaitu transaksi berikutnya yang dibuat dalam DB akan ditulis ke awal log terpotong secara melingkar. Pencadangan dan penggunaan kembali log ini adalah yang mencegah pertumbuhan file log.

Jika Anda tidak tertarik pada titik pemulihan waktu dan ingin menyederhanakan administrasi basis data. Kemudian atur basis data ke model pemulihan sederhana dan jangan mengambil cadangan t-log. SQL Server akan secara otomatis memotong log transaksi setelah setiap transaksi dilakukan. Artinya, begitu transaksi dilakukan ke log, catatan ditimpa oleh transaksi berikutnya, dll.

Either way, setelah Anda membuat salah satu dari dua keputusan ini, Anda kemudian dapat mengecilkan file log ke ukuran yang lebih masuk akal. Perhatikan idealnya Anda ingin membuatnya cukup besar sehingga tidak tumbuh tetapi tidak terlalu besar sehingga Anda harus menyusutkannya lagi. Perhatikan juga bahwa Anda tidak dapat mengecilkan bagian aktif dari log.

Unduh dan gunakan solusi administrasi database https://ola.hallengren.com/ untuk mencakup cadangan, fragmentasi indeks, statistik, dan CHECKDB.

Anda mungkin juga menemukan laporan 'penggunaan disk' dikembalikan dengan mengklik kanan DB di Object Explorer> Laporan> Laporan standar> 'penggunaan disk' berguna untuk mengembalikan ruang kosong di log-t.

Saya juga merekomendasikan kepada Anda Google mengapa sangat penting untuk menjaga rantai log tetap utuh dari sudut pandang DR, dan bagaimana beralih dari penuh ke sederhana memecah rantai sehingga Anda terpapar kehilangan data.


3

Melihat kami mengambil cadangan db penuh secara teratur pada tengah malam, apakah aman bagi saya untuk sementara menempatkan database ke dalam Mode Pemulihan Sederhana (setelah salah satu dari cadangan ini berjalan), mengecilkan file log untuk mendapatkan kembali (hampir semua) ruang dan lalu masukkan kembali ke Pemulihan Penuh dengan strategi cadangan yang disebutkan di atas?

Ya, itu akan aman asalkan Anda tidak mengganggu transaksi ketika Anda melakukan ini, seperti beban larut malam. Secara umum, jika database harus dalam mode pemulihan penuh, Anda ingin cadangan T-Log biasa. Ini akan mengurangi masalah yang Anda hadapi. Saya menulis "secara umum" karena dalam beberapa kasus, saya telah melihat orang mengatur database menjadi penuh tanpa mengetahui mengapa mereka melakukannya. Anggap saja ini bukan kasusnya.

Anda mungkin ingin mempertimbangkan mengapa log adalah ukuran ini relatif terhadap ukuran database. Database 500MB dengan log 116GB tampaknya sangat tidak proporsional untuk acara satu kali. Saya menyarankan untuk memantau apa yang terjadi pada basis data untuk melihat bagaimana ia sampai pada ukuran itu.


Dari apa yang saya mengerti, ini telah berdetak selama enam bulan atau lebih sekarang dengan nol pemeliharaan, karenanya ukurannya. Saya akan melakukan apa yang Anda sarankan dan mengawasi pertumbuhan file begitu saya menyelesaikan masalah segera.
Kraig Walker

Sejujurnya, saya ingin memilih jawaban ini.
jyao

1
Sebenarnya tidak aman untuk beralih dari pemulihan penuh ke sederhana dan kemudian mulai melakukan penyusutan. Dari deskripsi Kraig Walker, saya kira db ini tidak memiliki cadangan t-log untuk suatu saat. Jadi hal pertama yang harus dilakukan adalah memeriksa mode pemulihan db dan apa cadangan tlog terakhir yang dilakukan (jika BUKAN mode pemulihan sederhana). Jika ada cadangan tlog, maka periksa mengapa cadangan tlog tidak menghapus log dengan memeriksa [log_reuse_wait_desc] dari tampilan sys.databases. Pengalaman saya adalah jika mayoritas file log kosong, Anda dapat melakukan menyusut secara langsung.
jyao

@ jyao Tebakan Anda benar, tidak ada cadangan log dan itulah sebabnya file ini sangat besar.
Kraig Walker
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.