5 Aralık 2017 Salı

Kim korkar kritik bir ayarı değiştirmekten? (İpucu: temkinli olmakta fayda var)

Birkaç ay önce sahadaki sağlık kontrolü çalışmalarım sırasında karşılaştığım sorunlardan birini bu yazı ile anlatmıştım. Bu duruma benzer bir sorunun geçenlerde başka bir ortamda yaşandığına şahit oldum.

Sorun oluştuğunda SQL Server Management Studio ve uygulamalar ile SQL Server Instance'ına bağlanmaya çalıştığımızda şöyle hatalar oluşuyordu:

"A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - The specified network name is no longer available.) (Microsoft SQL Server, Error: 64)"

Açıkçası özellikle aşina olmayanlar için oldukça kafa karıştırıcı bir mesaj. Hata mesajını özetle ve mealen şöyle Türkçeye çevirebiliriz "Sunucuya bağlantı sağlandı, ama sonra bir hata oluştu (Belirtilen ağ adı artık ulaşılabilir değil)". Yani sunucuya ulaşabiliyoruz, ama sonra bir hata oluşuyor ve birden sunucu ulaşılamaz oluyor. 

Not: SQL Server'da buna çok benzer, fakat farklı ibareler içeren çeşitli hata mesajlarıyla karşılaşılabilir. Birebir aynı olmadığı sürece sorunları birbirine karıştırmamakta fayda var. SQL Server bağlantı sorunlarıyla ilgili daha fazla bilgi için referans yazımı bu adresten inceleyebilirsiniz. Ayrıca Aaron Bertrand'tan 18456 hatalarıyla ilgili güzel bir referans yazısını da bu adreste bulabilirsiniz.

Sorun anında yeni oturum açmak pek mümkün olmadığı için varolan açık oturumları kullandık ve hata kayıtlarını kontrol ettiğimizde şu hataları gördük:

"Could not connect because the maximum number of user connections has already been reached."

SQL Server'da normal şartlar altında, yani varsayılan olarak "User Connection" ayarı sınırsızdır, daha doğrusu 0'dır ve bu da 32.767'ye karşılık gelir. 

Not: Tabii ki 32.767 nihayetinde bir sınırdır, ama pratikte bu sınıra ulaşmanız pek kolay değil.

Not: Benzer sıkıntılı durumlarda Dedicated Administrator Connection (DAC) hayat kurtarır. Her SQL Server veritabanı yöneticisi muhakkak bu kavramı ve ne zaman, nasıl kullanılabileceğini bilmelidir.

Sanırım şimdiye kadar birçoğunuz durumu anlamıştır. "User Connection" ayarı çok daha küçük bir sayı ile değiştirilmiş. Her ortamda "lütfen bilmediğiniz, emin olmadığınız, yeterince test etmediğiniz ayarı değiştirmeyin" diye bas bas bağırıyoruz; ama "tarih tekerrürden ibarettir" sözü, anlamı gibi kendini de tekrar ettirip duruyor.

Sonradan öğrendiğime göre bu değişikliğe neden olan motivasyon, sunucunun zaten X sayısından fazla kullanıcı bağlantısını kaldıramayacağı düşüncesiymiş. Fakat bu senaryoda yanılınan temel nokta şu oldu bence, bağlantılar aktif olsun, pasif olsun, bu ayar her türlü bağlantıyı kapsar. Örneğin sorun esnasında kontrol ettiğimde varolan bağlantıların %80'i pasifti (sleeping) ve ancak %20'si aktif, çalışan bağlantıydı. Bu normal mi, anormal mi ayrı bir tartışma konusu; ama bu kullanıcı bağlantı sayısı kesinlikle sunucunun kaldırabileceğinin çok altındaydı. Yani eğer bu ayar bu şekilde suni olarak değiştirilmeseydi, bu durumdan kaynaklanan bir kesinti olmayacaktı. Sonuç itibariyle elbette her sunucu kaynağının ve sistemin kaldırabileceği bir yük var, ama buna suni olarak ve yeterince ince eleyip sık dokumadan müdahale etmeye ne gerek var?

Not: Özellikle kompleks sistemlerde türlü anormallikler, beklenmedik durumlar muhakkak, olacaktır (dikkat "olabilir" demiyorum); sunucularımızın ayarları ve donanım kaynakları özellikle kritik ortamlarda bu tür anormallikleri ve anormal yükleri kaldırabilecek şekilde düşünülmeli ve tasarlanmalıdır. 

Sistemin sağlığını etkileyebilecek benzer değişiklikler yapılmadan önce bu değişikliklerin olası sonuçları, özellikle çok kritik canlı sistemlerde muhakkak etraflıca düşünülmelidir. Ayarlar, kavramlar ve özellikler hakkında resmi dokümantasyon ve ilgili değişikliği uygulamış insanların gerçek hayat tecrübeleri muhakkak dikkate alınmalı, incelenmeli, okunmalı ve dinlenmelidir. Ayrıca böyle değişiklikleri canlı ortamınızda uygulamadan önce kendi ortamınız için testler ve gözlemler yapmanızda büyük fayda var. Değişiklik öncesinde (yeterli bir süre boyunca) ne durumda olduğunuzu, değişiklik sonrasında hangi duruma geldiğinizi, metriklerin nasıl ve ne yönde değiştiğini mutlaka bilmelisiniz. Bunları bilmezseniz, yönetemezsiniz. Yönetemediğinizde de durum kontrolden çıkar.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

Hiç yorum yok: