1 Ağustos 2014 Cuma

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

8 Temmuz 2014 Salı

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

28 Haziran 2014 Cumartesi

TransSQL v1.0 BETA - Test çalışmaları 1. faz

Merhaba arkadaşlar,

Önceden "SQL Paket Taşıma Yöneticisi" adıyla sizlerle bazı haberlerini ve bazı özelliklerini paylaştığım çalışmamızın adını "TransSQL" olarak belirledik. Bu isimle SQL kodlarının Transfer edilmesi mesajını vermek istiyoruz. Transfer özü itibariyle Türkçe bir kelime olmasa da artık dilimize yerleşmiş, İngilizce de de kullanılan bir kelime.

www.transsql.com alan adını da almış durumdayız. Uygulama konusundaki çalışmalarımız yoğun bir şekilde devam ettiği için henüz site ile ilgilenemedik. Test çalışmaları belli bir noktaya geldikten sonra umuyorum ki internet sitemizi de devreye alacağız.

TransSQL, sıkı çalışmalarımız sonucu artık paket program haline geldi. Uygulamayı Türkçe ve İngilizceyi tam olarak destekleyecek hale getirmek istiyoruz, şu anda uygulama arayüzleri 2 dili destekliyor olsa da, dokümantasyon şimdilik sadece Türkçe. Zaman içinde bu noktadaki eksik de giderilecek ve uygulama artık yurtdışından arkadaşlar tarafından da kullanılabilecek.

Uygulama artık paket program durumuna geldiği için, başkalarının da test edebilmesi mümkün hale geldi. Eğer talip olanlarınız varsa lütfen benim gmail.com adresime bildirsin. Kendisine uygulamanın Setup'ının olduğu adresi vereceğim.

Test yapmak isteyenlerden ricam, lütfen:
- Karşılaşacağınız her olası sorunu not edin. Sorunla ne yaparken karşılaştınız; karşılaştığınız sorunun tam olarak tanımı, varsa hata mesajı nedir?
- "şu şöyle olsaydı çok daha iyi olurdu" diyebildiğiniz bir şey var mı?
- "şu da olsaydı çok daha iyi olurdu" diyebildiğiniz bir şey var mı?

Test ortamı gereksiniminiz:
- .Net 3.5 yüklü bir Windows OS (Client veya Server farketmez),
- SQL Server 2005 ve üstü versiyon, mümkünse Standard Edition ve üstü. Eğer bu, farklı bir makine olursa daha iyi; ama aynı makine de olsa sorun değil.

Desteğiniz için şimdiden çok teşekkürler!

Ekrem Önsoy

27 Haziran 2014 Cuma

Kerberos Configuration Manager for SQL Server

Merhaba!

Bugün günlük makaleleri okurken Kerberos Configuration Manager for SQL Server ile karşılaştım.

Daha sonra ilk defa 4-5 sene önce karşılaştığım aşağıdaki SQL Server Error Log mesajlarını hatırladım.

SQL Server is attempting to register a Service Principal Name (SPN) for the SQL Server service. Kerberos authentication will not be possible until a SPN is registered for the SQL Server service. This is an informational message. No user action is required.

The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/..com ] for the SQL Server service. Windows return code: 0x2098, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

Bu mesajları ilk gördüğümüzde hemen SPN'in ne olduğunu internetten araştırmış ve öğrenmiştik. Akabinde Domain Administrator'ımızdan da SPN kayıtlarımızı yapmasını istemiştik.

Microsoft sonunda bu konu ile ilgili bir Tool üretmiş. Belki sizin de böyle bir ihtiyacınız olabilir diye paylaşmak istedim.

http://www.microsoft.com/en-us/download/details.aspx?id=39046

Kolay gelsin,
Ekrem Önsoy

18 Haziran 2014 Çarşamba

SQL Paket Taşıma Yöneticisi: Etkilenecek kayıt sayısı?



Merhaba!

SQL Paket Taşıma Yöneticisi uygulamasına beğeneceğinizi düşündüğüm bir özellik eklendi. Zaman zaman DELETE ve UPDATE gibi komutların çalıştırılması gerekiyor. Eğer bu komutu yazan siz değilseniz ve sadece çalıştırmanız gerekiyorsa, o zaman bu komutlar ile kaç tane kaydın etkileneceğini bilmeniz gerekir, ki buna göre bu komutu o anda çalıştırmanın uzun süreli Blocking'lere neden olmayacağından emin olasınız. Çoğu zaman da bu komutu çalıştırmanızı isteyen arkadaşlar, kaç kaydın etkileneceğini size söylemezler. Bu UPDATE ve DELETE komutlarını elle SELECT'lere çevirmek zorunda kalırsınız, aynı WHERE kriterlerini kullanarak kaç tane kaydın etkileneceğini görürsünüz. Örneğin:

Komutu yazan kişinin gönderdiği komut:
UPDATE dbo.tablo SET xxx = 'y' WHERE yyy='x'

Sizin bu komutu aşağıdaki gibi SELECT'e çevirip çalıştırmanız gerekir ki kaç tane kaydın etkileneceğini bilesiniz:
SELECT COUNT(*) FROM dbo.tablo WHERE yyy='x'

Elle taşıma yapmak zaten başlı başına tehlikeli bir iş iken, bir de böyle elle komutlar yazıp çalıştırmak durumu daha da tehlikeli bir hale sokar. Bazen UPDATE'e WHERE kriterinin eklenmesi unutulur ve tüm tablodaki kayıtlar değişiklikten etkilenir. Bu gibi durumların yaşandığını az çok tecrübesi olan herkes zaman zaman görüyor…

İşte yeni eklenen özellik tam da bu soruna parmak basıyor. Aşağıdaki ekran görüntüsünden de görebileceğiniz gibi paket girişi yapan kişi 2 UPDATE ve bir de DELETE komutu girmiş:

Resim1

Önceden de değindiğim gibi normal şartlar altında bu komutları çalıştırmadan önce SELECT'lerini tekrar yazmalı ve kaç kaydın etkileneceğini öğrenmeniz gerekirdi. Fakat SQL Paket Taşıma Yöneticisi'nin "Kayıt sayısını al" özelliği ile artık bu iş de otomatikleşmiş oluyor. "Kayıt sayısını al" düğmesine tıkladığınızda, betiğinizdeki tüm DELETE ve UPDATE komutlarının SELECT'leri otomatik olarak sizin için hazırlanıyor ve isteğinize göre çalıştırılıp kaç kayıt getirdikleri görülebiliyor. 

Resim2

Resim2'de görebileceğiniz gibi "Kayıt sayısını al" düğmesine tıklayınca aşağıda farklı bir bölüm daha açılıyor ve burada, betikteki tüm DELETE ve UPDATE komutları için otomatik olarak SELECT komutları yazılıyor. Olabilecek kritik ortamlar gözönüne alınarak bu işin kontrollü bir şekilde yapılması nedeniyle her SELECT komutunun yanına "Çalıştır" düğmeleri kondu. Her bir SELECT komutunu hemen yanındaki SELECT düğmesiyle çalıştırabilirsiniz. Bu komuttaki WHERE kriteriyle kaç kaydın etkilendiğini hemen düğmenin sağoldaki "Kayıt sayısı" bölümünde görebilirsiniz.

Bunun yanında, her bir SELECT komutunun betik içerisindeki hangi komuta ait olduğunu görmek için SELECT komutunun üstüne tıklayabilirsiniz. Resim2'de de görebileceğiniz gibi 2. SELECT komutuna tıkladığımda betik içerisindeki sonuncu satır da otomatik olarak işaretlendi.

Ekrem Önsoy