Basit Kurtarma'ya geçerken İşlem Günlüğü bakımı


9

Arka fon:

Kısa süre önce 450'den fazla veritabanına sahip 50'den fazla SQL Sunucusunu devraldım. Gece yedeklemeleri yaklaşık 8 TB'tır ve söylemeye gerek yok, istediğimizden daha fazla disk alanı kullanıyoruz. Tüm veritabanları TAM kurtarmaya ayarlanmıştır ve işlem günlükleri hiçbir zaman yedeklenmemiştir. Tüm SQL Server'lardan geçtim ve sadece gece yedekleme ve bir gün veri kaybının kabul edilebilir olduğu düşük öncelikli olanları belirledim.

Soru:

Çok düşük öncelikli veritabanlarını SIMPLEkurtarma modundan değiştiriyorum FULL. Mevcut işlem günlükleri kısaltılacak mı (kontrol noktaları oluşturulduğunda)? Mevcut işlem günlüklerinden bazıları 50-100 GB; ilerlemek için neyi küçültmem gerektiğini belirlemede en iyi yaklaşım nedir? Açıkçası onları bu kadar büyük tutmak istemiyorum. Yoksa zamanla kendiliğinden küçülecekler mi (yapacaklarını sanmıyorum)?

Yanıtlar:


2

Dan açmadan önce FULLiçin SIMPLEkurtarma modeli, kaybedecek göze ne kadar veri kendinize sorun. Bir felaket durumunda, son veritabanı yedeklemesini geri yüklemeyle iyi durumda olduğunuz veritabanları SIMPLEiçin Tamam olmalıdır. Eğer durum böyle değilse, birlikte kalın FULL.

LDFDosyayı olabildiğince küçük bir boyuta küçültmek için , Kimberly Tripp tarafından verilen adımları izleyin: Daha iyi İşlem Günlüğü çıktısı için 8 Adım

  1. Veritabanında düşük etkinlik olduğunda bekleyin

  2. SSMS'de çalıştır:

    DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)
  3. İşlem günlüğü dosya boyutunu değiştirin:

    ALTER DATABASE db_name
    MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

1
Ben ediyorum değil önermek SHRİNK o kadar, günlük büyür iken VLF parçalanma ve tüm veritabanı iş yükü duraklatılacak neden olacağından Günlüğü dosyaları anlık başlatma kullanamaz işlem günlük dosyası .
Kin Shah

9

TAM kurtarma modundan çok sayıda veritabanını BASİT kurtarma moduna geçiriyorum (T-Günlükleri ve zaman içinde kurtarma gerekli değildir). Mevcut işlem günlükleri kesilecek mi (kontrol noktaları oluşturulduğunda)?

Basit kurtarma modelinde, veritabanı motoru otomatik kontrol noktaları yayınlar ve sıklığı kurtarma aralığı (gelişmiş sunucu yapılandırma ayarı) veya günlük% 70 doluysa belirlenir.

Günlük kesmeyi geciktirecek uzun süren bazı işlemleriniz yoksa, otomatik bir denetim noktası T günlüğünün kullanılmayan kısmını keser.

Mevcut işlem günlüklerinden bazıları 50-100GB'dur, ilerlemek için neyi küçültmem gerektiğini belirlemede en iyi yaklaşım nedir? Açıkçası onları bu kadar büyük tutmak istemiyorum.

50-100 GB T günlüklerine sahip veritabanı için veritabanı kurtarma modelini FULL olarak ayarladıysanız, sık sık T-log yedeklemesi yapmaya başlamanız gerekir. Tam kurtarma modelinde, bir günlük yedekleme zinciri oluşturulduktan sonra, otomatik kontrol noktaları bile günlüğün kısalmasına neden olmaz.

Son çare olarak, günlük dosyasını kısaltabilir ve hemen tam bir yedek alabilir ve ardından bir felaket olursa zamanında kurtarma yapabilmeniz için T-log yedeklerini almaya başlayabilirsiniz.

Yoksa zamanla kendiliğinden küçülecekler mi (yapacaklarını sanmıyorum)?

@TomTom'un işaret ettiği gibi, manuel bir işlemdir.

Oku :


2

Sorunun çoğu tarafımızdan cevaplanamaz. Bir ip parçası ne kadardır?

Mevcut işlem günlüklerinden bazıları 50-100GB'dur, ilerlemek için neyi küçültmem gerektiğini belirlemede en iyi yaklaşım nedir?

Olmaları gerektiği sürece. Küçülmemesini öneririm. Günlükleri trunacate, bir hafta içinde geri dönün ve ne kadar alan kullanıldığını görün, sonra karar verin. Ama buna cevap vermelisin.

Gece yedeklemeleri yaklaşık 8 TB'tır ve söylemeye gerek yok, istediğimizden daha fazla disk alanı kullanıyoruz.

Peki neden onları basitleştirelim? Gerçekten diyorum.

Tüm veritabanları TAM kurtarmaya ayarlanmıştır ve işlem günlükleri hiçbir zaman yedeklenmemiştir.

Küçük bir mantık size ONCE onları keserseniz, muhtemelen onları yedeklemek için çok daha az alan kullanacağınızı söyleyecektir. Sonuç, onları tam kurtarma modunda iyi tutabilmeniz olabilir. Önce deneyin. Eğer ralli düşük hacimli ise, o zaman kütük yedekleri gelecekte çok daha küçük olacaktır.

Tüm SQL Server'ları geçtim ve sadece bir gece yedeklemesine ihtiyaç duyan DÜŞÜK öncelikli olanları tespit ettim ve bir felakette bile bir günlük veri kaybı sorun olmayacak (Faks veritabanları ve bunun gibi şeyler).

Evet. Bu, mahkemeye çıkana ve kritik yasal belgelere sahip olmadığın için kıçını teslim edene kadar. Faks günlüklerinin işle ilgili bilgiler olarak yıllarca saklamanız gerekenlerin bir parçası olabileceğini biliyor musunuz? Benim yetki alanımda (10 yıl) böyle. Eğer bir U hisse senedi şirketi iseniz benzer sürpriz olabilir (SOX). Bunu yapmamanız, faks alamadığınızı kanıtlamak istiyorsanız mahkemede ÇOK kötü yapar. Yoksa gönderdim. Kimse bunun aylık olarak olup olmadığını umursamıyor ve daha yeni günlükleriniz var - yasa gereksinimlerini geçemezsiniz. Bunun çok yüksek biri tarafından kapatıldığından emin olun, çünkü işiniz kritik olmayan işiniz ateşleme nedeniniz olabilir.

Yoksa zamanla kendiliğinden küçülecekler mi (yapacaklarını sanmıyorum)?

Hayýr. Ve bunu yapmamalýlar. Günlük yeniden boyutlandırma, düşük hacimli veritabanları dışında manuel bir işlemdir.


Geri dönüşünüz için teşekkür ederiz. İlk noktaya katılıyorum ve onlara göz kulak olacağım. Günlük kaydı hakkında endişelenmenize gerek kalmayacak şekilde onları basit olarak ayarlamak. ve onları tutmamız gerekmiyor. TAM kurtarmada kalmak ve günlük yedeklerini almaya başlamak (küçük olsalar bile) hala sahip olmadığımız ek alan. DÜŞÜK öncelikli SQL Sunucularının belirlenmesi üstümde verilen bir ticari karardı.
BamBamBeano
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.