10 Temmuz 2015 Cuma

Bir forum hikayesi: Shrink it and everything's gonna be fine...

Selam millet,

Dün (9 Temmuz 2015) birisi MSDN SQL Server forumlarında yaşadığı kapasite sorunuyla ilgili bir soru sordu, ibretlik olsun diye bunu bu yazımda irdelemek istiyorum.

Soru şöyle (Noktası virgülüne aynı):
"Hi all,
i've a server which is reside in remote area. my database store in drive E where disk capacity is 1000 GB and DB size reached 800GB , now disk free space showing 10 GB only . how to manage space.
couple of week back i've tried to shrink the database but it is not completed successfully and since the time db size drastically increase. now i'm sitting in corner. please help anyone to resolve this issues.
can we perform partial shrink only on MDF. so that we can manage the space (starting from 10 gb only)
if yes then please share the T-sql script."
Türkçesi:
"Herkese merhaba,

Uzaktaki bir sunucum var. Veritabanı E: diskinde ve kapasitesi 1TB ve veritabanının boyutu da 800GB'a ulaştı, şimdi diskteki boş alan sadece 10GB. Diskteki boşluk durumunu nasıl yönetebilirim?

Birkaç hafta önce veritabanını küçültmeye (Shrink) çalıştım, ama işlem başarıyla tamamlanmadı ve o zamandan beri veritabanının boyu ciddi şekilde arttı. Şimdi çaresiz kaldım, lütfen biri bu sorunu çözmem için yardımcı olsun.

Shrink işlemini sadece veri dosyaları (*.mdf) için yapabilir miyiz? Eğer öyleyse boş alan sorununun bu şekilde halledebiliriz.

Eğer böyle bi şey yapılabiliyorsa lütfen T-SQL Script'ini paylaşın."

Sorunun yorumu:
Şimdi bu sorudan hemen anlaşılıyor ki, bahsi geçen bu firmada bir SQL Server uzmanı yok. Muhtemelen her şeyle ilgilenmeye çalışan bir arkadaşa bu sorumluluk da verilmiş veya nispeten boyut olarak büyük sayabileceğimiz bu veritabanlarını yönetmek için bir Junior çalıştırıyorlar.

İlk gözlemler olarak şunları söyleyebilirim, bu arkadaş her şeyden önce kapasite planlaması yapmıyor. Veritabanlarının ortalama ne hızda büyüdüğünü bilmiyor. Shrink işleminin ne işe yaradığını ve sonuçlarını bilmiyor. Böyle bir durum ile önceden hiç karşılaşmamış.

Olabilir, profesyonel hayata dair sanırım hiçbir şeyi hiçbirimiz annemizin karnında öğrenmiyoruz. AMA! Sen gelmişssin uluslararası bir platformda bu sorununu paylaşmışsın. Sana defaatle "Güzel kardeşim, yapma, etme, Shrink senin sorununun çözümü değil" denmiş, ama belli ki bu konuda hiç tecrübesi olmayan biri "Shrink'e devam et sen kardeşim, iyidir" demiş ve sen çaresizce onu yapmaya devam etmişsin.

Sorunun ideal çözümü:
Dün ben ve başka arkadaşlar tekrar tekrar şunları önerdik:
- Mümkünse büyük ve gereksiz olan tablolardan temizlik yap,
- Eğer Transaction Log dosyanın boyutu çok büyükse, bunu en azından geçici bir süre için de olsa Shrink etmende sıkıntı yok (çünkü veri ve Transaction Log dosyaları aynı diskteydi),
- Yeni disk ekle! Çünkü Transaction Log dosyası veritabanının boyutuyla karşılaştırıldığında büyük değildi ve belli ki veritabanının büyümesi, tek seferlik bir işlemden kaynaklanan bir şişme durumu değildi.
- Eğer mümkünse, böyle bir durumda zaman kazanmak için Enterprise Edition kullanıyorsan (ve tabii CPU kaynakların da yeterliyse) Data Compression'ı düşünebilirsin.

Sonuç:
Şimdi bu sorunu yaşayan arkadaş dün heyecandan, çaresizlikten veya belki de yapabileceği hiçbir şey olmadığından veya saflğından diyeyim siz başka anlamlar yükleyin, bizim önerilerimiz yerine böyle bir sorun karşısında ısrarla Shrink'i öneren birisini dinledi. Böyle bir durumda Shrink'i önerebilecek biri, zaten hayatında 10GB'tan büyük veritabanı yönetmemiştir. Shrink'in tam olarak ne anlama geldiğini, ne zaman yapılabileceğini ve ne işe yaradığını da bilmiyordur. Fakat biz bunu, soru sorana anlatamadık. Sonra ne mi oldu? Devamı aşağıda.

Sorunu yaşayan arkadaş bu sabah (10 Temmuz 2015) şöyle iki cevap daha vermiş:

"big problem in front of me. disk space gradually decrease and application performance down,
now it is showing
Msg 904, Level 16, State 1, Line 1Database 11 cannot be autostarted during server shutdown or startup."

Türkçesi:
"Büyük bir sorunum var. Diskteki boş alan miktarı adım adım azaldı ve uygulama performansı da düştü. Şu anda şu hataları alıyorum:

Msg 904, Level 16, State 1, Line 1
Database 11 cannot be autostarted during server shutdown or startup.
"

Hemen akabindeki diğer mesajı:

"now while connecting to the database 
massage showing 'database vts not accessible'
help me to fix this issues"

Türkçesi:
"Şimdi, veritabanına bağlanmaya çalıştığımda 'Veritabanına erişilemiyor' hatası alıyorum.

Bu sorunları çözmem için yardımcı olun."

Bu saatten sonra yapabileceği tek şey artık çok daha zor koşullarda yeni bir disk eklemek, ardından ilgili dosya grupları için bu diske yeni dosyalar eklemek. Tabii ki veritabanına erişebilirse ve kesintinin yarattığı stres ile başa çıkabilirse.

İnsanlar bir gün elbette bu işin çocuk oyuncağı olmadığını anlayacak.

Ekrem Önsoy

1 yorum:

Ali Taş dedi ki...

çok açıklayıcı olmuş hocam elinize sağlık .