İşlem günlüğü neden her gece yedeklemeli Basit kurtarma modunda büyümeye devam ediyor?

Hemen yinelemeli olarak işaretlemeden önce , Mike Walsh'in Neden İşlem Günlüğünün Büyümesini Sürdürdüğünü veya Boşaltılmadığını Okudum ? , ama durumuma bir cevap verdiğini sanmıyorum. Bir düzine kadar benzer soruyu araştırdım ama ilgili sorular çoğunlukla "kopya" dedi ve Mike'ın sorusuna işaret etti.

Ayrıntılar: SQL Server 2008 R2'de, tümü SIMPLE kurtarma modunda (benim seçimim değil), gece tam yedeklemelerinde, ~ 200 MB veri dosyaları ve ~ 300 MB günlük dosyalarında ~ 500 MB veritabanına sahibim. Günlük hemen 300 MB'a çıkmıyor, ancak birkaç ay boyunca yavaş ilerliyor. Hiçbirinde sp_who2 ve aktivite izleyicisine göre hiçbirinde açık işlem yoktur. Veritabanına sağ tıklayıp özellikleri seçersem, bana ~ 50 MB ücretsiz olduğunu söylüyor. Özellikle de bir yedeklemeden hemen sonra bütün kütük serbest kalmamalı mı? SIMPLE modunda, açık bir işlem olmadığı sürece kayıt ücretsiz olmaz mı?

log_reuse_wait_descdan sys.databasesdiyor soruya dayanmaktadır ve yukarıda referans cevabı o alanı yeniden kullanmasına şey beklemek gerektiğini söylüyor "ŞEY" diyor.

'DBCC SHRINKFILE' yaparsam, günlük dosyası 1 MB'a kadar küçülür, bu nedenle alanı geri almaya isteklidir. Günlükleri haftalık olarak küçülten ve işlerin kontrolden çıkmasını engelleyen bir şey ayarlayabilirim, ancak SQL Server'ın bunu neden yapmama neden olduğu konusunda kafam karıştı.

Bunu kaydetmek için 300 MB'a ihtiyaç duyan çılgınca bir işlem olup olmadığını anlayabiliyorum, ancak aşırı basit bir şey yapmıyoruz, sadece temel OLTP. Mike'ın soru / cevabından:

Basit Kurtarma Modeli - Yukarıdaki girişle, önce Basit Kurtarma modelinden bahsetmek en kolay yoldur. Bu modelde, SQL Server'a söylüyorsunuz - çökme ve kurtarma işlemlerini başlatmak için işlem günlüğü dosyanızı kullanmanız konusunda iyiyim (Gerçekten orada başka seçeneğiniz yok. o kilitlenme / yeniden başlatma kurtarma amacı için daha uzun süre ihtiyacınız var, devam edin ve günlük dosyasını yeniden kullanın.

SQL Server, Basit Kurtarma'daki bu talebi dinler ve yalnızca çökmesi / yeniden başlatılması için yapması gereken bilgileri tutar. SQL Server, verilerin veri dosyasına (daha fazla veya daha az) sertleştirildiği için kurtarılabildiğinden emin olduktan sonra, sertleştirilmiş veriler artık günlükte gerekli değildir ve kesme için işaretlenir - bu da yeniden kullanıldığı anlamına gelir.

Günlük alanının yeniden kullanılması gerektiğini söylemeye devam ediyor, ancak aylar boyunca bu yavaş büyüme ile öyle görünmüyor.

Neyi kaçırıyorum? SQL Server'ın verileri "sertleştirilmiş" olarak tanımasını ve günlüğü kurtarmasını engelleyen bir şey mi var?

(değiştir) Eylem Sonrası Rapor - AKA biraz bilgi tehlikelidir

Bunun “popüler bir soru” olduğunu bulduktan sonra, 7 ay önce olanları ve bazı insanlara kederi umursamayı umduklarımı açıklayan bir açıklama borçlu olduğumu hissettim.

Öncelikle, bir veritabanındaki özellikleri görüntülerken SSMS'de gördüğünüz boş alan veri dosyasındaki boş alandır. Aşağıdakileri bir veritabanında çalıştırarak bunu görüntüleyebilirsiniz ve SSMS tarafından bildirilen boş alanın FileSizeMB ve UsedSpaceMB arasındaki fark olduğunu göreceksiniz:

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'

Bu normal şartlarda çok az günlük alanı kullandığımızı doğruladı (20 MB veya daha az), ancak bu ikinci maddeye yol açtı ...

İkincisi, kütüklerin büyümesine ilişkin algım, zaman içindeki yavaşlıktı. Bununla birlikte, gerçekte, günlükler hızla büyüyordu, bu 3. parti başvurusu için yamalar uygulamaktan sorumlu adam yamalar uyguluyordu. Yama tek bir işlem olarak yapıldı, bu yüzden yamaya bağlı olarak 200 MB günlük 300 MB günlük gerekiyordu. Bunu izlemenin anahtarı, https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace adresindeki Aaron Bertrand'ın sorgusu oldu.

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;

Bu, müşterinin veritabanını kullanmadığı zamanlarda logun belirli akşamlarda büyüdüğünü gösterdi. Bu, yamaları uygulayan adamla konuşmaya ve gizeme verilen cevaba yol açtı.

Cevabı bulmama yardım edenlere tekrar teşekkür ederim.

Neye neden olduğunu tahmin etmek bizim için imkansız, ancak SQL Server heck için sadece bir günlük dosyasını 300 MB'a çıkarmıyor, 300 MB'a çıkıyor, çünkü son küçültme işleminizden bu yana bir noktada, buna ihtiyacı vardı. Çok fazla günlük alanı (bazı büyük tek işlem veya çok daha küçük eşzamanlı işlemler nedeniyle). Bunun ne zaman veya neden olduğunu denemek ve daraltmak için günlük dosyası büyüme olaylarını izlemek zorundasınız (bu konuda burada ve burada konuştum ) (ayrıca, dosya büyüme ayarı 300 MB veya başka bir şey ise, o zaman 300 MB büyüyecek) etkin işlemleri yapabilmek için 1 MB’dan daha fazla alana ihtiyaç duyduğu anda).

Herneyse, neden günlük dosyasını 300 MB'a ulaştığında küçültmeniz gerektiğini düşünüyorsunuz? Mike'ın sorusu üzerine bütün cevapları iyice okudun mu? Günlük dosyası kendiliğinden Küçültülmeyecektir, çünkü günlük dosyasını 1 MB'a küçültmek - en büyük işlemleriniz sırasında yeniden büyümesi için - zaman kaybıdır. Bu arada, bu boş alanla ne yapacaksın?

Mevcut testlerinizin tümü ( DBCC SHRINKFILE, log_reuse_wait_desc) şu anda işlem günlüğünün sanal günlük dosyalarını uygun şekilde yeniden kullandığınızı kanıtlıyor . Ancak, otomatik büyüme olaylarınız işlem günlüğü dosyanızda gerçekleştiğinde, tekrar kullanılamamış olan günlüğün tepkisidir.

Çoğu zaman, bu devam eden bir durum değildir (şu anda gördüğünüz semptomların eksikliği ile tam olarak size nasıl göründüğü gibi). Basit kurtarma modelinde bile, bu davranışa neden olabilecek çok sayıda şey vardır.

En iyisi, rutin olarak log_reuse_wait_descveritabanınızı çekmek için bir veri toplama işi ayarlamak ve bunu düzenli olarak bir yere kaydetmek olabilir . Öyleyse, kütük yeniden kullanım eksikliğine neyin neden olduğunu tersine çevirebilmelisiniz.

Günlük alanının yeniden kullanılması gerektiğini söylemeye devam ediyor, ancak aylar boyunca bu yavaş büyüme ile öyle görünmüyor.

Yukarıda belirtildiği gibi, bu kez kesin olarak belirlemek zorundayız bu yüzden, bu tipik (kötü inşa işlemler gibi birkaç köşe durumlarda tasarruf) işlem günlük yeniden kullanım eksikliği neden devam eden bir durum değil edilir oluyor. Hafif tanılama veri toplama iyi bir başlangıç ​​olmalıdır.

Veritabanlarında otomatik küçültmeyi etkinleştirdiniz mi? Ve / veya endeks yeniden oluşturmalarını gerçekleştiren planlanmış bakım planlarınız var mı?

Otomatik küçültme ve ardından indeks bakımı önemli miktarda kütük hacmi üretecektir.

Dizin bakımı, GUID'lerde kümelenmiş dizinler gibi DB tasarım sorunları varsa, kendi başına da önemli bir günlük hacmi üretecektir.

 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