Bir günlük dosyasını küçültmek, tekrar olmasını beklemediğiniz beklenmedik büyümeyle karşılaştığı senaryolara ayrılmalıdır. Günlük dosyası tekrar aynı boyuta büyürse, geçici olarak küçülterek çok fazla şey başarılmaz. Şimdi, veritabanınızın kurtarma hedeflerine bağlı olarak, yapmanız gereken eylemlerdir.
İlk olarak, tam bir yedek alın
Bir şey ters gittiğinde geri yükleyebilmenizi sağlamadan veritabanınızda asla değişiklik yapmayın.
Zamanında iyileşmeyi önemsiyorsanız
(Zamanında kurtarma ile, tam veya farklı bir yedeklemeden başka bir şeye geri yükleme yapabileceğinizi kastediyorum.)
Muhtemelen veritabanınız FULLkurtarma modunda. Değilse, olduğundan emin olun:
ALTER DATABASE testdb SET RECOVERY FULL;
Düzenli tam yedeklemeler alsanız bile, günlük dosyası bir günlük yedeklemesi gerçekleştirene kadar büyüyecek ve büyüyecektir - bu sizin güvenliğiniz içindir, disk alanınızda gereksiz yere yemek yememek değil. Kurtarma hedeflerinize göre bu günlük yedeklemelerini sık sık gerçekleştiriyor olmalısınız. Örneğin, bir felaket durumunda 15 dakikadan fazla veri kaybetmeyi göze alabileceğinizi belirten bir iş kuralınız varsa, günlüğü 15 dakikada bir yedekleyen bir işiniz olmalıdır. İşte şimdiki zamana göre zaman damgalı dosya adları üretecek bir komut dosyası (ancak bunu bakım planları vb. İle de yapabilirsiniz, sadece bakım planlarındaki küçültme seçeneklerinden herhangi birini seçmeyin, korkunçturlar).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
Bunun \\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 diskleri kullanan farklı bir makineye veya aynı fiziksel ana bilgisayarda bulunan farklı bir VM'ye) yedeklemek size gerçekten yardımcı olmaz, çünkü makine patlarsa veritabanınızı kaybettiniz ve yedekleri. Ağ altyapınıza bağlı olarak, yerel olarak yedekleme yapmak ve daha sonra bunları sahne arkasındaki farklı bir konuma aktarmak daha mantıklı olabilir; her iki durumda da, onları birincil veritabanı makinesinden olabildiğince çabuk çıkarmak istersiniz.
Şimdi, düzenli günlük yedeklemeleriniz çalıştıktan sonra, günlük dosyasını şimdiye kadar patladığından daha makul bir şeye küçültmek mantıklı olmalıdır. Bu mu değil çalışan anlamına SHRINKFILEdefalarca günlük dosyası 1 MB kadar - sık günlüğü yedekleme bile, yine de oluşabilir herhangi eşzamanlı işlemlerin toplamı karşılamak gerekiyor. SQL Server dosyaları sıfırlamak zorunda olduğu için günlük dosyası otomatik büyüme olayları pahalıdır (anlık dosya başlatma etkinleştirildiğinde veri dosyalarının aksine) ve bu işlem sırasında kullanıcı işlemleri beklemek zorundadır. Bu büyümek-küçültmek-büyümek-küçültmek rutini mümkün olduğunca az yapmak istiyorsunuz ve kesinlikle kullanıcılarınızın bunun için ödeme yapmasını istemiyorsunuz.
Büzülme mümkün olmadan önce günlüğü iki kez yedeklemeniz gerekebilir (teşekkürler Robert).
Bu nedenle, günlük dosyanız için pratik bir boyut bulmanız gerekir. Burada kimse sisteminiz hakkında çok daha fazla şey bilmeden size ne olduğunu söyleyemez, ancak günlük dosyasını sık sık küçültüyorsanız ve tekrar büyüyorsa, iyi bir filigran muhtemelen en büyük olandan% 10-50 daha yüksektir . Diyelim ki 200 MB'a geliyor ve sonraki otomatik büyüme olaylarının 50 MB olmasını istiyorsanız, günlük dosyası 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 iyileşmeyi umursamıyorsanız
Bu bir sınama veritabanı ise ve zaman içinde kurtarmayı umursamıyorsanız, veritabanınızın SIMPLEkurtarma modunda olduğundan emin olmalısınız .
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Veritabanını SIMPLEkurtarma moduna getirmek, SQL Server'ın tüm işlemlerin ( FULLgünlük kaydı yedekleninceye kadar kurtarma işlemi gibi) kaydını tutmak için büyümek yerine günlük dosyasının bölümlerini (esas olarak etkin olmayan işlemlerin aşamalı olarak kaldırılması) kullanmasını sağlar . CHECKPOINTolaylar günlüğün kontrolüne yardımcı olur ve CHECKPOINTs arasında çok fazla t-log etkinliği üretmediğiniz sürece büyümesinin gerekmediğinden emin olur .
Daha sonra, bu günlük büyümesinin gerçekten normal bir günlük kullanımdan değil, anormal bir olaydan (örneğin, yıllık bir bahar temizliği veya en büyük dizinlerinizi yeniden oluşturması) kaynaklandığından emin olmalısınız. Günlük dosyasını gülünç derecede küçük bir boyuta küçültürseniz ve SQL Server'ın normal etkinliğinize uyması için yeniden büyütmesi gerekiyorsa, ne kazandınız? Serbest bıraktığınız disk alanını geçici olarak kullanabildiniz mi? Derhal 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
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
Aksi takdirde, uygun bir boyut ve büyüme oranı ayarlayın. Zamanında kurtarma durumundaki örneğe göre, hangi dosya boyutunun uygun olduğunu belirlemek ve makul otomatik büyüme parametrelerini ayarlamak için aynı kodu ve mantığı kullanabilirsiniz.
Yapmak istemediğiniz bazı şeyler
Günlüğü TRUNCATE_ONLYseçenekle yedekleyin ve sonraSHRINKFILE . Birincisi, bu TRUNCATE_ONLYseçenek kullanımdan kaldırılmıştır ve SQL Server'ın geçerli sürümlerinde artık mevcut değildir. İkincisi, FULLkurtarma modelindeyseniz, bu günlük zincirinizi yok eder ve yeni, tam bir yedekleme gerektirir.
Veritabanını ayırı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 görünebilir, bir yedeğe (varsa) geri dönmeniz gerekebilir.
"Veritabanını küçült" seçeneğini kullanın . DBCC SHRINKDATABASEve aynısını yapmak için bakım planı seçeneği, özellikle yalnızca bir günlük sorunu sorununu çözmeniz gerektiğinde kötü fikirlerdir. Kullanarak, ayarlamak istediğiniz ve bağımsız olarak ayarlamak dosyayı Hedef DBCC SHRINKFILEveya ALTER DATABASE ... MODIFY FILE(örnekler üzerinde).
Günlük dosyasını 1 MB'ye küçültün . Heyecan verici görünüyor çünkü, hey, SQL Server bunu belirli senaryolarda yapmama izin verecek ve serbest bıraktığı tüm alana bakacak! Veritabanınız salt okunur olmadığı sürece (ve bunu kullanarak olduğu gibi işaretlemeniz gerekir ALTER DATABASE), bu günlük sadece kurtarma modelinden bağımsız olarak mevcut işlemleri barındırmak zorunda olduğundan, gereksiz birçok büyüme olayına yol açacaktır. SQL Server'ın yavaş ve acı verici bir şekilde geri alabilmesi için bu alanı geçici olarak boşaltmanın anlamı nedir?
İkinci bir günlük dosyası oluşturun . Bu, diskinizi dolduran sürücü için geçici olarak rahatlama sağlayacaktır, ancak bu delinmiş bir akciğeri bir bant yardımı ile düzeltmeye çalışmak gibidir. Sorunlu günlük dosyasıyla, başka bir potansiyel sorun eklemek yerine doğrudan ilgilenmelisiniz. Bazı işlem günlüğü etkinliklerini farklı bir sürücüye yeniden yönlendirmek dışında, ikinci bir günlük dosyası sizin için hiçbir şey yapmaz (ikinci bir veri dosyasının aksine), çünkü aynı anda dosyalardan yalnızca biri kullanılabilir. Paul Randal, birden çok günlük dosyasının neden daha sonra sizi ısırdığını da açıklıyor .
Proaktif olun
Günlük dosyanızı bir miktar küçültmek ve sürekli olarak kendi başına küçük bir oranda otomatik olarak büyümesine izin vermek yerine, makul ölçüde büyük bir boyuta (en büyük eşzamanlı işlem kümenizin toplamını barındıracak şekilde) ayarlayın ve makul bir otomatik büyüme ayarlayın tek bir işlemi tatmin etmek için birden fazla büyümek zorunda kalmamak ve böylece normal iş operasyonları sırasında büyümesi nispeten nadir olacaktır.
Buradaki olası en kötü ayarlar 1 MB büyüme veya% 10 büyüme. Oldukça komik, bunlar SQL Server için varsayılanlar (ki şikayet edip boşuna değişiklik istediğim ) - veri dosyaları için 1 MB ve günlük dosyaları için% 10. Birincisi bu gün ve yaşta çok küçük ve ikincisi her seferinde daha uzun ve daha uzun olaylara yol açıyor (diyelim ki günlük dosyanız 500 MB, ilk büyüme 50 MB, bir sonraki büyüme 55 MB, bir sonraki büyüme 60.5 MB - ve yavaş G / Ç'de, inanın bana, bu eğriyi gerçekten göreceksiniz)
daha fazla okuma
Lütfen burada durmayın; günlük dosyalarını daraltma konusunda gördüğünüz tavsiyelerin çoğu doğal olarak kötü ve hatta potansiyel olarak felaket olsa da, disk bütünlüğünü boşaltmaktan çok veri bütünlüğüne önem veren bazı insanlar var.
2009 yılında yazdığım bir blog yazısı, birkaç "günlük dosyasını nasıl küçülteceğimizi" gördüğümde yayınlar ortaya çıkıyor .
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'ın t-log bakımının neden önemli olduğunu ve veri dosyalarınızı neden küçültmemeniz gerektiğini açıklayan bir blog yazısı .
Mike Walsh, günlük dosyanızı hemen küçültememenizin nedenleri de dahil olmak üzere bu yönlerden bazılarını da kapsayan harika bir cevaba sahiptir .
