it-swarm.asia

Mengapa Log Transaksi Terus Berkembang atau Kehabisan Ruang?

Yang ini tampaknya menjadi pertanyaan umum di sebagian besar forum dan di seluruh web, ditanyakan di sini dalam banyak format yang biasanya terdengar seperti ini:

Dalam SQL Server -

  • Apa alasan mengapa log transaksi tumbuh begitu besar?
  • Mengapa file log saya sangat besar?
  • Apa sajakah cara untuk mencegah masalah ini terjadi?
  • Apa yang harus saya lakukan ketika saya berada di jalur dengan penyebab yang mendasarinya dan ingin menempatkan file log transaksi saya ke ukuran yang sehat?
271
Mike Walsh

Jawaban Singkat:

Anda mungkin memiliki transaksi berjalan yang berjalan lama (Pemeliharaan indeks? Penghapusan atau pembaruan batch besar?) Atau Anda berada dalam mode pemulihan "default" (lebih lanjut tentang apa yang dimaksud secara default) dari Full dan belum mengambil cadangan log (atau tidak cukup sering mengambilnya).

Jika ini adalah masalah model pemulihan, jawaban sederhana bisa menjadi Beralih ke mode pemulihan Simple jika Anda tidak perlu pemulihan waktu dan pencadangan log reguler. Namun, banyak orang membuat jawaban mereka tanpa memahami model pemulihan. Baca terus untuk memahami mengapa itu penting dan kemudian putuskan apa yang Anda lakukan. Anda juga bisa mulai mengambil cadangan log dan tetap dalam pemulihan Full.

Mungkin ada alasan lain tetapi ini adalah yang paling umum. Jawaban ini mulai masuk ke dalam dua alasan paling umum dan memberi Anda beberapa informasi latar belakang tentang mengapa dan bagaimana di balik alasan serta mengeksplorasi beberapa alasan lainnya.


Jawaban yang Lebih Panjang: Skenario apa yang dapat menyebabkan log tetap Tumbuh? Ada banyak alasan, tetapi biasanya alasan-alasan ini dari dua pola berikut: Ada kesalahpahaman tentang model pemulihan atau ada transaksi jangka panjang. Baca terus untuk detailnya.

Alasan utama 1/2: Tidak Memahami Model Pemulihan

( Berada di Mode Pemulihan Penuh dan Tidak Mengambil Cadangan Cadangan - Ini adalah alasan paling umum - sebagian besar yang mengalami masalah ini adalah. )

Sementara jawaban ini bukan menyelam dalam model pemulihan SQL Server, topik model pemulihan sangat penting untuk masalah ini.

Di SQL Server, ada tiga model pemulihan :

  • Full,
  • Bulk-Logged Dan
  • Simple.

Kami akan mengabaikan Bulk-Logged Untuk saat ini kami akan mengatakan bahwa ini adalah model hybrid dan kebanyakan orang yang ada dalam model ini ada karena suatu alasan dan memahami model pemulihan.

Dua yang kami pedulikan dan kebingungan mereka adalah penyebab mayoritas kasus orang yang mengalami masalah ini adalah Simple dan Full.

Intermission: Pemulihan secara umum

Sebelum kita berbicara tentang Model Pemulihan: mari kita bicara tentang pemulihan secara umum. Jika Anda ingin lebih dalam dengan topik ini, baca saja blog Paul Randal dan sebanyak mungkin posting yang Anda inginkan. Namun untuk pertanyaan ini:

  1. Crash/Restart Recovery
    Salah satu tujuan file log transaksi adalah untuk pemulihan crash/restart. Untuk rolling forward dan rolling back pekerjaan yang dilakukan (rolling forward/redo) sebelum crash atau restart dan pekerjaan yang dimulai tetapi tidak selesai setelah crash atau restart (rolling back/undo). Adalah tugas log transaksi untuk melihat bahwa suatu transaksi dimulai tetapi tidak pernah selesai (dibatalkan atau macet/restart terjadi sebelum transaksi dilakukan). Dalam situasi itu, adalah tugas log untuk mengatakan "Hei .. ini tidak pernah benar-benar selesai, mari putar kembali" selama pemulihan. Ini juga tugas log untuk melihat bahwa Anda menyelesaikan sesuatu dan bahwa aplikasi klien Anda diberitahu sudah selesai (bahkan jika belum diperkeras ke file data Anda) dan berkata "Hei .. ini benar-benar terjadi , mari kita putar ke depan, mari kita buat seperti aplikasi pikir itu " setelah restart. Sekarang ada lebih banyak tetapi itu adalah tujuan utama.

  2. Poin dalam Pemulihan Waktu
    Tujuan lain dari file log transaksi adalah untuk dapat memberi kami kemampuan untuk memulihkan ke titik waktu karena "oops" dalam database atau untuk menjamin titik pemulihan jika terjadi kegagalan perangkat keras yang melibatkan data dan/atau file log dari database. Jika log transaksi ini berisi catatan transaksi yang telah dimulai dan selesai untuk pemulihan, SQL Server dapat dan kemudian menggunakan informasi ini untuk mendapatkan database ke tempat sebelum masalah terjadi. Tetapi itu tidak selalu merupakan pilihan yang tersedia untuk kita. Agar itu berfungsi, kita harus memiliki database kita di kanan model pemulihan, dan kita harus mengambil pencadangan log.

Model Pemulihan

Ke model pemulihan:

  • Model Pemulihan Sederhana
    Jadi dengan pendahuluan di atas, paling mudah untuk membicarakan tentang model Simple Recovery Terlebih dahulu. Dalam model ini, Anda memberi tahu SQL Server: "Saya baik-baik saja dengan Anda menggunakan file log transaksi Anda untuk kerusakan dan memulai kembali pemulihan ..." (Anda benar-benar tidak punya pilihan di sana. Lihat - properti ACID dan itu seharusnya masuk akal dengan cepat.) "... tapi begitu Anda tidak lagi membutuhkannya untuk tujuan pemulihan kerusakan/restart, silakan dan gunakan kembali file log."

    SQL Server mendengarkan permintaan ini di Simple Recovery dan hanya menyimpan informasi yang diperlukan untuk melakukan crash/restart recovery. Setelah SQL Server yakin dapat pulih karena data dikeraskan ke file data (kurang lebih), data yang telah dikeraskan tidak lagi diperlukan dalam log dan ditandai untuk pemotongan - yang berarti akan digunakan kembali.

  • Model Pemulihan Penuh
    Dengan Full Recovery, Anda memberi tahu SQL Server bahwa Anda ingin dapat memulihkan ke titik waktu tertentu, selama file log Anda tersedia atau ke titik waktu tertentu yaitu dicakup oleh cadangan log. Dalam hal ini ketika SQL Server mencapai titik di mana aman untuk memotong file log dalam Model Pemulihan Sederhana, itu tidak akan melakukan itu. Sebaliknya Ini memungkinkan file log terus tumbuh dan akan membuatnya terus bertambah, hingga Anda ambil cadangan log (atau kehabisan ruang pada drive file log Anda) dalam keadaan normal.

Beralih dari Sederhana ke Penuh memiliki Gotcha.

Ada aturan dan pengecualian di sini. Kita akan berbicara tentang transaksi jangka panjang di kedalaman di bawah ini.

Tetapi satu peringatan yang perlu diingat untuk Mode Pemulihan Penuh adalah ini: Jika Anda hanya beralih ke mode Full Recovery, Tetapi jangan pernah mengambil Cadangan Penuh awal, SQL Server akan tidak hormati permintaan Anda untuk menjadi model Full Recovery. Log transaksi Anda akan terus beroperasi seperti di Simple hingga Anda beralih ke Model Pemulihan Lengkap DAN ambil Full Backup Pertama Anda.

Model Pemulihan Penuh tanpa cadangan log buruk.

Jadi, apa alasan paling umum untuk pertumbuhan kayu bulat yang tidak terkendali? Jawab: Berada di Mode Pemulihan Penuh tanpa memiliki cadangan log.

Ini terjadi semua waktu kepada orang-orang.

Mengapa ini merupakan kesalahan umum?

Mengapa itu selalu terjadi? Karena setiap basis data baru mendapatkan pengaturan model pemulihan awal dengan melihat basis data model.

Pengaturan model pemulihan awal Model selalu Full Recovery Model - sampai dan kecuali seseorang mengubahnya. Jadi Anda bisa mengatakan "Model Pemulihan default" adalah Full. Banyak orang tidak menyadari hal ini dan memiliki basis data mereka berjalan di Full Recovery Model Tanpa cadangan log, dan karenanya file log transaksi jauh lebih besar dari yang diperlukan. Inilah sebabnya mengapa penting untuk mengubah default ketika mereka tidak bekerja untuk organisasi Anda dan kebutuhannya)

Model Pemulihan Penuh dengan terlalu sedikit cadangan log buruk.

Anda juga bisa mendapatkan masalah di sini dengan tidak cukup sering mengambil cadangan log.
Mengambil cadangan log sehari mungkin terdengar baik, itu membuat pemulihan memerlukan lebih sedikit mengembalikan perintah, tetapi mengingat diskusi di atas, file log itu akan terus tumbuh dan tumbuh sampai Anda mengambil cadangan log.

Bagaimana cara mengetahui frekuensi cadangan log apa yang saya butuhkan?

Anda perlu mempertimbangkan frekuensi cadangan log dengan dua hal yang perlu diperhatikan:

  1. Kebutuhan Pemulihan - Semoga ini menjadi yang pertama. Jika drive perumahan log transaksi Anda memburuk atau Anda mendapatkan korupsi serius yang mempengaruhi cadangan log Anda, berapa banyak data yang bisa hilang? Jika angka itu tidak lebih dari 10-15 menit, maka Anda harus mengambil cadangan log setiap 10-15 menit, akhir dari diskusi.
  2. Pertumbuhan Log - Jika organisasi Anda baik-baik saja kehilangan lebih banyak data karena kemampuan untuk dengan mudah membuat ulang hari itu, Anda mungkin baik-baik saja untuk membuat cadangan log lebih sedikit sering dari 15 menit. Mungkin organisasi Anda baik-baik saja setiap 4 jam. Tetapi Anda harus melihat berapa banyak transaksi yang Anda hasilkan dalam 4 jam. Apakah membiarkan log untuk terus tumbuh dalam empat jam itu membuat file log terlalu besar? Apakah itu berarti cadangan log Anda terlalu lama?

Alasan utama 2/2: Transaksi Berlari Panjang

( "Model pemulihan saya baik-baik saja! Lognya masih tumbuh! )

Ini juga bisa menjadi penyebab pertumbuhan log yang tidak terkendali dan tidak terkendali. Tidak masalah model pemulihan, tetapi sering muncul sebagai "Tapi saya dalam Model Pemulihan Sederhana - mengapa log saya masih tumbuh?!"

Alasannya sederhana: jika SQL menggunakan log transaksi ini untuk tujuan pemulihan seperti yang saya jelaskan di atas, maka SQL harus melihat kembali ke awal transaksi.

Jika Anda memiliki transaksi yang membutuhkan waktu lama atau melakukan banyak perubahan, log tidak dapat memotong pada pos pemeriksaan untuk setiap perubahan yang masih dalam transaksi terbuka atau yang telah dimulai sejak transaksi itu dimulai.

Ini berarti bahwa penghapusan besar, penghapusan jutaan baris dalam satu pernyataan penghapusan adalah satu transaksi dan log tidak dapat melakukan pemotongan sampai seluruh penghapusan itu dilakukan. Dalam Full Recovery Model, Penghapusan ini dicatat dan itu mungkin banyak catatan log. Hal yang sama dengan pengoptimalan Indeks berfungsi selama jendela pemeliharaan. Ini juga berarti manajemen transaksi yang buruk dan tidak mengawasi dan menutup transaksi terbuka dapat benar-benar melukai Anda dan file log Anda.

Apa yang bisa saya lakukan dengan transaksi jangka panjang ini?

Anda dapat menyelamatkan diri Anda di sini dengan:

  • Mengubah ukuran file log Anda dengan benar untuk skenario terburuk - seperti perawatan Anda atau operasi besar yang diketahui. Dan ketika Anda menumbuhkan file log Anda, Anda harus melihat ini bimbingan (dan dua tautan yang ia kirimkan kepada Anda) oleh Kimberly Tripp. Ukuran yang tepat sangat penting di sini.
  • Menonton penggunaan transaksi Anda. Jangan memulai transaksi di server aplikasi Anda dan mulai mengobrol panjang dengan SQL Server dan berisiko membiarkannya terbuka terlalu lama.
  • Menonton transaksi tersirat dalam laporan DML Anda. Misalnya: UPDATE TableName Set Col1 = 'New Value' Adalah transaksi. Saya tidak menaruh BEGIN TRAN Di sana dan saya tidak harus, itu masih satu transaksi yang secara otomatis dilakukan ketika selesai. Jadi, jika melakukan operasi pada sejumlah besar baris, pertimbangkan untuk menumpuk operasi itu menjadi potongan yang lebih mudah dikelola dan memberikan waktu log untuk pulih. Atau pertimbangkan ukuran yang tepat untuk menghadapinya. Atau mungkin melihat ke perubahan model pemulihan selama jendela beban massal.

Apakah kedua alasan ini juga berlaku untuk Pengiriman Log?

Jawaban singkat: ya. Jawaban yang lebih panjang di bawah.

Pertanyaan: "Saya menggunakan pengiriman log, jadi cadangan log saya otomatis ... Mengapa saya masih melihat pertumbuhan log transaksi?"

Jawab: baca terus.

Apa itu Pengiriman Log?

Log pengiriman seperti apa kedengarannya - Anda mengirim cadangan log transaksi Anda ke server lain untuk tujuan DR. Ada beberapa inisialisasi tetapi setelah itu prosesnya cukup sederhana:

  • Pekerjaan untuk mencadangkan log di satu server,
  • pekerjaan untuk menyalin cadangan log itu dan
  • pekerjaan untuk mengembalikannya tanpa pemulihan (baik NORECOVERY atau STANDBY) di server tujuan.

Ada juga beberapa pekerjaan untuk dipantau dan waspada jika semuanya tidak berjalan sesuai rencana Anda.

Dalam beberapa kasus, Anda mungkin hanya ingin melakukan pengembalian pengiriman log sekali sehari atau setiap hari ketiga atau sekali seminggu. Ini baik saja. Tetapi jika Anda melakukan perubahan ini pada semua pekerjaan (termasuk cadangan log dan salin pekerjaan) itu berarti Anda menunggu sepanjang waktu untuk mengambil cadangan log. Itu berarti Anda akan memiliki banyak pertumbuhan log - karena Anda dalam mode pemulihan penuh tanpa cadangan log - dan itu mungkin juga berarti file log besar untuk disalin. Anda hanya harus mengubah jadwal pemulihan pekerjaan dan membiarkan pencadangan dan salinan log terjadi lebih sering, jika tidak, Anda akan mengalami masalah pertama yang dijelaskan dalam jawaban ini.


Pemecahan masalah umum melalui kode status

Ada alasan lain selain keduanya, tetapi ini adalah yang paling umum. Terlepas dari penyebabnya: ada cara Anda dapat menganalisis alasan Anda atas pertumbuhan log yang kurang jelas/kurangnya pemotongan ini dan melihat apa itu.

Dengan menanyakan sys.databases tampilan katalog Anda dapat melihat informasi yang menjelaskan alasan file log Anda menunggu pada truncate/reuse.

Ada kolom yang disebut log_reuse_wait Dengan ID pencarian kode alasan dan kolom log_reuse_wait_desc Dengan deskripsi alasan menunggu. Dari artikel buku yang direferensikan secara online adalah sebagian besar alasan (alasan yang cenderung Anda lihat dan alasan yang dapat kami jelaskan alasannya. Yang hilang tidak digunakan atau untuk penggunaan internal) dengan beberapa catatan tentang menunggu di huruf miring:

  • 0 = Tidak Ada
    Seperti apa rasanya .. Tidak boleh menunggu

  • 1 = Titik Pemeriksaan
    Menunggu pos pemeriksaan terjadi. Ini harus terjadi dan Anda harus baik-baik saja - tetapi ada beberapa kasus untuk mencari jawaban atau pengeditan nanti

  • 2 = Cadangan log
    Anda sedang menunggu cadangan log terjadi. Entah Anda menjadwalkannya dan akan segera terjadi, atau Anda memiliki masalah pertama yang dijelaskan di sini dan sekarang Anda tahu cara memperbaikinya

  • 3 = Backup atau restore aktif
    Operasi pencadangan atau pemulihan berjalan di basis data

  • 4 = Transaksi aktif
    Ada transaksi aktif yang harus diselesaikan (baik cara - ROLLBACK atau COMMIT) sebelum log dapat dicadangkan. Ini adalah alasan kedua yang dijelaskan dalam jawaban ini.

  • 5 = Pencerminan basis data
    Salah satu cermin berada di belakang atau di bawah latensi dalam situasi mirroring kinerja tinggi atau mirroring dijeda karena alasan tertentu

  • 6 = Replikasi
    Mungkin ada masalah dengan replikasi yang akan menyebabkan ini - seperti agen pembaca log tidak berjalan, basis data berpikir itu ditandai untuk replikasi yang tidak lagi ada dan berbagai alasan lainnya. Anda juga dapat melihat alasan ini dan itu sangat normal karena Anda melihat waktu yang tepat, seperti halnya transaksi sedang dikonsumsi oleh pembaca log

  • 7 = Pembuatan snapshot basis data
    Anda sedang membuat snapshot basis data, Anda akan melihat ini jika Anda melihat saat yang tepat ketika snapshot dibuat

  • 8 = Log Scan
    Saya belum menemukan masalah dengan proses ini selamanya. Jika Anda melihat cukup lama dan cukup sering Anda dapat melihat ini terjadi, tetapi itu seharusnya tidak menjadi penyebab pertumbuhan log transaksi yang berlebihan, yang saya lihat.

  • 9 = Replika sekunder Grup AlwaysOn Availability Group menerapkan catatan log transaksi dari database ini ke database sekunder yang sesuai. Tentang deskripsi paling jelas ..

331
Mike Walsh

Karena saya tidak benar-benar puas dengan salah satu jawaban di atas Stack Overflow , termasuk saran yang paling banyak dipilih, dan karena ada beberapa hal yang ingin saya sampaikan bahwa jawaban Mike tidak tidak, saya pikir saya akan memberikan masukan saya di sini juga. Saya menempatkan salinan jawaban ini di sana juga.

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 FULL mode pemulihan. Jika tidak, maka pastikan:

ALTER DATABASE yourdb SET RECOVERY FULL;

Bahkan jika Anda mengambil cadangan penuh reguler, file log akan tumbuh dan tumbuh sampai Anda melakukan log cadangan - ini adalah untuk perlindungan Anda, bukan untuk 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 kurang 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 rencana pemeliharaan dll., Jangan pilih salah satu opsi menyusut dalam rencana pemeliharaan, itu mengerikan).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + 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 pada mesin yang berbeda yang mewakili perangkat penyimpanan dasar yang berbeda. Membackup ini ke mesin yang sama (atau ke mesin lain yang menggunakan cakram dasar yang sama, atau berbeda VM yang ada di Host fisik yang sama) tidak benar-benar membantu Anda, karena jika mesin meledak, Anda 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 tidak berarti menjalankan SHRINKFILE berulang-ulang sampai file log adalah 1 MB - bahkan jika Anda sering mencadangkan log, masih perlu mengakomodasi jumlah 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 pengujian, dan Anda tidak peduli tentang pemulihan point-in-time, maka Anda harus memastikan bahwa database Anda dalam SIMPLE mode pemulihan.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Menempatkan basis data dalam SIMPLE mode pemulihan akan memastikan bahwa SQL Server menggunakan kembali sebagian dari file log (pada dasarnya menghapus transaksi tidak aktif) alih-alih membesar untuk menyimpan catatan semua = transaksi (seperti FULL pemulihan dilakukan hingga Anda mencadangkan log). CHECKPOINT events akan membantu mengendalikan log dan memastikannya tidak perlu bertambah kecuali Anda menghasilkan banyak aktivitas t-log di 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
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
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_ONLY pilihan lalu SHRINKFILE. Untuk satu, ini TRUNCATE_ONLY pilihan telah ditinggalkan dan tidak lagi tersedia di versi SQL Server saat ini. Kedua, jika Anda berada dalam model pemulihan FULL, ini akan menghancurkan rantai log Anda dan memerlukan cadangan lengkap 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 "shrink database" . DBCC SHRINKDATABASE dan 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 SHRINKFILE atau 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 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 ulang 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 standar untuk SQL Server (yang saya keluhkan dan meminta 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.

117
Aaron Bertrand

Anda juga dapat melihat konten file log Anda. Untuk melakukan itu, Anda dapat menggunakan fn_dblog, atau pembaca log transaksi, seperti ApexSQL Log .

Itu tidak menunjukkan pengorganisasian indeks, tetapi itu menunjukkan semua DML dan berbagai acara DDL: ALTER, CREATE, DROP, pemicu mengaktifkan/menonaktifkan, memberikan/mencabut izin, objek ganti nama.

ApexSQLLogProject.temp - ApexSQL.log

Penafian: Saya bekerja untuk ApexSQL sebagai Support Engineer

30
Milena Petrovic

Ini adalah masalah yang paling sering dihadapi untuk hampir semua DBA di mana log tumbuh dan mengisi disk.

• Apa alasan mengapa log transaksi tumbuh begitu besar?

  1. Transaksi Aktif Panjang
  2. Transaksi logging yang tinggi seperti pembangunan kembali Indeks, pengorganisasian kembali, Sisipan Massal, Hapus dll.
  3. Setiap HA seperti Replikasi, Mirroring dikonfigurasi yang memegang log dan tidak memungkinkannya melepaskan ruang log

• Mengapa file log saya sangat besar?

Periksa log_reuse_wait_desc kolom dalam sys.databases tabel untuk mengetahui apa yang menahan log agar tidak terpotong:

select name, log_reuse_wait_desc 
from sys.databases

• Apa saja cara untuk mencegah masalah ini terjadi?

Pencadangan log akan membantu Anda mengontrol pertumbuhan log kecuali ada sesuatu yang menahan agar log tidak digunakan kembali.

• Apa yang saya lakukan ketika saya berada di jalur dengan penyebab yang mendasarinya dan ingin menempatkan file log transaksi saya ke ukuran yang sehat?

Jika Anda telah mengidentifikasi apa yang sebenarnya menyebabkannya, maka cobalah untuk memperbaikinya sebagaimana dijelaskan di halaman di bawah ini.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

Menjadwalkan pencadangan log yang tepat adalah cara terbaik untuk menangani pertumbuhan log kecuali untuk situasi yang tidak biasa.

7