1 Şubat 2016 Pazartesi

HATA: The computer 'xxx' is joined to a cluster

Selam millet!

Geçen gün bir ortamda bir Cluster'a yeni bir düğüm ekleme işimiz vardı. Bu işlem sırasında aşağıdaki ekran görüntüsünde de göreceğiniz hata ile karşılaştım.


Bu sunucu yeni kurulan bir sunucu değildi, bununla birlikte benim ortama girmemden önce kurulmuş bir sunucuydu. İlgili arkadaşlara sorduğumda bu sunucunun önceden herhangi bir Cluster'a katılmadığını söylediler. Ayrıca Windows Server Failover Cluster servisleri de kurulu değildi, ben kendim kurmuştum. Bu nedenlerle ben de bu hata ile karşılaştığıma şaşırdım.

Bu hatayı aşağıdaki ekran görüntüsünden göreceğiniz Powershell komutlarını kullanarak atlatabildim.

Tim Radney'in çözümünden alıntıdır.
Önemli not: Yukarıdaki komutu sorun yaşadığım düğümde çalıştırdım.

Sevgiler,
Ekrem Önsoy

28 Ocak 2016 Perşembe

Database Mirroring'ten Log Shipping'e geçiş senaryosu

Selamlar,

Çalıştığımız bir şirkette ilginç bir gereklilik hasıl oldu, sizlere de bahsedeyim.

Ortam büyük ve dinamik. En kritik veritabanları 6TB'a yakın bir boyutta. İş ve haliyle veritabanı beklenmedik şekilde büyümüş. Müşteri sayısı, gelen iş ve iş yoğunluğu çok kısa zamanda, çok fazla artmış. Böyle olunca bazı noktalarda hazırlıksız yakalanılmış. Yeni Storage alımında geç kalınmış.

Gelinen noktada elde bir üretim SQL Server sunucusu, bir de ikincil bir SQL Server sunucusu var; üretim sunucusundan ikincil sunucuya Database Mirroring yapılıyor. Yani birincil sunucuda (üretim sunucusu) gerçekleşen tüm işlemler gerçek zamanlıya yakın olarak ikincil sunucuya aktarılıyor. Fakat varolan kullanılabilecek Storage alanı o kadar az ki, örneğin birincil sunucuda bir tablo silinse ve geri getirilmek istense bu yapılamaz; çünkü elde yedek olduğu halde bunu Restore edebilecek müsait disk alanı yok.

Böyle bir senaryo için, en azından kişilerin, misal yazılımcıların (her yazımda size sataşmazsam olmuyor) yapabileceği olası bir hatalı silme veya güncelleme senaryosunda ilgili kayıtların eski versiyonlarına ulaşabilmeleri için bu arkadaşlara gecikmeli olarak işletilen bir Log Shipping uygulamasını tavsiye ettim. Database Mirroring'in ve Log Shipping'in nasıl çalıştığını ayrıntısıyla anlattım. Yeni Storage siparişi verildi; fakat en azından Storage gelip kullanılabilir oluncaya kadar ve hatta sonrasında da böyle sıkıntılar yaşanırsa hızlı aksiyon alınabilmesi ve zarar gören verinin ılık yedeklerden geri getirilebilmesi için Log Shipping işlerini görecektir.

Geçenlerde bu geçişi yaptık, hem de o en büyük veritabanını tekrar Restore etmeye gerek kalmadan. Çünkü anlayacağınız üzere zaten bu veritabanı Database Mirroring sayesinde ikincil sunucuda Restoring durumdaydı. Varolan Transaction Log yedekleme işlemlerini sonlandırıp yeni Log Shipping yapılandırmasını uyguladıktan sonra beklendiği gibi tıkır tıkır çalıştı. Tabii ki öncesinde gerekti tüm testleri yaptım. Her ne kadar yeni Storage'tan gelecek diskler devreye girene kadar Restore yapamayacak olsalar da, gecikmeli çalışan Log Shipping'ler sayesinde şimdi kendilerini daha güvende hissediyorlar.

Umarım tüm IT direktörleri ve / veya sistemci arkadaşlarım gerekli kapasite planlama işlerini aksatmadan yapar ve tabii ki yönetimden bütçe kopartabilir ve bu öyle sıkıntılar yaşamaz, gerçekten zor bir durum.

Sevgiler,
Ekrem Önsoy

22 Ocak 2016 Cuma

Gereği kadar yetki vermek...

Merhabalar,

Bugün, çalıştığım bir firmaya hizmet veren başka bir firmadaki bir arkadaştan şöyle bir e-posta aldım:

"Ekrem Bey Merhaba,
SQL bağlantısı için izin istiyoruz. Bir de dün açılan X_user yetkisi yeterli olmadı sanırım. X veritabanı için mi sysadmin hakkıyla bağlantı izni rica ediyoruz."

Kendi içimde verdiğim ilk ilkel tepkiyi pas geçiyorum, medeni tepkimin yansıması aşağıdaki gibi oldu:

"Merhabalar,



"sysadmin" yetkisi yapacağınız işin boyutunu çok aşan bir yetki ve bu yetkiyi size tabii ki veremeyiz. Dün arkadaşınıza verdiğim yetkiyi verdim yine X_user'a, işlemlerinizi kendi kullanıcınız olan bu kullanıcıyla yapabilirsiniz. Eğer bir yetki sorunuyla karşılaşırsanız bana danışın lütfen."

Ardından yine aynı firmada çalışan, ama başka bir arkadaştan şöyle bir e-posta geldi:

"Ekrem Bey,
Büyük bir ihtimalle dün X beye verdiğiniz yetki ile işlemleri yapamadığı için sorun oldu. Aşağıda sizin sunucuya bağlanıp tablonun dizaynını açtığımdaki görüntü ve hata mesajı var (Görüldüğü gibi kolonlar yok)."

Yukarıdaki e-postayı gönderen arkadaş aşağıdaki ekran görüntüsünü eklemiş:

Designer
Cevabım şöyle oldu:

"Designer için db_owner yetkisi gerekli, sizde bu yetki yok, ama yeni alan eklemeniz için gerekli yetkiler var. Bu işlemler Designer kullanarak yapılmamalı, çok tehlikeli. Misal Designer, yerli yersiz bazı işlemler için tüm tabloyu silip sıfırdan oluşturma yöntemini uyguluyor.

Bunun yerine yapacağınız işlemleri kod ile yapmalısınız.

ALTER TABLE ... ADD ... gibi"

5 dakika sonrasında aynı arkadaşlardan gelen e-posta şöyle:

"Tamamdır Ben düzeltmeleri yapabildim Ekrem Bey. işim bitti. Bilginize."

Diyeceğim o ki arkadaşlar, sevgili yazılımcı arkadaşlarımız veritabanı yöneticilerini hep az yetki vermekle suçlar, yokuş yapmakla suçlar (yıllar oldu, beni Denizbank'ta hala "Yokuş Ekrem" diye ananlar varmış, geliyor kulağıma ha!); ama çoğu zaman aslında verilen yetkiler yeterlidir. Sırf birileri yetki istiyor diye hemen vermeyin onlara istedikleri yetkiyi. Talebi sorgulayın, her şeyi sorgulayın (biraz felsefe).

Fazla yetki sahibi olmak, büyük sorumluluk, çoğu zaman yazılımcılar ilk etapta bunun yükünü anlayamıyorlar. Ancak ne zaman bir veritabanını, tabloyu vs siliyorlar veya yanlış işler yapıyorlar, o zaman anlıyorlar fazla yetkinin sıkıntısını. Günlük kullanımlık aracınızın 1000 beygirlik olması gibidir "sysadmin" yetkisiyle üretim ortamında çalışmak. Bunun tehlikelerini lütfen yeri geldiğinde yazılımcılarınıza anlatın.


Ekrem Önsoy

6 Ocak 2016 Çarşamba

Ansızın AlwaysOn AG'deki bir Replica gitti...

Selam!

Dün akşam, bir müşterimdeki bir AlwaysOn Availability Group yapılandırmasındaki Replica'lardan biriyle ilgili hata mesajları gelmeye başladı telefonuma. Hata mesajları, replikasyonun gecikmesi ve ilgili Replica'nın çalışmaması ile ilgiliydi. Müsait olunca sunucuya bağlanıp AlwaysOn AG Dashboard'unu ve ilgili logları incelemeye başladım ve hata mesajlarının geldiği Replica'nın NOT SYNCHRONIZING durumunda olduğunu gördüm. Kırmızı çarpılı uyarı simgeleri gözlerinizin önüne geliyordur sanırım…

AlwaysOn_health Extended Event dosyasında şöyle bir kayıt gördüm:
A connection timeout has occurred on a previously established connection to availability replica '' with id [XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX].  Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

Daha sonra sorunun yaşandığı SQL Server Instance'ına bağlanmaya çalıştım, RDP yapamıyordum (nedenini sonra anlatacağım); fakat SSMS ile bağlanabiliyor ve TELNET ile servise erişebiliyordum. Yani SQL Server Instance servisi ayaktaydı. SQL Server Instance'ına bağlandım, Error Log'u incelemeye başladım. Dha sonra sorunun oluştuğu ilk anda yine yukarıdaki hata mesajını gördüm ve hemen onun ardından aşağıdakine benzer hatalar vardı:

AlwaysOn Availability Groups connection with primary database terminated for secondary database 'VERITABANI_ADI' on the availability replica with Replica ID: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. This is an informational message only. No user action is required.

Fakat benim senaryomda can alıcı kısım (kafamda ampulün yandığı sahne), özellikle aşağıdaki hata mesajıydı:

Database Mirroring login attempt failed with error: 'Connection handshake failed. An OS call failed: (80090311) 0x80090311(No authority could be contacted for authentication.). State 67.'.  [CLIENT: XX.X.X.XX]

Bu hata mesajını görünce aklıma bu ortamda takriben 15 gün önce yaşanmış olan kaza geldi. 15 gün önce yaşanan kaza, bu sıkıntının yaşandığı SQL Server Instance'ının Computer nesnesinin Active Directory'den yanlışlıkla silinmesi kazasıydı. Bu kaza, o anda bir soruna neden olmamıştı; fakat bu kaza hakkındaki bilgi bana geldiğinde, ilgili arkadaşlara "Belki şu anda bir soruna neden olmuyor, ama muhakkak bir gün patlar. Şimdilik Cache'ten vs idare ediyor olmalı (teknik olarak bu noktada tükendiğimi anladınız sanırım)" demiştim.

Sorunu çözmek için ilgili SQL Server Instance'ının bulunduğu bilgisayara yerel Windows hesabıyla bağlanıldı, Domain'den çıkartıldı ve tekrar eklendi. Bu işlemin akabinde AlwaysOn ile ilgili sorunun da, RDP yapamama sorununun da düzeldiğini gözlemledik.

Evet, belki Computer nesnesinin Active Directory'de yeniden oluşturulması için daha pratik bir yol vardı; fakat bunun incelenmesi için vakte ihtiyaç vardı ve bu konuda çalışması gereken, kazayı yapan arkadaştı, çünkü o anda tam olarak ne yaptığını o biliyordu. En azından onun yakından yönlendirmesi şarttı. Mesai saatlerinin dışında bir vakitti ve mesai saatlerinin içinde dahi olsa bu araştırmaya vakit ayırılabileceğini sanmıyorum, o yüzden böyle daha "pratik" bir yöntem kullanıldı, sonuç olarak da işe yaradı.

Sevgiler,
Ekrem Önsoy

8 Aralık 2015 Salı

Bir Restore neden uzun sürer?

Merhabalar,

Bu aralar işler biraz yoğunlaştı, o nedenle bir şeyler paylaşmaya ara vermek durumunda kaldım. Yine de boşa çıkmış değilim; ama ne kadar ara verdiğimi görünce dayanamadım, daha dün yaşadığım bir olayı sizlerle de paylaşmak istedim.

Dün bir ortamda bazı veritabanlarını Restore etmem gerekti, kritik bir test durumu söz konusu olduğu için işlemi özellikle benim yapmam gerekti. Birkaç veritabanını Restore ettikten sonra, bazı veritabanlarının Restore işleminin ilginç bir şekilde duraksadığını, geciktiğini gözlemledim. Kuşkulandım ve ilk etapta sys.dm_exec_requests DMV'sini kullanarak işlemleri inceledim, birkaç Restore işleminin "percent_complete" alanındaki değer 100 idi, ama yine de işlemler bir türlü tamamlanmıyordu. Belki, herhangi bir garip nedenden dolayı SQL Server Management Studio'nun (SSMS) azizliklerinden biri olabilir diye düşündüm, SSMS'i kapattım açtım, sorun yine devam ediyordu. Sonra SQL Server Database Engine Service'ini kapatıp açtım, sonra sunucuyu komple kapattım açtım (test sunucusu) ve sorunun yine devam ettiğini gözlemledim.

En klasik sorun çözme yöntemlerinden olan kapat aç da işe yaramayınca artık daha derinlemesine bir araştırma şart olmuştu. Bunun için öncelikle 3004 ve 3605 Trace Flag'lerini aşağıdaki komut ile etkinleştirdim.

DBCC TRACEON (3004, 3605, -1)

Bu Trace Flag'ler ile Restore işleminin daha fazla kayıt üretmesini ve bu kayıtların da Error Log'a yazılmasını sağlamış oldum.

Ardından Error Log'ta aşağıdaki gibi kayıtlar gördüm:

SQL Server Error Log

Yukarıdaki ekran görüntüsünden de görüldüğü gibi bekleme anı Transaction Log dosyasının içerisinin sıfırlarla doldurulma anı. Bu anı Performance Monitor kullanarak ilgili sayaçlarla da izledim. Ayrıca Restore komutunu Script ile çalıştırdığım için aşağıdaki mesajı da görebildim ve not ettim:

Processed 857872 pages for database 'veritabanı_adı', file 'dosya_adı' on file 1.
Processed 2 pages for database 'veritabanı_adı', file 'dosya_adı_log' on file 1.

RESTORE DATABASE successfully processed 857874 pages in 528.709 seconds (12.676 MB/sec).

İşlem 529 saniyede ve saniyede sadece 12,6MB veri işleyerek tamamlanabilmişti. Bu gerçekten çok düşük bir değer, hele ki bu sunucudaki disklerden beklenen performans ile karşılaştırıldığında...

Aynı testi halihazırda üretim ortamında çalışan bir makinede denedim ve sonuç aşağıdaki gibi oldu:

Processed 857872 pages for database 'veritabanı_adı', file 'dosya_adı' on file 1.
Processed 2 pages for database 'veritabanı_adı', file 'dosya_adı_log' on file 1.

RESTORE DATABASE successfully processed 857874 pages in 48.744 seconds (137.496 MB/sec).

Gördüğünüz gibi işlenen sayfa sayısı aynı (857874), fakat üretim ortamındaki sunucuda aynı işlem 48,7 saniyede tamamlandı ve saniyede 137,5MB veri işleyerek. Bununla birlikte, bu işlemi üretim ortamındaki sunucuda da Performance Monitor ile izlemiştim ve veri yazma kapasitesi test sunucusundakine göre 6 kat daha hızlıydı.

Anlayacağınız, bu çalışmayla veritabanlarını Restore ederken aslında disk performans testi de yapmış olduk. Restore işlemlerinizi yaparken bir gariplik görürseniz görmezden gelmeyin, geçişten sonra başınız çok ağrıyabilir…

Kolay gelsin,
Ekrem Önsoy