Veritabanı her zaman kurtarma modunda başlar

Sunucumu her yeniden başlattığımda, veritabanı her zaman kurtarma modunda ve normal şekilde davranması yaklaşık 20 dakika sürüyor. Bu her zaman ve sadece sunucuyu yeniden başlattığımda olur, bu yüzden birkaç sorum var ...

Bunun büyük bir günlük dosyasından kaynaklanabileceği söylendi? Bu doğru olabilir mi? Değilse, diğer nedenler ne olabilir?
Kurtarmaları önlemek için günlük dosyasının alanını düşürmek gerekiyor. Hangisi daha iyi: küçülme veya kesilme?
Boyutu azaltmak için bir günlük dosyasını / veritabanını nasıl küçültebilir veya kısaltabilirim? Sözdizimi nedir?

Şu anda Microsoft SQL Server 2008 kullanıyorum.

sql-server-2008

Kapattığınızda büyük uçuşlarda işlem yapma eğiliminiz var mı? Kurtarma aralığı ne olarak ayarlanmıştır?

— Martin Smith

sunucu yeniden başlatılmadan 20 dakika önce hiçbir eylem gerçekleştirilmez, belirli deyimler dışında aralık 0 olarak ayarlanır.

Ne sıklıkta yeniden başlıyorsunuz? Veritabanını ne sıklıkla yedekliyorsunuz? Sunucuyu neden düzenli olarak yeniden başlattığınızı merak ediyorum. Tamamlamak için gerekirse bir veritabanını (günlüğü temizleyen) manuel olarak kontrol edebilirsiniz.

— Lynn Langit

"Tamamlanması için, gerekirse bir veritabanını (günlüğü temizleyen) manuel olarak kontrol edebilirsiniz." bu nasıl yapılabilir? ve bir günlüğü temizle dediğinizde, günlüğü kullanmamak veya silmekten mi bahsediyorsunuz?

Yeterli bilgi yok. Kurtarma modeli? Yansıtma veya çoğaltma gibi özellikler kullanıyor musunuz? Veritabanının boyutu ve ilgili dosyalar? Veritabanı idare mu herhangi büyük hareketleri?

— Jon Seigel

Yanıtlar:

Aynı sorunu yaşıyorum ve çözdüğüme inanıyorum ama onaylamak için tam olarak test edemedim.

Sorunların boyutunuzla değil, günlük dosyanızdaki VLF'lerin sayısıyla ilgili olduğuna inanıyorum. Büyük bir günlük dosyanız varsa, muhtemelen otomatik büyüme olayları yoluyla organik olarak büyüdüğü ve kasıtlı olarak planlanmış bir büyüme olmadığı muhtemeldir. Bu durumda, günlük dosyalarında binlerce VLF olabilir.

Burada ben den kullanılan kaç VLFs görmek için bir sorgu burada :

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

VLF'lerin ne olduğuna dair daha fazla açıklama için bu bağlantıya bakın .

Sorun çok sayıda VLF ile kendi durumunu değerlendirmek ve daha sonra veritabanını kurtarma dışında getirmek için SQL Server uzun bir süre alır inanıyorum. Günlük dosyanızı olabildiğince küçük boyuta, genellikle günlük dosyasında oluşturulan ilk VLF'nin boyutuna küçültürseniz, derhal yeniden büyütebilir ve böylece doğru sayıda VLF (daha az bir şey) oluşturmasını sağlayabilirsiniz. 16).

Bu tamamlandığında, veritabanınızın kurtarma işleminden çok daha hızlı geldiğini görebileceğinize inanıyorum.

Kendi VLF sorunlarımızı çözdükten sonra üretim örneklerinin başarısızlığını test etme şansım olmadı, bu yüzden sorunun temel nedeni olduğunu onaylayabiliyorsanız çok merak ediyorum. Deneysel olarak, evreleme ortamımızda restore edilmenin ortaya çıkma zamanının, bu yüzden umarım bu yüzden önemli ölçüde azaldığını gördüm.

— Chris Magnuson
kaynak

Bu sorunla ilgili daha fazla bilgiyi PSS blogunda bulabilirsiniz

— Martin Smith

Bu MSDN makalesinden :

Uzun süredir devam eden taahhütsüz işlemler, her türlü kontrol noktası için iyileşme süresini artırır.

Genellikle üretim veritabanlarında herhangi bir DBCC shrink dosyası çalıştırılması önerilmez. Ayrıca günlük kesme davranışı önceki sürümlerden 2008'e (teşekkürler @Edward) değişti - bu blog başına :

SQL 2008'de trucate_only ile yedekleme günlüğü artık desteklenmemektedir. Veritabanınız toplu günlüğe kaydedilmiş veya tam kurtarma modelindeyse, T-Log yedeklemesini düzenli aralıklarla programlayın ve t-log'unuzun şeklini koruyacaktır.

Tekrar söyleyeceğim, veritabanını ne sıklıkta yedekliyorsunuz? Genellikle, düzenli yedeklemeler günlük boyutunu en iyi şekilde yönetir.

— Lynn Langit
kaynak

Çevrimiçi işlem günlüğünün boyutunu azaltmak sorunu çözebilir, yani veritabanını çevrimiçi duruma getirmeyi hızlandırabilir, ancak bunu yapmadan önce olağanüstü durum kurtarma hakkında düşünmelisiniz. Basit kurtarma modelindeyseniz, zaman içinde bir noktaya geri yükleyemeyeceğinizi unutmayın. Öte yandan, TAM kurtarma modelindeyseniz, çevrimiçi işlem günlüğünün boyutunu korumanın en iyi yolu, düzenli olarak işlem günlüğü yedeklemesi oluşturmaktır (planlayın).

İşlem günlüğünün kesilmesi fiziksel sabit disk alanını boşaltmaz, yalnızca SQL Server'ın bu alanı son CHEKPOINT'ten (son işlem günlüğü yedeklemesinden bu yana) sonra gerçekleşen işlemler için yeniden kullanmasına izin verir.

Veritabanını küçültürseniz, dosyaların boyutunu küçültürsünüz. MyDB veritabanını yüzde 15 küçültmek için:

DBCC SHRINKDATABASE (MyDB, 15); GİT

— Carol Baker West
kaynak