Mengapa log transaksi terus tumbuh dalam mode pemulihan sederhana dengan backup malam hari

Sebelum langsung menandai sebagai duplikat , saya telah membaca Mike Walsh's Mengapa Log Transaksi Terus Tumbuh atau Kehabisan Ruang? , tapi saya pikir itu tidak memberikan jawaban untuk situasi saya. Saya melihat-lihat selusin pertanyaan serupa, tetapi yang relevan kebanyakan hanya mengatakan "duplikat" dan menunjuk ke pertanyaan Mike.

Detail: Saya memiliki banyak ~ 500MB basis data di SQL Server 2008 R2, semuanya dalam mode pemulihan SEDERHANA (bukan pilihan saya), backup penuh setiap malam, dengan ~ 200MB file data dan ~ 300MB file log. Log tidak tumbuh hingga 300MB segera, tetapi agak lambat selama beberapa bulan. Tidak ada transaksi terbuka pada salah satu dari mereka, setidaknya menurut sp_who2 dan monitor aktivitas. Jika saya klik kanan pada database dan pilih properti, itu memberitahu saya ada ~ 50MB gratis. Terutama setelah cadangan, bukankah seluruh log harus gratis? Dalam mode SIMPLE, bukankah seharusnya log menjadi gratis selama tidak ada transaksi terbuka?

log_reuse_wait_descdari sys.databaseskata mengatakan "TIDAK ADA", yang berdasarkan pertanyaan dan jawaban yang dirujuk di atas mengatakan tidak boleh menunggu apa pun untuk menggunakan kembali ruang tersebut.

Jika saya melakukan 'DBCC SHRINKFILE', file log menyusut ke 1MB, sehingga bersedia untuk mengambil kembali ruang. Saya dapat mengatur sesuatu yang menyusutkan log setiap minggu dan menjaga hal-hal agar tidak terkendali, tapi saya bingung mengapa SQL Server membuat saya melakukan itu.

Saya bisa mengerti jika ada beberapa transaksi gila yang membutuhkan 300MB untuk login, tapi kami tidak melakukan sesuatu yang ekstrem, hanya OLTP dasar. Dari pertanyaan / jawaban Mike:

Simple Recovery Model - Jadi dengan pengantar di atas, lebih mudah untuk berbicara 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 pemulihan kerusakan dan restart (Anda benar-benar tidak punya pilihan di sana .. Cari properti ACID dan itu harus masuk akal dengan cepat), tetapi begitu Anda tidak lagi membutuhkannya untuk tujuan pemulihan kerusakan / mulai ulang, lanjutkan 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 itu 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.

Ia terus mengatakan ruang log harus digunakan kembali, tetapi dengan pertumbuhan yang lambat selama berbulan-bulan, sepertinya tidak.

Apa yang saya lewatkan? Apakah sesuatu menjaga SQL Server dari mengenali data sebagai "keras" dan membebaskan log?

(sunting) Laporan Setelah Tindakan - AKA sedikit pengetahuan berbahaya

Setelah menemukan bahwa ini adalah "pertanyaan populer", rasanya seperti saya berhutang penjelasan tentang apa yang terjadi 7 bulan lalu dan apa yang saya pelajari semoga dapat menyelamatkan beberapa orang dari kesedihan.

Pertama, ruang yang tersedia yang Anda lihat di SSMS saat Anda melihat properti di database adalah ruang yang tersedia di file data. Anda dapat melihat ini dengan menjalankan yang berikut ini pada database, dan Anda akan menemukan ruang yang tersedia yang dilaporkan oleh SSMS adalah perbedaan antara FileSizeMB dan UsedSpaceMB:

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

Ini memang mengkonfirmasi bahwa dalam keadaan normal kami menggunakan sangat sedikit ruang log (20MB atau kurang), tetapi ini mengarah ke item kedua ...

Kedua, persepsi saya tentang kayu gelondongan tumbuh dengan lambat seiring berjalannya waktu. Namun, pada kenyataannya log tumbuh dengan cepat pada malam hari orang yang bertanggung jawab untuk menerapkan tambalan untuk aplikasi pihak ke-3 ini menerapkan tambalan. Patch dilakukan sebagai satu transaksi tunggal, jadi tergantung pada patchnya, data 200MB membutuhkan 300MB log. Kunci dalam melacaknya adalah permintaan dari Aaron Bertrand di https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

Ini menunjukkan bahwa log tumbuh pada malam-malam tertentu, ketika pelanggan tidak menggunakan database. Itu mengarah ke percakapan dengan pria yang menerapkan tambalan dan jawaban untuk misteri.

Terima kasih sekali lagi untuk orang-orang yang memberikan bantuan untuk mendapatkan jawaban saya.

Tidak mungkin bagi kita untuk menebak apa yang menyebabkannya, tetapi SQL Server tidak hanya menumbuhkan file log menjadi 300 MB untuk itu, ia tumbuh hingga 300 MB karena pada beberapa titik sejak operasi menyusut terakhir Anda, diperlukan bahwa banyak ruang log (apakah karena beberapa transaksi tunggal besar atau banyak yang bersamaan kecil). Anda harus melacak peristiwa pertumbuhan file log (saya berbicara tentang ini di sini dan di sini ) untuk mencoba dan mempersempit kapan atau mengapa ini terjadi (juga jika Anda mencatat pengaturan pertumbuhan file 300 MB atau sesuatu, maka itu akan tumbuh 300 MB segera setelah dibutuhkan lebih dari 1 MB ruang untuk mengakomodasi transaksi aktif).

Ngomong-ngomong, mengapa Anda pikir Anda perlu mengecilkan file log setelah mencapai 300 MB? Apakah Anda benar-benar membaca semua jawaban, dengan seksama, pada pertanyaan Mike ? File log TIDAK akan menyusut dengan sendirinya, karena menyusut file log ke 1MB - hanya agar dapat tumbuh lagi selama transaksi terbesar Anda - adalah total buang waktu. Apa yang akan Anda lakukan dengan semua ruang kosong itu sementara itu?

Semua tes Anda saat ini ( DBCC SHRINKFILE, log_reuse_wait_desc) hanya membuktikan bahwa sekarang Anda menggunakan kembali file log virtual log transaksi dengan tepat. Tetapi ketika peristiwa pertumbuhan otomatis Anda terjadi pada file log transaksi Anda itu adalah reaksi terhadap log yang tidak dapat digunakan kembali.

Seringkali, itu bukan kondisi yang sedang berlangsung (persis seperti apa yang Anda rasakan saat ini dengan kurangnya gejala yang sedang Anda lihat). Ada beberapa hal yang dapat menyebabkan perilaku ini, bahkan dalam model pemulihan sederhana.

Taruhan terbaik Anda adalah mengatur pekerjaan pengumpulan data untuk secara rutin menarik log_reuse_wait_descdatabase Anda, dan secara rutin mencatat ini di suatu tempat. Maka Anda harus bisa merekayasa balik apa yang menyebabkan kurangnya penggunaan kembali log.

Ia terus mengatakan ruang log harus digunakan kembali, tetapi dengan pertumbuhan yang lambat selama berbulan-bulan, sepertinya tidak.

Seperti yang saya ditunjukkan di atas, itu tidak biasanya kondisi yang sedang berlangsung yang menyebabkan kurangnya penggunaan kembali log transaksi (kecuali beberapa kasus sudut, seperti transaksi buruk dibangun), sehingga Anda harus menentukan saat-saat ini adalah terjadi. Pengumpulan data diagnostik yang ringan harus menjadi awal yang baik.

Apakah Anda mengaktifkan menyusut otomatis pada DB? Dan / atau apakah Anda telah menjadwalkan rencana pemeliharaan yang melakukan pembangunan kembali indeks?

Susut otomatis yang diikuti oleh pemeliharaan indeks akan menghasilkan volume log yang signifikan.

Pemeliharaan indeks dengan sendirinya juga akan menghasilkan volume log yang signifikan, jika ada masalah desain DB seperti indeks berkerumun di GUID.

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog