Data dosyanıza göre çok büyük bir transaction logunuz varsa


SQL Server’da bazı durumlarda transaction logunuza data dosyanızdan çok daha büyük hale gelebilir.

Bunun en temel nedenlerinden birisi, açık bir transaction kalmış olmasıdır. Çünkü SQL Server transaction log’un açık ilk transaction bulunan alt bölümünden itibaren transaction logu aktik kabul eder ve küçültmeye çalışmaz.

Transaction logunuzun simple modda olmadığını varsayarsak, transaction logunuzun backup’ını alırsınız ve logunuz küçülebilir hale gelir. Ardından da dbcc shrinkfile’ı çalıştırarak dosyanın kullanılmayan kısımlarının işletim sistemine bırakılması yani fiziksel olarak küçülmesi sağlanabilir.

Bazı durumlarda backup almış olsanız bile dbcc shrinkfile, logu küçültmeyi başaramayabilir. Bu durumda dbcc opentran’ı kullanarak açık transactionları kontrol edin. Açık kalmış eski bir transaction bulup bunun kapanmasını sağlarsanız sorununuz çözülebilir.

Dbcc opentran, sorunlu bir açık ve eski transaction’a işaret etmiyorsa, dbcc loginfo ile logun virtual parçalarının durumuna bakın. İlgili veritabanına bağlanarak çalıştıracağınız bu komut, tüm virtual log parçaları için size birer satır verir. Status kolonunda 0 olanlar tekrar kullanılabilir parçalara, 2 olanlar ise aktif parçalara işaret eder. Backup aldığınız halde ve dbcc opentran sorunlu bir transactiona işaret etmediği halde logunuz küçülmüyorsa ve dbcc loginfo status’ta kabul edilemez sayıda satırda 2 veriyorsa, biraz sorununuz var demektir.

Başka çözümler de deneyebilirsiniz ama, eğer detach etme şansınızın olduğu zaman dilimleriniz varsa, tüm bağlantıları kestikten sonra veritabanının bir full yedeğini alıp veritabanını detach edebilirsiniz. Düzgün bir şekilde detach edebilirseniz kirli sayfaların veri dosyasına yazılacağı için recovery sırasında transaction logun var olmasını gerektirmeyecektir. (Readonly veritabanlarında BU DURUM GEÇERLİ DEĞİLDİR.) Transaction logu başka bir yere alıp sadece veri dosyalarını eklerseniz, SQL Server yeni bir log dosyası oluşturur. Böylece logunuz küçülmüş olur.

Bu son anlattığım çözüm YÜKSEK RİSK İÇEREBİLİR. Bu sebeple çalıştığından emin olmak için orijinal serverdan detach ettiğiniz dosyaları başka bir sunucuya kopyalayıp orada attach etmeyi denemeniz ve risk almamanız şiddetle tavsiye edilir.

Log dosyalarının anlam verilemeyen bir şekilde büyümesi, yedek alındığı halde shrink edilememisi, büyük olasılıkla veritabanı üzerinde koşan uygulamaların transaction yönetimindeki hatalardan kaynaklanmaktadır. Bu tür hatalar veritabanındaki bilgilerin tutarlılığıyla ilgili sorunlara da sebep olabileceğinden, bulunup giderilmeleri önemlidir.

Küçük bir not: Shrink komutunu verdiğiniz halde logunuz küçülmeyebilir. Log shrink edilmek üzere işaretlenmiştir ancak virtual logların boşa çıkıp shrink edilebilmenin gerçekten sağlanması için BACKUP LOG <> WITH TRUNCATE_ONLY komutunun da çalıştırılması gerekir.

Bu yazı SQL Server içinde yayınlandı. Kalıcı bağlantıyı yer imlerinize ekleyin.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s