AlwaysOn Kullanılabilirlik Grubunu Kullanırken İşlem Günlüğünü Küçült


17

AlwaysOn Availability GroupSQL Server 2012 özelliğini kullanıyoruz . Düzenli tam veritabanı yedeklemeleri ve işlem günlüğü yedeklemeleri her gün ikincil veritabanında yapılır.

Burada birincil çoğaltma veya ikincil çoğaltma işlem günlüğü yedekleme yaparken her iki kopya 'işlem günlükleri yeniden kullanılabilir olarak işaretler okudum . Her neyse, işlem günlüğü yedekleme boyutu büyüktür ve shrink dosyası kullanılarak azaltılabilir:

resim açıklamasını buraya girin

Ben yerel olarak veritabanını geri yükleme ve shrink işlemi gerçekleştirmek. Günlük dosyasının boyutu 160 MB'ye düşürüldü.

Benim sorum işlem günlüğü dosyası (birincil, ikincil veya her ikisi) üzerinde bir shrink işlemi gerçekleştirmeliyim?


Geçmişte birkaç yıl boyunca günlük dosyasının hiçbir yedeklemesi yapılmadığını tahmin ediyorum, bu yüzden çok büyük hale geldi. Yürütme DBCC SQLPERF (LOGSPACE)Sadece 0.06%dosyanın kullanıldığını görebiliyorum - günlük dosyasının bu kadar büyük boyutunu korumamın bir anlamı yok. In [sys].[database_files]ben onun kontrol max_sizeayarlandığında -1ile growthkarşı 65536o alacak daha fazla yere ihtiyacınız olduğunda sanırım bu yüzden. Her neyse, örneğin gelecekteki büyümeyi önlemek için% 5'e çekebilirim. Bunu yapmanın kötü bir fikir olmadığına dair bir onay bulmaya çalışıyorum.


Aslında, yedekler (veritabanında ve günlük dosyalarında) yalnızca ikincil veritabanlarında gerçekleştirilir, bu nedenle üzerlerinde shrink dosyası gerçekleştirmek daha kolay olacaktır, ancak birincil günlük dosyası boyutu da küçülecek mi?

Yanıtlar:


21

AG'lerde yazma işlemleri yalnızca birincil metin üzerinde yapılabilir. Shrink işlemleri yazıdır. Bu nedenle primerde büzülme yapmalısınız. Büzülmenin beklediğiniz kadar daralmayabileceğini unutmayın, geri yüklenen DB'deki testinizde muhtemelen basit kurtarma modeli kullanılmıştır. Daha fazla bilgi için SQL Server günlüğünü küçültme konusunu okuyun .

160 MB'a küçülmeyin. Belirleme neden o tekrar etmez böylece günlük 121TR için büyüdü (bir şüphe var, onaylayın mümkünse güzel olurdu). Günlüğü, işletme gereksinimlerinize uygun bir boyuta göre boyutlandırın. Günlük büyümesi ciddi bir sorundur, anlık dosya başlatmayı kullanamaz ve günlük büyürken ve 0 başlatılırken tüm veritabanı etkinliğiniz donar. Kullanıcılar ve uygulamalar gerçekleştiğinde bundan nefret eder. Eğer siz etkisini anlamak ve kullanıcıların Tamam, sen küçültmek kez küçük bir miktara (160MB muhtemelen çok küçük olsa) ve stabilize kadar büyümesine izin verin.


7

Deneyebilirsin:

  1. Kullanılabilirlik Grubundaki tüm sunuculardaki veritabanı Senkronize durumda olmalıdır.
  2. Küçültmeden önce kullanılmış sayfaları işlem günlüğünün başlangıcına taşıyın.
  3. Bazen kullanılabilir boş günlük alanı% 99'dur, ancak SQL Server kullanılmayan alanı serbest bırakamaz. Kullanılabilirlik Grubundaki her sunucuyu sırayla yeniden başlatmayı deneyin.
  4. Bazen, MS SQL Server boş alan bırakmadan önce işlem günlüğünü 2 kez pişirmeniz ve daraltmanız gerekir (Dosyanın sonunda bulunan mantıksal günlük dosyası kullanımda olduğundan günlük dosyasını daraltamaz (DB_Log).).

Bu komut dosyasını deneyin:

    - İş adımında veya komut dosyasında mevcut veritabanını ayarlama
    - Yalnızca Birincilde Yürütme Denetimi
    eğer (SELECT rolü
        FROM sys.dm_hadr_availability_replica_states AS bir
        Sys.availability_replicas AS b
            AÇIK b.replica_id = a.replica_id
    NEREDE b.replica_server_name = @@ SUNUCU ADI) = 1
    BAŞLA
        - [test_db] kullanın - MS SQL 2014 için çalışmıyor, sadece bu satıra yorum yapın ve mevcut veritabanını iş adımı veya komut dosyası içinde ayarlayın
        - 1) Bakup Trn
        YEDEKLEME GÜNLÜĞÜ [test_db] DİSK = N'D: \ MSSQL \ Backup \ test_db.trn 'NOFORMAT, INIT, NAME = N' Trn Yedekleme ', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
        - 2) Kullanılmış sayfaları taşıma
        DBCC SHRINKFILE (N'test_db_log ', 3000, NOTRUNCATE)
        - 3) SHRINKFILE Günlüğü
        DBCC SHRINKFILE (N'test_db_log ', 3000)
    SON
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.