Database Corruption

Arkadaşlar merhaba,

Az önce bir arkadaşım telaşlı bir durumda aradı ve kısa bir süre sonra telaşının nedeni anlaşıldı. 150GB boyutundaki bir veritabanı Corrupt olmuştu.

Bu arkadaşım çalıştığı firmada sistem yöneticisi olarak çalışıyor ve birçok konuda kendisi sorumlu. Windows ve diğer işletim sistemlerinin yönetiminden, ağdan, güvenlikten ve veritabanından gibi. Daha geçenlerde görüşmüştük kendisiyle ve bana şirketinin bütçe ayırmadığından dolayı veritabanı yönetimi konusunda danışmanlık hizmeti alamadığından yakınmıştı.

"Umarım dokunmadın?" dedim, "Dokundum…" dedi. "Ne yaptın?" dedim, "internetten okudum ve DBCC CHECKDB…" derken lafını kestim, "ALLOW_DATA_LOSS parametresiyle çalıştırdın değil mi?" dedim "Evet, 15 saattir devam ediyor. Ne yapabiliriz?" dedi. Bu noktada kendisine yapabileceğim hiçbir şey kalmadığını, bu veritabanına dair en iyi yedeği bulması gerektiğini, eğer sorun güç kesintisindense bunu, SAN'dense onu düzeltip yedekten öyle dönmesi gerektiğini söyledim.

DBCC CHECKDB komutunu Microsoft'ta baştan sona tekrar yazan kişi Paul S. Randal'dır, kendisiyle daha dün başka bir konuda gece e-posta yoluyla konuşuyorduk. Paul DBCC CHECKDB ile ilgili verdiği derslerde, yazdığı makalelerde özellikle ve bıkmadan vurgular, veritabanınız Corrupt olduysa, DBCC CHECKDB'yi "ALLOW_DATA_LOSS" komutuyla çalıştırmak eğer yedeğiniz de yoksa ve o kadar çaresizseniz ve bol bol da vaktiniz varsa ancak o zaman yapılabilirdir.

Bununla birlikte, lütfen ama lütfen beni veya başka bir SQL Server danışmanını Corruption hakkında internetten okuyup bir şeyler uyguladıktan sonra değil, önce arayın. Çünkü yaptığınız her müdahale ile bizim bir şeyleri kurtarma ihtimalimizi azaltıyorsunuz.

Bir veritabanınız herhangi bir nedenden dolayı kullanılamaz duruma geldiğinde ilk bakacağınız şey yedekleriniz olmalı. Ardından eğer veritabanınızı o durumdan kurtarma ihtimalinizi değerlendirmek istiyorsanız ve kurumunuzun bünyesinde de deneyimli bir veritabanı uzmanı yoksa lütfen bir veritabanı danışmanına başvurun.

Lütfen sağlıklı işleyen bir yedekleme stratejiniz olduğundan emin olun, emin olamıyorsanız yine bir veritabanı danışmanına başvurun. Ayrıca sadece veritabanlarınızın yedeklerini almakla yetinmeyin, güzel ve işleyen bir veritabanı yedek kontrol sisteminiz olduğundan da emin olun. Unutmayın, şirketlerin en değerli varlıkları verilerdir.

Ekrem Önsoy

CHOOSE fonksiyonu

Merhaba arkadaşlar,

SQL Server'daki CHOOSE fonksiyonunu biliyor muydunuz? Bu fonksiyon SQL Server 2012 ile birlikte geldi. 

SELECT ..., 'xxx' = CASE WHEN yyy = 1 THEN 'xy' ... END ...

Yukarıdaki örnekteki gibi durumlar için pratik bir kullanım sağlayabilir CHOOSE komutu. Örneğin:

SELECT CHOOSE (alan1, 'Manager', 'Director', 'Developer', 'Tester' ) AS Result FROM tablom1;

CHOOSE ile yukarıdaki yazdığım komutun CASE WHEN'lisi şöyle:

SELECT 'Result' = CASE WHEN alan1 = 1 THEN 'Manager'  WHEN alan1 = 2 THEN 'Director' WHEN alan1 = 3 THEN 'Developer' WHEN alan1 = 4 THEN 'Tester' END FROM tablom1

Performans açısından bir katkısı yok, ama dediğim gibi kod yazma konusunda kolaylık sağlıyor.

Bu fonksiyon hakkında daha fazla bilgi için BOL'dan faydalanabilirsiniz:

http://msdn.microsoft.com/en-us/library/hh213019(v=sql.110).aspx

Ekrem Önsoy

TransSQL: SQL Server ortamlarınıza kod taşıma

Merhaba arkadaşlar,

Bir süredir bu bloguma bir şey yazamadım, takip eden arkadaşlarımın tahmin ettiği gibi TransSQL isimli SQL Server ortamları arasında kod taşıma işini yapan uygulamamızın geliştirilmesi konusunda harıl harıl çalışmalarımıza devam ediyoruz.

Sağolsun Yiğit Aktan, Yavuz Selim Akbulut, İlker Usta ve Turgay Sahtiyan gibi deneyimli Veritabanı Yöneticisi arkadaşlarımın, Semerkand Grup'ta IT Direktörü olan Murat Demirkıran'ın ve İş Analisti olan eşim Selin Bilge Kurt Önsoy'un da değerli yorumları ve destekleriyle iyi bir noktaya geldik.

Henüz bir "demo" versiyon yok, demo versiyonu sizlerle bu senenin sonuna doğru paylaşmayı umut ediyorum. O vakte kadar tamamlamamız gereken bazı dokümantasyon, işlevsellik testi ve güvenlik ile ilgili çalışmalar var.

Uygulamamız ile ilgili ayrıntıları www.transsql.com alan adını taşıyan blog'umuzda bulabilirsiniz. Bu blog'taki yazılar hem Türkçe hem İngilizce. TransSQL konusundaki tüm gelişmeler orada yayınlanıyor.

Sitemizi ziyaret eder ve uygulamanın gelişimi konusunda bize yorumlarınız, tavsiyeleriniz ve yapıcı eleştirilerinizle destek gösterirseniz çok memnun oluruz.

Selamlar,
Ekrem Önsoy

Bir replikasyon macerası

Bugün bir replikasyon kurulumuyla başım beladaydı… Sizlere de anlatayım dedim.

SQL Server 2005 olan ortamların birinde sorun var diye haber geldi, bağlandım baktım, ne göreyim dersiniz? Error Log'da aşağıdaki kaydı gördüm:

The operating system returned error 23(Data error (cyclic redundancy check).) to SQL Server during a read at offset 0x00000000012000 in file 'C:\xxx\distribution.MDF'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Tabii ki tüylerim diken diken oldu, çünkü bu, Corruption olduğu anlamına geliyordu.

Veritabanı SQL Server servis açılışında bu sorun nedeniyle yüklenemiyordu. Bu ortamdaki Distribution veritabanının bir yedeği de yoktu. Daha ne olsun? Kötü bir senaryo için her şeyimiz tam.

Neyse ki tatil dönemindeyiz ve neyse ki bu sunucuda sadece bir veritabanı replikasyona dahil.

Tüm replikasyonu kaldırıp, yapılandırmayı silip, her şeyi yeniden kurmaya karar verdim. Replike olan veritabanında aşağıdaki komutu çalıştırdım:

EXEC sp_removedbreplication

Daha sonra Distribution veritabanını kaldırmak için aşağıdakini:

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor = 1

Kar etti mi? Tabii ki hayır, çünkü Distribution veritabanım Corrupt durumda ve erişilemiyor. Bu noktada aklıma olan Distribution veritabanını kaldırmak ve yerine başka bir SQL Server 2005 Instance'ında yaratılmış Distribution veritabanını Restore etmek geldi, bunu yaptım.

Daha sonra Distribution veritabanını kaldırmak için aşağıdaki komutu çalıştırdım:

EXEC master.dbo.sp_serveroption @server=N'sunucu_adı', @optname=N'dist', @optvalue=N'true'

Bu komut hayatımı kurtardı. Sayesinde Distribution'dan kurtuldum ve replikasyonu tekrar baştan kurdum.

Burada benim hayatımı kurtaran şeyler, bağlanacak ve yalandan da olsa yeni bir Distribution veritabanı oluşturabilecek bir SQL Server 2005 ortamımın olması ve sp_removedbreplication ve sp_serveroption komutlarıydı.

Bir replikasyonu temizlemek zaman zaman gerçekten çok sıkıntılı olabiliyor, olur da birilerinin başına gelirse belki buradaki ipuçlarından faydalanabilirler…

Ekrem Önsoy

Bir hikaye: Ahh şu yazılımcılar yok mu… Başımızın tatlı belaları!

Merhabalar,

Sanırım 1 ayı geçmiştir, özel bir firmadan, SQL Server ile ilgili olduğunu düşündükleri bir sıkıntı nedeniyle yardım çağrısı geldi. Durumun acil olduğunu söylediler ve ben de nasıl olduysa üşenmedim ve akşam 19.00 civarı gittim yanlarına. Size bu hikayeyi anlatmak istiyorum. Tabii ki beni arayan arkadaşımın ve şirketin bilgileri bende saklı.

Firmaya gittiğimde 2 arkadaş karşıladılar ve sorundan bahsettiler. Kullanmaya yeni başladıkları bir uygulama ile ilgili yavaşlık sorunu yaşıyorlardı, ama ne olduğunu bilen yoktu. Kullanıcı algısına göre önceki uygulamaları jet hızıyla çalışıyordu; fakat ne olduysa yeni uygulamaya geçtikten sonra birçok şey çok yavaşlamıştı, acaba sorun SQL Server olabilir miydi?

Durumu incelemeye başladık, Trace açtık, Log'ları inceledik… Bazı sorgular nispeten ağır çalışıyorlardı, Index'lerinin olmadığını gördük ve bunları oluşturduk; fakat en can alıcı şey, veritabanlarının AUTO_CLOSE özelliğinin ON oluşuydu. Üretim ortamlarındaki veritabanlarında neredeyse ASLA olmaması gereken bir durum. Bu bir 3. parti paket uygulama, yani başka bir şirket geliştirmiş. Muhtemelen o şirketteki yazılımcı arkadaşlar SQL kod geliştirme ortamı olarak SQL Server Developer Edition yerine SQL Server Express Edition kullanıyorlar. Çünkü AUTO_CLOSE özelliği Express Edition'larda varsayılan olarak ON!

Gerekli Index'leri oluşturduktan sonra ve en önemlisi de veritabanlarının AUTO_CLOSE özelliklerini ON yaptıktan sonra Pazartesi gününü bekledik ve kullanıcılar tarafından uygulamanın kabul edilebilir bir hızla çalıştığı bilgisini aldım.

Başka bir gün, yine aynı arkadaşlarımdan yine bir yardım çağrısı geldi ve ilk fırsatta uğradım yanlarına. Bu sefer sorun, belli ekranlarda yaşanan kayda değer bir yavaşlıkla ilgiliydi. Sorunu beraber inceledik ve bu sefer sorunun SQL Server ile hiçbir ilgisi yoktu. Sorun tamamen uygulama arayüzü tasarımı ile ilgiliydi. Şöyle ki, ekranda son kullanıcıya gösterilemek istenen veri SQL Server'dan 200 milisaniyede alınırken, arayüzde gösterilebilmesi 15-18 saniye sürüyordu! İnanabiliyor musunuz? Peki bu nasıl başarılabilmiş dersiniz? Uygulama arayüzünde bol bol Checkbox kullanarak böyle bir şey yapılabiliyor! Bu cümlemden Checkbox'ların ne kadar çok olduğunu ne kadar tahmin edebilirsiniz bilemiyorum, ama rahatça 50'den fazlaydı diyebilirim. Sorun tabii ki sadece Checkbox'lar da değildi, aynı zamanda Tab Control bileşeni de kullanılmış ve veritabanından yapılan sorgulama bu bileşendeki 10'dan fazla sekmedeki Datagridview'lere ve Checkbox'lara dağıtılıyor. Veriyi sorgulamak 200 milisaniye, ekranda gösterimi ise ortalama 17 saniye!

Aman yazılımcı arkadaşlarım, siz siz olun lütfen ekran tasarımını yabana atmayın. Tasarladığınız ekranlarda son kullanıcının yapabileceği veri girişini, veritabanındaki tablolarınızın tasarımını düşünerek kısıtlayın, iki tarafın da birbiriyle tutarlı olmasını sağlayın. Lütfen ama lütfen NULL olmaması gereken tablo alanları için veri girişi yapılan kullanıcı arayüzlerini NULL girilemeyecek şekilde tasarlayın ki sonra ISNULL veya COALESCE'lerle dolu sorgular görmeyelim ki sorgu performansımız kötü olmasın. Lütfen ekran tasarlarken yukarıdaki tecrübeyi de göz önünde bulundurun ki veritabanından 200 milisaniyede gelen sorgu için kullanıcılar 17 saniye beklemesin. Ekran tasarımı hakkında söylenebilecek daha nice şey var, ama akla ilk gelen en önemlileri bunlar.

Kolay gelsin,
Ekrem Önsoy