Forum

Disk %99 iken shrin...
 
Bildirimler
Hepsini Temizle

Disk %99 iken shrink yapılamaması (AlwaysOn)

4 Yazılar
2 Üyeler
0 Reactions
2,691 Görüntüleme
(@keremgoktay)
Gönderiler: 118
Üye
Konu başlatıcı
 

Merhaba,

Mevcut yapıdaki SQL Sunucularında SQL DB logları yükseliyor, hard diskte hiç yer kalmadığı için logları silmek içinde always on grubundan çıkartılıp loglar shrink edilip tekrardan dahil edilme gibi bir yöntem izleniyor.

Google üzerinden baktığımda, 

http://realit1.blogspot.com/2016/02/shrinking-database-log-files-in.html

https://dba.stackexchange.com/questions/73850/shrink-transaction-log-while-using-alwayson-availability-group

Diske doğru kayıt etmeden sonra shrink etme verilmiş ama yükselme durumunda ilgili diskte çok fazla yer olmuyor.

Bu iş için izlenen en doğru yöntem nedir?

 
Gönderildi : 27/08/2018 15:07

(@keremgoktay)
Gönderiler: 118
Üye
Konu başlatıcı
 

Merhaba,

Sorum zaten diskte yer olmaması yönünde ne yapılması gerektiği idi. 

Yani, 500 gb lık bir diskte, 490 gb log oluşuyor. Var olan yapıda shrink ederken %10 büyüme gibi davrandığından yer yetmiyor ve silemiyor.

Bu yüzden always ondan çekip, simple moda çekip shrink ediyoruz. Bunun önüne geçebilmenin bir yöntemi var mı diye ona bakıyorum.

 
Gönderildi : 27/08/2018 18:35

(@cankaya)
Gönderiler: 119
Üye
 

Merhaba Göktay Bey,

Öncelikle log çok önemli veriler içermektedir. Sizi veri kaybından korur. Bu yüzden log almanız sizin için çok önemli. En son full backup üzerine aldığınız yedekler kadar veri kaybının önüne geçersiniz. Always ON replikasyonunuz olduğu için biraz daha rahat hissediyor olabilrsiniz ancak size şiddetle bir yedekleme politikası belirleyip o politikaya uymanızı öneririm. 

Önermesem de en azından Şu an ki yönteminizi kolaylaştırmak için size aşağıda bir çözüm öneriyorum. Bu yöntem şu an sizin yaptığınız yöntem gibi. Loglarınızı kaybedecektir.

BACKUP LOG YOURDATABASENAME TO DISK = N'NUL' WITH STATS = 10

bu komut diskte yeriniz yoksa log file da biriken VLF leriniz boşaltmaya yarıyor. Linuxtaki /dev/null a göndermek gibi düşünebilirsiniz. Replikasyonunuz sorunsuz ilerliyorsa bu komutu düzenleyerek 10 dakikada bir agent job tanımlayıp schedule edebilirsiniz. 

Bu sayede AG grubundan koparıp shrink etmeniz gerekmez.

NFS üzerinden bir yere yedek almanızı ve yukardaki komutu kullanmamanızı öneririm. 

Logunuzun bu kadar büyümesinin önüne geçebilir ve çıkan tüm yedek filelarınıza retention belirleyerek sorunu kalıcı olarak çözebilirsiniz. 10 GB data file 490 GB log file sorun tam olarak burada.

Merhaba,

Sorum zaten diskte yer olmaması yönünde ne yapılması gerektiği idi. 

Yani, 500 gb lık bir diskte, 490 gb log oluşuyor. Var olan yapıda shrink ederken %10 büyüme gibi davrandığından yer yetmiyor ve silemiyor.

Bu yüzden always ondan çekip, simple moda çekip shrink ediyoruz. Bunun önüne geçebilmenin bir yöntemi var mı diye ona bakıyorum.

 
Gönderildi : 27/08/2018 18:45

(@keremgoktay)
Gönderiler: 118
Üye
Konu başlatıcı
 

Teşekkürler Can bey,

 

NFS üzerinden bir yere yedek almanızı ve yukardaki komutu kullanmamanızı öneririm. 

Logunuzun bu kadar büyümesinin önüne geçebilir ve çıkan tüm yedek filelarınıza retention belirleyerek sorunu kalıcı olarak çözebilirsiniz. 10 GB data file 490 GB log file sorun tam olarak burada.

 

 

Aslinda soyle, her gece zaten normal sunucu uzerine ayri bir diske backup aliyoruz, bunun disinda Comcell adli backup ürünü SQL backupta gelip aliyor. Yani backuplarin alinma durumu yok degil. Aynı şekilde maintenance plan olarakta her gün transaction log alınıp, shrink file ile ilgili bir jobımız mevcut. Fakat sorun, bütün bu işlemlerden sonra maint taskı başarılı olarak bitmesine rağmen logların silinmemesi.

 

Bu arada verdiğiniz komut muhtemelen çalışacaktır, şu anda aynı senaryoyu yapmaya çalıştık ama loglar silindi.

Biz diskin doluluk oranına bağlamıştık, ama aynı senaryoyu şimdi yapınca logları silme yaptı. Problem olursa, komutu deneyip sonucunu yazarım.

 

 

 
Gönderildi : 27/08/2018 19:10

Paylaş: