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.