Arkadaşlar dün yeni bir şey daha öğrenmiş olduk, fakat bu öğrendiğimiz şeyi geç öğrenmenin bedelini de ödedik.
SQL Server 2008'e geçtiğimizden beri Index bakımı yapılan zamanlarda Transaction Log yedeklerimizin eskiye nazaran çok büyüdüğünü gözlemledik ve Transaction Log yedeklerimizi aldığımız disk artık yetmez oldu. Acilen ekstra disk talep ederek bu sorunu atlattık, ama anlayamadığımız şey neden birden böyle bir sorunla karşılaştığımızdı. Kayıt sayılarında böyle ani bir artık beklenecek bir durum yoktu ortada, en azından işlemler açısından.
Sağolsun MS PFE'mizin bize ilgili KB'yi iletmesiyle sorun anlaşıldı. SQL Server 2008'den itibaren, Online Index Rebuild işlemleri Transaction Log dosyasına artık tam olarak işleniyormuş. SQL Server 2005'te bu işlem asgari seviyede yapılıyormuş. Bu sorunu kritik sistemlerimizi SQL Server 2008'e yükseltince farkettik, çünkü malum kritik sistemler en fazla kayıdın oluştuğu sistemler ve bu nedenle de Transaction Log'un en çok kullanıldığı, en büyük Transaction Log yedeklerinin oluştuğu sistemler.
Daha fazla bilgi için ilgili KB'yi incelemek isteyebilirsiniz: http://support.microsoft.com/kb/2407439
4 yorum:
Transacrion Log Backupları compress alırsanız eski size larından daha küçük olur:)
Slm,
Bu KByi paylaşırmısınız, bu arada ek disk eklemenin dışında bu sorunun kalıcı bir çözüm var mı?
Tşk...
KB'nin adresini eklemiştim; ama çıkmamış, şimdi düzelttim =)
Sevgili Mehmet, tabii ki o da bazılarına göre bir çözüm olabilir, fakat bizim için değil. Çünkü biz aynı zamanda DR çözümü olarak Log Shipping de kullanıyoruz. Birden fazla Secondary sunucumuz var ve bazıları şehirdışında. O sunuculara T-Log yedeklerini göndermeden önce bu dosyaları RAR ile sıkıştırıyoruz. Şayet T-Log yedek dosyalarını SQL Server'ın Native sıkıştırma yöntemiyle sıkıştırırsak, daha sonra RAR normalde olduğu kadar başarılı olmuyor. Bu nedenle Native Compression'ı kullanmamayı tercih ediyoruz.
Muhtemelen kimse bana neden Native Compression'ı değil de RAR'ı seçtiğimizi sormayacaktır =)
Yorum Gönder