Bu, çoğu forumda ve web’in tamamında yaygın bir soru gibi görünüyor, burada genellikle bunun gibi görünen birçok formatta soruluyor:

SQL Server'da -

• İşlem günlüğünün bu kadar büyümesinin nedenleri nelerdir?
• Günlük dosyam neden bu kadar büyük?
• Bu sorunun oluşmasını önlemenin bazı yolları nelerdir?
• Altta yatan neden ile kendimi takip ettiğimde ve işlem günlüğü dosyamı sağlıklı bir boyuta koymak istediğimde ne yapmalıyım?

Daha Kısa Bir Cevap:

Muhtemelen uzun süredir devam eden bir işleminiz var (İndeks bakımı? Büyük toplu silme veya güncelleme?) Veya kurtarma modunda "varsayılan" (varsayılanın ne anlama geldiğinin altında daha fazlası) olduğunuzu veya Fullbir günlük yedeği almadığınızdan (veya onları yeterince sık almayacağım).

Bir kurtarma modeli sorunuysa, Simplezaman içinde kurtarma ve düzenli günlük yedeklemelerine gerek duymuyorsanız , basit cevap kurtarma moduna geçme olabilir. Yine de çoğu insan, iyileşme modellerini anlamadan cevaplarını veriyor. Neden önemli olduğunu anlamak için okumaya devam edin ve sonra ne yaptığınıza karar verin. Ayrıca günlük yedeklerini almaya başlayabilir ve Fullkurtarmaya devam edebilirsiniz.

Başka sebepler olabilir ama bunlar en yaygın olanları. Bu cevap, en yaygın iki nedenin içine dalmaya başlar ve size nedenlerin neden ve ne kadar gerisinde kaldığını ve bazı diğer nedenleri araştırdığınızı gösterir.

Daha Uzun Bir Cevap: Hangi Senaryolar günlüğün Büyümesini sürdürmesine neden olabilir? Birçok neden var, ancak genellikle bu nedenler aşağıdaki iki düzendedir: Kurtarma modelleri hakkında bir yanlış anlaşılma var ya da uzun süren işlemler var. Detaylar için okumaya devam edin.

En iyi neden 1/2: Kurtarma Modellerini Anlamamak

( Tam Kurtarma Modunda Olmak ve Günlük Yedeklemelerini Almamak - Bu en yaygın sebep - bu sorunu yaşayanların büyük çoğunluğudur. )

Bu cevap, SQL Server kurtarma modellerinde derin bir dalış olmasa da, kurtarma modelleri konusu bu sorun için kritik öneme sahiptir.

SQL Server'da üç kurtarma modeli vardır :

• Full,
• Bulk-Logged ve
• Simple.

Bulk-LoggedŞimdilik görmezden geleceğiz, bunun bir melez model olduğunu söyleyeceğiz ve bu modelde bulunan çoğu insanın bir nedeni var ve kurtarma modellerini anlıyoruz.

Önemsediğimiz iki şey ve onların kafa karışıklığı, bu sorunu yaşayan insanların çoğunluğunun nedeni Simpleve Full.

İntermisyon: Genel Olarak Kurtarma

Kurtarma Modelleri hakkında konuşmadan önce: genel olarak kurtarma hakkında konuşalım. Bu konuyla daha da derinleşmek istiyorsanız, Paul Randal'un blogunu ve konuyla ilgili istediğiniz kadar mesajı okuyun . Bu soru için olsa:

1. Kilitlenme / Yeniden Başlatma Kurtarması
   İşlem günlük dosyasının bir amacı kilitlenme / yeniden başlatma kurtarmasıdır . Bir çarpmadan önce yeniden yapılanma ve geri alma için ya bir çarpmadan önce yeniden yapılanma veya yeniden başlatma ya da yeniden başlatma ve bir çarpma veya yeniden başlatmadan sonra başlatılmış ancak bitmemiş iş (geri alma / geri alma) için. Bir işlemin başladığını, ancak hiç bitmediğini (işlem yapılmadan önce geri alındı ​​veya çökme / yeniden başlatma gerçekleştiğini) görmek işlem günlüğünün işidir. Bu durumda İyileşme sırasında "Hey .. bu asla bitmedi, hadi geri dönelim" demek günlüğün işidir . Ayrıca, bir şeyi bitirdiğinizi ve müşteri başvurunuzun bittiğini (veri dosyanızda henüz sertleşmemiş olsa bile) söyleyip söylemediğini görmek günlüğün işidir.“Hey .. bu gerçekten oldu, hadi ileri saralım, uygulamaların sanıldığı gibi yapalım” diyerek yeniden başlattıktan sonra. Şimdi dahası var ama asıl amaç bu.

2. Zaman Kurtarıcılığındaki Nokta
   Bir işlem günlüğü dosyasının diğer amacı , bir veritabanındaki "hatalar" nedeniyle bize bir noktaya kadar zaman kazanabilme veya donanım arızası durumunda bir kurtarma noktası sağlama becerisi kazandırmaktır. Bir veri tabanının veri ve / veya günlük dosyalarını içeren. Bu işlem günlüğü kurtarma için başlatılmış ve bitmiş işlemlerin kayıtlarını içeriyorsa, SQL Server bu bilgiyi bir sorun oluşmadan önce bulunduğu yere bir veritabanı elde etmek için kullanabilir ve kullanır. Ancak bu bizim için her zaman uygun bir seçenek değildir. Bunun için veritabanımızı doğru kurtarma modelinde bulundurmalı ve günlük yedeklemelerini almalıyız .

Kurtarma Modelleri

Kurtarma modellerine:

• Basit Kurtarma Modeli
  Bu yüzden yukarıdaki girişle, Simple Recoveryilk önce model hakkında konuşmak en kolay olanıdır . Bu modelde, SQL Server'a şunları söylüyorsunuz: "Kilitlenme ve yeniden başlatmayı başlatmak için işlem günlüğü dosyanızı kullanma konusunda iyiyim ..." (Orada gerçekten seçeneğiniz yok. ACID özelliklerine bakın ve bu hızlı bir şekilde anlaşılmalıdır.) “... ancak artık bu kilitlenme / yeniden başlatma kurtarma amacıyla ihtiyacınız olmadığında, 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.

• Tam Kurtarma Modeli
  ile Full Recovery, SQL Server'a, günlük dosyanız kullanılabilir olduğu sürece veya belirli bir zamana göre bir günlük yedeklemesi tarafından kapsanan belirli bir noktaya kurtarabilmek istediğinizi söylüyorsunuz. Bu durumda, SQL Server Basit Kurtarma Modelinde günlük dosyasını kısaltmanın güvenli olacağı noktaya ulaştığında, bunu yapmayacaktır. Bunun yerine , günlük dosyasının büyümeye devam etmesine izin verir ve normal koşullar altında bir günlük yedeği alıncaya kadar (veya günlük dosyası sürücünüzde alan biterse) büyümeye devam etmesini sağlar .

Simple'dan Full'a geçmek Gotcha'ya sahiptir.

Burada kurallar ve istisnalar var. Aşağıda uzun süredir devam eden işlemlerden söz edeceğiz.

Ancak, Tam Kurtarma Modu için akılda tutulması gereken bir uyarı şudur: Eğer sadece Full Recoverymoda geçiyorsanız, ancak hiçbir zaman ilk bir Tam Yedekleme yapmazsanız , SQL Server isteğinizin Full Recoverymodele girmesini onurlandırmaz . İşlem günlüğünüz, SimpleTam Kurtarma Modeli'ne geçene ve ilkinizi alıncaya kadar devam ettiği gibi çalışmaya devam eder Full Backup.

Günlük yedekleme olmadan Tam Kurtarma Modeli kötü.

Yani kontrolsüz kütük büyümesinin en yaygın nedeni bu mu? Cevap: Herhangi bir günlük yedeği olmadan Tam Kurtarma modunda olmak.

Bu insanlara her zaman olur .

Bu neden bu kadar yaygın bir hata?

Neden her zaman oluyor? Çünkü her yeni veritabanı, model veritabanına bakarak ilk kurtarma modeli ayarını alıyor.

Modelin ilk kurtarma modeli ayarı her zaman Full Recovery Model- birisi tarafından değiştirilmedikçe ve Yani "varsayılan Kurtarma Modeli" olduğunu söyleyebiliriz Full. Birçok kişi bunun farkında değildir ve veritabanlarının Full Recovery Modelkayıt defteri yedeği olmadan çalışmakta ve bu nedenle işlem kayıt dosyası gerekenden çok daha büyüktür. Bu nedenle kuruluşunuz ve ihtiyaçları için çalışmadıklarında varsayılanları değiştirmek önemlidir.)

Çok az günlük yedeği olan Tam Kurtarma Modeli kötü.

Ayrıca, günlük kayıtlarını yeterince sık alamayarak burada başınız derde girebilir.
Günlüğün günlük yedeğini almak kulağa iyi gelebilir, geri yükleme işlemi daha az geri yükleme komutu gerektirir, ancak yukarıdaki tartışmayı göz önünde bulundurarak, günlük dosyasının yedekleninceye kadar büyümeye ve büyümeye devam edeceğini unutmayın.

Hangi günlük yedekleme sıklığına ihtiyacım olduğunu nasıl bulabilirim?

Günlük yedekleme sıklığınızı aklınızda bulundurmanız gereken iki şeyi göz önünde bulundurmanız gerekir:

1. Kurtarma İhtiyaçları - Bu umarım ilk olmalıdır. İşlem günlüğünüzü barındıran sürücünün arızalanması veya günlük yedeklemenizi etkileyen ciddi bozulma olması durumunda ne kadar veri kaybedilebilir? Bu sayı 10-15 dakikadan fazla değilse, tartışma sonunda her 10-15 dakikada bir günlük yedeği almanız gerekir.
2. Günlük Büyümesi - Kuruluşunuz o günü kolayca yeniden oluşturabilmesi nedeniyle daha fazla veri kaybetmek için uygunsa, 15 dakikadan daha az sıklıkla bir günlük yedeklemesi yapmanız iyi olabilir. Belki de organizasyonunuz her 4 saatte bir iyidir. Ancak 4 saat içinde kaç işlem yaptığınıza bakmalısınız. Günlüğün bu dört saat içinde büyümeye devam etmesine izin vermek, bir günlük dosyasında çok büyük olacak mı? Bu log yedeklemenizin çok uzun süreceği anlamına mı geliyor?

En önemli sebep 2/2: Uzun Süreli İşlemler

( "Kurtarma modelim iyi! Günlük hala artıyor! )

Bu aynı zamanda kontrolsüz ve kontrolsüz kütük büyümesinin bir nedeni olabilir. Kurtarma modeli ne olursa olsun, ancak genellikle "Ama Basit Kurtarma Modelindeyim - günlüğüm neden hala büyüyor ?!" olarak ortaya çıkıyor.

Bunun nedeni basittir: SQL yukarıda açıklandığı gibi kurtarma amacıyla bu işlem günlüğünü kullanıyorsa, işlem başlangıcına geri dönmesi gerekir.

Uzun süren veya çok fazla değişiklik yapan bir işleminiz varsa, günlüğe hala açık işlemlerde olan veya işlem başladığından bu yana başlayan değişikliklerin hiçbirinin denetim noktasında kesilmesi mümkün değildir.

Bu, bir delete ifadesinde milyonlarca satırı silen büyük bir silme işleminin tek işlem olduğu ve tüm silme işlemi tamamlanıncaya kadar günlük kesmenin yapamayacağı anlamına gelir. Olarak Full Recovery Model, bu günlüğe silmek ve bu günlük kayıtlarının çok olabilir. İndeks optimizasyonu ile aynı şey bakım pencerelerinde çalışır. Ayrıca, zayıf işlem yönetimi ve açık işlemleri izlememek ve kapatmamak, size ve günlük dosyanıza gerçekten zarar verebilir.

Bu uzun süren işlemler hakkında ne yapabilirim?

Kendinizi burada kaydedebilirsiniz:

• Bakım veya bilinen büyük işlemler gibi, en kötü durum senaryosunu hesaba katarak günlük dosyanızı doğru şekilde boyutlandırın. Ve log dosyanızı büyüttüğünüzde, Kimberly Tripp'un bu kılavuzuna (ve size gönderdiği iki bağlantıya) bakmalısınız . Doğru boyutlandırma burada çok önemlidir.
• İşlem kullanımınızı izliyorum. Uygulama sunucunuzda bir işlem başlatmayın ve SQL Server ile uzun konuşmalar yapmaya başlayın ve birini çok uzun süre açık bırakma riskiyle karşı karşıya kalın.
• DML ifadelerinizde zımni işlemleri izlemek . Örneğin: UPDATE TableName Set Col1 = 'New Value'bir işlemdir. Oraya bir yer BEGIN TRANkoymadım ve mecbur kalmadım, hala yapıldığında otomatik olarak işleyen bir işlem. Bu nedenle, çok sayıda satırda işlem yapıyorsanız, bu işlemleri daha yönetilebilir parçalara ayırmayı ve kurtarılması için günlük vermeyi düşünün. Veya bununla başa çıkmak için doğru boyutu düşünün. Veya dökme yük penceresi sırasında belki kurtarma modellerini değiştirme konusuna bakın.

Bu iki neden Log Günlüğü için de geçerli midir?

Kısa cevap: evet. Aşağıda daha uzun cevap.

Soru: Günlük kaydı kullanıyorum, bu nedenle günlük yedeklemelerim otomatikleştiriliyor ... Neden hala işlem günlüğü büyümesi görüyorum?

Cevap: okumaya devam edin.

Günlük Gönderimi Nedir?

Günlük sevkıyatı tam olarak göründüğü gibi - işlem günlüğü yedeklerinizi DR amacıyla başka bir sunucuya gönderiyorsunuz. Bazı başlangıçlar var ancak ondan sonra süreç oldukça basittir:

• Günlüğü bir sunucuda yedekleyecek bir iş,
• o günlük yedeklemesini kopyalamak için bir iş ve
• Hedef sunucuda kurtarmadan (ya NORECOVERYda STANDBY) geri yüklemek için bir iş .

Ayrıca, işler planladığınız gibi gitmezse izlenmesi ve uyarılması gereken bazı işler de vardır.

Bazı durumlarda, günlük sevkiyat geri yüklemesini yalnızca günde bir kez veya her üç günde bir veya haftada bir kez yapmak isteyebilirsiniz. Bu iyi. Ancak, bu değişikliği tüm işlerde (günlük yedekleme ve kopyalama işleri dahil) yaparsanız, o zaman tüm zamanların günlük yedeğini almayı beklersiniz. Bu, çok fazla günlük büyümesine sahip olacağınız anlamına gelir - çünkü günlük yedeği olmadan tam kurtarma modundasınızdır - ve muhtemelen kopyalanacak büyük bir günlük dosyası anlamına da gelir. Yalnızca geri yükleme işinin zamanlamasını değiştirmeli ve günlük yedeklemelerinin ve kopyalarının daha sık gerçekleşmesine izin vermelisiniz, aksi halde bu cevapta açıklanan ilk sorundan muzdarip olacaksınız.

Durum kodlarıyla genel sorun giderme

Bu ikisinden başka nedenler var ama bunlar en yaygın olanları. Sebep ne olursa olsun: bu açıklanamayan kütük büyümesi / kesilme eksikliği için nedeninizi analiz etmenin ve bunların ne olduğunu görmenin bir yolu vardır.

sys.databasesKatalog görünümünü sorgulayarak, günlük dosyanızın kısaltılması / yeniden kullanılmasını beklemesinin nedenini açıklayan bilgileri görebilirsiniz.

Neden log_reuse_waitkodunun arama kimliğiyle birlikte adlandırılan bir log_reuse_wait_descsütun ve bekleme nedeninin açıklamasını içeren bir sütun vardır. Başvurulan kitaplardan çevrimiçi makale, nedenlerin çoğu (görmesi muhtemel olanlar ve nedenlerini açıklayabildiklerimizin çoğunluğudur. Eksik olanlar kullanım dışı veya iç kullanım içindir) italik :

• 0 = Nothing
  Neye benziyor .. Beklememelisin

• 1 = Kontrol Noktası
  Bir kontrol noktasının oluşmasını bekliyor. Bu olmalı ve iyi olmalısınız - ancak daha sonra cevaplar veya düzenlemeler için burada aranacak bazı durumlar vardır.

• 2 = İşlem kaydı yedekleme İşlem
  kaydı işleminin gerçekleşmesini bekliyorsunuz. Ya onları planladınız ve yakında ortaya çıkacak ya da burada açıklanan ilk probleminiz var ve şimdi nasıl düzelteceğinizi biliyorsunuz.

• 3 = Aktif yedekleme veya geri
  yükleme Veritabanında bir yedekleme veya geri yükleme işlemi çalışıyor

• 4 = Aktif işlem Günlük yedeklenmeden önce
  tamamlanması gereken (her iki şekilde - ROLLBACKveya COMMIT) bir aktif işlem var . Bu cevapta açıklanan ikinci sebep budur.

• 5 = Veritabanı yansıtma
  Yüksek performanslı yansıtma durumunda bir ayna ya gecikmenin altına veya altına düşüyor ya da yansıma bir nedenden dolayı duraklatılıyor

• 6 = Çoğaltma Buna
  neden olacak çoğaltma ile ilgili sorunlar olabilir - bir günlük okuyucu aracısının çalışmaması gibi, artık olmadığının ve bunun çeşitli nedenlerden dolayı çoğaltma için işaretlendiğini düşünen bir veritabanı gibi. Bu nedeni de görebilirsiniz ve bu tamamen normaldir, çünkü işlemlerin günlük okuyucusu tarafından tüketildiği gibi doğru zamanda bakıyorsunuzdur.

• 7 = Veritabanı anlık görüntüsü oluşturma Veritabanı anlık görüntüsü oluşturuyorsunuz , anlık görüntü oluşturulurken
  doğru zamanda bakarsanız bunu görürsünüz

• 8 = Günlük Taraması
  Bu, sonsuza dek sürecek bir sorunla karşılaşmadım. Yeterince uzun ve yeterince sık bakarsanız bunun olduğunu görebilirsiniz, ancak gördüğüm aşırı işlem günlüğü büyümesinin bir nedeni olmamalıdır.

• 9 = AlwaysOn Kullanılabilirlik Grupları ikincil kopyası, bu veritabanının işlem günlüğü kayıtlarını ilgili ikincil veritabanına uyguluyor. Henüz en net açıklama hakkında ..

En fazla oy alan öneri de dahil olmak üzere Stack Overflow'taki yanıtlardan hiçbiri ile gerçekten tatmin olmadığım için ve Mike'ın cevabının cevaplamadığı bir kaç şey olduğu için temin edeceğimi düşündüm. benim de giriş burada. Bu cevabın bir kopyasını da oraya yerleştirdim.

Bir günlük dosyasını küçültmek, bir daha olmasını beklemeyeceğiniz beklenmedik bir büyüme ile karşılaştığı senaryolar için gerçekten ayrılmalıdır. Günlük dosyası tekrar aynı boyuta çıkarsa, geçici olarak küçülterek pek bir şey olmaz. Şimdi, veritabanınızın kurtarma hedeflerine bağlı olarak, yapmanız gerekenler bunlar.

İlk önce tam bir yedekleme yapın

Bir şeyler ters giderse geri yükleyebilmenizi sağlamadan veritabanınız üzerinde hiçbir değişiklik yapmayın.

Zamanında toparlanmaya önem veriyorsanız

(Ve zaman içinde toparlanma ile, tam ya da farklı bir yedeklemeden başka bir şeyi geri yükleyebilmeyi önemsiyorum.)

Muhtemelen veritabanınız FULLkurtarma modundadır. Değilse, emin olun:

ALTER DATABASE yourdb SET RECOVERY FULL;

Düzenli olarak tam yedekleme yapıyor olsanız bile, günlük dosyası bir günlük yedeklemesi gerçekleştirene kadar büyür ve büyür - bu sizin korumanız içindir, gereksiz yere diskinizde yemek yemeyin. Kurtarma günlüklerinize göre bu günlük yedeklemelerini oldukça sık gerçekleştirmelisiniz. Örneğin, bir felaket durumunda 15 dakikadan az veri kaybetmeyeceğinizi belirten bir iş kuralınız varsa, günlüğü her 15 dakikada bir yedekleyen bir işiniz olmalıdır. İşte şimdiki zamana göre zaman damgalı dosya adları oluşturacak bir betik (ancak bunu bakım planları ile de yapabilirsiniz, sadece bakım planlarındaki küçültme seçeneklerinden hiçbirini seçmeyin, berbatlar).

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;

\\backup_share\Farklı bir temel depolama aygıtını temsil eden farklı bir makinede olması gerektiğini unutmayın . Bunları aynı makineye (veya aynı temel diski kullanan farklı bir makineye veya aynı fiziksel ana bilgisayarda bulunan farklı bir VM'ye) yedeklemek, gerçekten yardımcı olmaz, çünkü makine patlarsa, veritabanınızı kaybettiniz ve onun yedekleri. Ağ altyapınıza bağlı olarak, yerel olarak yedekleme yapmak ve ardından sahnelerin arkasında farklı bir yere aktarmak daha mantıklı olabilir; Her iki durumda da, onları birincil veritabanı makinesinden olabildiğince çabuk çıkarmak istersiniz.

Artık düzenli bir günlük yedeklemesi çalıştırdığınızda, günlük dosyasını şu ana kadar ne olursa olsun daha makul bir şeye küçültmek mantıklı olacaktır. Bu mu değil çalışan anlamına SHRINKFILEsık günlüğü yedekleme bile, yine de oluşabilir herhangi eşzamanlı işlemlerin toplamı karşılamak gerekiyor - günlük dosyası 1 MB kadar tekrar tekrar. Günlük dosyası autogrow olayları pahalıdır, çünkü SQL Server dosyaları sıfırlamak zorundadır (anlık dosya başlatma etkinleştirildiğinde veri dosyalarının aksine) ve bu işlem sırasında kullanıcı işlemlerinin beklemesi gerekir. Bu büyümek-küçültme-küçültme-küçültme küçültme rutinini olabildiğince az yapmak istiyorsunuz ve kesinlikle kullanıcılarınızın parasını ödemesini istemiyorsunuz.

Küçültmenin mümkün olması için kütüğü iki kez yedeklemeniz gerekebileceğini unutmayın (teşekkürler Robert).

Bu nedenle, günlük dosyanız için pratik bir boyut bulmanız gerekir. Buradaki hiç kimse, sisteminiz hakkında daha fazla şey bilmeden size neyin olduğunu söyleyemez, ancak günlük dosyasını sık sık küçültüyorsanız ve yeniden büyüyorsa, iyi bir filigran büyük olasılıkla en fazla% 10-50 daha yüksektir . Diyelim ki bu 200 MB’dir ve sonraki herhangi bir otomatik büyütme olayının 50 MB olmasını istersiniz, daha sonra günlük dosyasının boyutunu şu şekilde ayarlayabilirsiniz:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Günlük dosyası şu anda> 200 MB ise, önce bunu çalıştırmanız gerekebileceğini unutmayın:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Zamanında toparlanmayı umursamıyorsanız

Bu bir test veritabanıysa ve zaman içinde kurtarmayı umursamıyorsanız, veritabanınızın SIMPLEkurtarma modunda olduğundan emin olmalısınız .

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Veritabanını SIMPLEkurtarma moduna sokmak, SQL Server'ın tüm işlemlerin kaydını tutmak için büyümek yerine (esas olarak etkin olmayan işlemleri iptal etme) günlük dosyasının bazı bölümlerini yeniden kullanmasını sağlar ( FULLkurtarma işlemi günlüğü yedekleyene kadar yapar). CHECKPOINTolaylar, günlüğü kontrol etmeye yardımcı olacaktır ve CHECKPOINTs arasında çok fazla t-log etkinliği oluşturmadığınız sürece büyümesine gerek olmadığından emin olacaktır .

Daha sonra, bu günlük büyümesinin gerçekten anormal bir olaydan (örneğin, yıllık ilkbahar temizliği veya en büyük endekslerinizi yeniden oluşturması) kaynaklandığından ve normal günlük kullanımdan kaynaklanmadığından emin olmalısınız. Günlük dosyasını gülünç derecede küçük bir boyuta daraltırsanız ve SQL Server normal etkinliğinize uyum sağlamak için yeniden büyütmek zorunda kalırsa ne elde ettiniz? Sadece geçici olarak boşalttığınız disk alanından yararlanabildiniz mi? Hemen bir düzeltmeye ihtiyacınız varsa, aşağıdakileri çalıştırabilirsiniz:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

Aksi takdirde, uygun bir boyut ve büyüme oranı ayarlayın. Zamanında kurtarma durumunda olan örneğe göre, hangi dosya boyutunun uygun olduğunu belirlemek ve makul otomatik büyüme parametrelerini belirlemek için aynı kodu ve mantığı kullanabilirsiniz.

Yapmak istemediğiniz bazı şeyler

• TRUNCATE_ONLYSeçeneği ve ardından günlüğü yedekleyinSHRINKFILE . Birincisi, bu TRUNCATE_ONLYseçenek kullanımdan kaldırıldı ve SQL Server'ın geçerli sürümlerinde artık kullanılamıyor. İkincisi, FULLkurtarma modelindeyseniz, bu, günlük zincirinizi imha eder ve yeni, tam bir yedekleme gerektirir.

• Veritabanını çıkarın, günlük dosyasını silin ve yeniden ekleyin . Bunun ne kadar tehlikeli olabileceğini vurgulayamıyorum. Veritabanınız geri gelmeyebilir, şüpheli olarak ortaya çıkabilir, bir yedeğe geri dönmeniz gerekebilir (varsa) vb.

• "Veritabanını küçült" seçeneğini kullanın . DBCC SHRINKDATABASEve aynısını yapma bakım planı seçeneği, özellikle sadece bir günlük sorunu sorunu çözmek gerekiyorsa, kötü fikirlerdir. Ayarlamak istediğiniz dosyayı hedefleyin ve ayarlayın ( DBCC SHRINKFILEveya ALTER DATABASE ... MODIFY FILEyukarıdaki örnekleri kullanarak ).

• Günlük dosyasını 1 MB'a küçültün . Bu cazip görünüyor çünkü, hey, SQL Server bazı senaryolarda bunu yapmama izin verecek ve serbest bıraktığı tüm boşluğa bakacak! Veritabanınız salt okunur olmadıkça (ve onu kullanarak işaretlemelisiniz ALTER DATABASE), bu, kurtarma modeline bakılmaksızın mevcut işlemlerin yerine getirilmesi gerektiğinden , kesinlikle gereksiz birçok büyüme olayına yol açacaktır. Bu alanı geçici olarak boşaltmanın amacı nedir, SQL Server'ın yavaş ve acı verici bir şekilde geri alabilmesi için mi?

• İkinci bir günlük dosyası oluşturun . Bu, diskinizi dolduran sürücünün geçici olarak rahatlamasını sağlayacaktır, ancak bu, delinmiş bir akciğeri bant yardımı ile tamir etmeye benzer. Yalnızca başka bir olası sorun eklemek yerine doğrudan sorunlu günlük dosyası ile ilgilenmelisiniz. Bazı işlem günlüğü etkinliklerini farklı bir sürücüye yönlendirmek dışında, ikinci bir günlük dosyası sizin için hiçbir şey yapmaz (ikinci veri dosyasından farklı olarak), çünkü dosyalardan yalnızca biri bir anda kullanılabilir. Paul Randal ayrıca çoklu log dosyalarının sizi neden daha sonra ısırdığını da açıklıyor .

Proaktif ol

Günlük dosyanızı küçük bir miktara küçültmek ve sürekli olarak kendi başına küçük bir oranda otomatik olarak büyümesine izin vermek yerine, oldukça büyük bir boyuta ayarlayın (en büyük eşzamanlı işlem kümenizin toplamına uyması için) ve makul bir otomatik ayarlama ayarlayın tek bir işlemi yerine getirmek için birden fazla kez büyümesi gerekmeyecek ve normal iş operasyonlarında büyümesi için nispeten nadir olacağı için bir geri dönüş olarak belirledik.

Buradaki olası en kötü ayarlar 1 MB büyüme veya% 10 büyüme. Yeterince komik, bunlar SQL Server'ın varsayılan ayarlarıdır (bundan şikayet ettim ve boşuna değişiklik istemedim ) - veri dosyaları için 1 MB, günlük dosyaları için% 10. İlki bu gün ve yaşta çok küçüktür ve ikincisi her seferinde daha uzun ve daha uzun olaylara yol açar (örneğin, günlük dosyanız 500 MB, ilk büyüme 50 MB, sonraki büyüme 55 MB, bir sonraki büyüme 60.5 MB , vb. vs. - ve yavaş G / Ç'de, inanın bana bu eğriyi gerçekten göreceksiniz).

daha fazla okuma

Lütfen burada durma; Günlük dosyalarını küçültmekle ilgili olarak gördüğünüz tavsiyelerin çoğu doğal olarak kötü ve hatta potansiyel olarak feci olsa da, disk bütünlüğünü boşaltmaktan ziyade veri bütünlüğünü önemseyen insanlar var.

• 2009'da yazdığım bir blog yazısı, birkaç tane "günlük dosyasını nasıl küçülteceğimi" gördüğümde yazılanlar .

• Bir blog yazısı Brent Ozar gereken bir SQL Server Dergi yazıya cevaben, çoklu kaynaklara işaret ederek, dört yıl önce yazdığı değil yayınlanmıştır .

• Paul Randal tarafından yayınlanan bir blog yazısı, t-log bakımının neden önemli olduğunu ve neden veri dosyalarınızı daraltmamanız gerektiğini açıklıyor .

• Elbette, Mike Walsh'un, günlük dosyanızı hemen neden daraltmamayacağınız nedenleri de dahil olmak üzere, bu yönlerden bazılarını da kapsayan büyük bir cevabı var .

Ayrıca günlük dosyanızın içeriğini görebilirsiniz. Bunu yapmak için, belgelenmemiş fn_dblogveya ApexSQL Günlüğü gibi bir işlem günlüğü okuyucusu kullanabilirsiniz .

Bu endeks yeniden düzenlenmesi göstermez, ancak tüm DML ve çeşitli DDL olayları gösterir: ALTER, CREATE, DROP, hibe / izinleri, nesne yeniden adlandırma iptal, tetik / devre dışı.

Yasal Uyarı: ApexSQL için Destek Mühendisi olarak çalışıyorum

Bu, günlüklerin büyüdüğü ve diski doldurduğu neredeyse tüm DBA'lar için en sık karşılaşılan sorun.

• İşlem günlüğünün bu kadar büyümesinin nedenleri nelerdir?

1. Uzun Aktif İşlem
2. Index yeniden oluşturma, yeniden düzenleme, Toplu Ekleme, Silme vb. Gibi yüksek kayıt işlemleri
3. Günlüğü tutan ve günlük alanını serbest bırakmasına izin vermeyen yapılandırılmış yansıtma gibi herhangi bir HA benzeri Çoğaltma

• Günlük dosyam neden bu kadar büyük?

Günlükleri kesilmekten ne tuttuğunu bilmek için tablodaki log_reuse_wait_desc sütununu kontrol edin sys.databases:

select name, log_reuse_wait_desc 
from sys.databases

• Bu sorunun oluşmasını önlemenin bazı yolları nelerdir?

Günlük yedeklemeleri, günlüklerin yeniden kullanılmasını önleyen bir şey olmadıkça günlük büyümesini kontrol etmenize yardımcı olur.

• Altta yatan neden ile kendimi takip ettiğimde ve işlem günlüğü dosyamı sağlıklı bir boyuta koymak istediğimde ne yapabilirim?

Eğer gerçekten neyin neden olduğunu tespit ettiyseniz, aşağıdaki sayfada açıklandığı şekilde düzeltmeye çalışın.

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

Olağandışı bir durum olmadıkça, uygun log yedeklerinin programlanmış olması log büyümesiyle başa çıkmanın en iyi yoludur.