10 Mart 2017 Cuma

Veritabanı sunucunuzun "rutin" durumu gerçekten normal mi?

Son zamanlarda bir firma ile kısa bir çalışma yaptık. Microsoft SQL Server veritabanı sunucusu sağlık kontrolü çalışması yaparken, sunucunun işlemci kaynaklarının neredeyse sürekli %100 kullanıldığını gözlemledim. Açıkçası ben her ne kadar o anda veritabanı sunucusu sağlık kontrolü çalışmasını erteleyip sorunlara göz atmak için sabırsızlansam da, müşteri bu durum ile yaşamaya alışıktı. Bu nedenle o gün sağlık kontrolü çalışmamıza devam ettik.


Kontrollerde sunucunun CPU durumu (temsilidir).

Aslında benimle çalışmak istemelerinin nedenlerinden biri de işlemcinin bu durumuydu, ama bu sorun hakkında çok da kaygılı değillerdi. Sonuç itibariyle günlük operasyonlarını durduran, kesintiye neden olan bir durum yoktu ortada. Sadece zaman zaman ağırlık hissediliyordu ve Deadlock'lar oluşuyordu. Muhtemelen kullanıcılar da zaten sistemin böyle bir performansla çalışmasına alışmışlardı, o yüzden kimse yadırgamıyordu, sonuç itibariyle sistemin "rutin" hali bu idi.

Şahsen sağlık kontrolü çalışmasınının tamamlanmasını ve ertesi gün yapacağımız performans iyileştirme çalışmasını iple çekiyordum. Ertesi gün performans iyileştirme çalışması için yalnızca birkaç saat ayırabildik. Bu kadarlık bir sürede bile, yaptığımız müdahalelerle işlemci kullanımının (sıçramaları hariç tutarsak) %1'lere indiğini gözlemledim. Zaman zaman işlemci kullanımını %100'e çıkartan bir (ve muhtemel başka zaman aralıklarında çalışan birkaç tane daha) sorgu hala vardı ve en sorunlu görünen sorguyu da tespit edip ilgili yöneticiye bildirmiştim; fakat sorgular uygulamada gömülü olduğundan hemen o gün müdahale edip sorun düzeltilemedi. Birkaç saatte bu kadar iyileştirme sağlanabildiyse çalışmak için 1 ekstra günümüz daha olsa, stabil olarak işlemci kaynaklarını %5'in altına indirebileceğimize eminimdim. Tabii tüm ortamlar için mümkün olan bir sonuç değil bu, bazı çalışmalar daha uzun sürüyor; ama bu müşterim için durum böyleydi.


Önceden de benzer senaryolara ve konulara değinmiştim. Sorunları CPU ve RAM ekleyerek ancak bir yere kadar öteleyebilirsiniz. Tabii CPU ve RAM eklemek de yetmiyor, bu donanımlar için Microsoft SQL Server lisansı da satın almanız gerekiyor. Örneğin Microsoft SQL Server 2016 Enterprise Edition veritabanı sunucunuzu Per Core modeliyle lisanslamak istediğinizde tek bir CPU Core'u için lisans bedeli 14,256$ ve sunucunuzdaki tüm fiziksel Core'lar için lisans satın almanız gerekiyor.


Güncelleme (2017-03-13): Per Core lisanslama modelinde çekirdek başına lisanslama yapılıyor ve 2 çekirdek paketiyle satılıyor. Yani 14,256$, 2 Core'luk paket fiyatı. Eğer sunucunuz 8 çekirdekliyse, o zaman 4 tane 2 Core'luk paket almanız gerekiyor. Tabii her lisanslama senaryosu bu kadar basit hesaplanmıyor. Senaryoya göre lisans hesabı çok daha ayrıntılı olabiliyor. Her halükarda bu konuyu yetkili bir satış kanalıyla görüşmenizde fayda var.

Bu konuda size bazı önerilerim var:


  • Yazılımcıların veritabanı kodlaması konusunda en iyi pratikleri bildiğinden ve uyguladığından emin olun, 
  • Veritabanı sunucunuza kod taşımalarını yapmadan önce taşınacak değişiklikleri iyi ve sistemli bir şekilde test edin, 
  • Testleri küçük boyutlarda, gerçekçi olmayan verilerle yapmayın, 
  • Test ortamınızın hem donanım olarak, hem yapılandırma olarak, hem de veri olarak üretim ortamınıza olabildiğince benzer ve güncel olmasını sağlayın, 
  • Kod taşımalarından önce ve sonra, üretim ortamınızdaki performans değişikliklerini takip edin, kodu taşıyıp hiçbir şey olmamış gibi üretim ortamını kendi haline bırakmayın,
  • Performans sorunlarınızı donanım kaynaklarını arttırarak değil, öncelikle veritabanı yapılandırmanızı ve kodlarınızı iyileştirerek gidermeyi deneyin,
  • Bu değişikliklerin yaratacağı olası performans sorunları takip edilmediğinde ve gerekli müdahaleler zamanında yapılmadığında bir noktada artık sistemin sağlıklı çalışamaz hale geleceğini unutmayın.

Microsoft SQL Server ile ilgili profesyonel bir desteğe ihtiyacınız varsa beklerim efendim.

Ekrem Önsoy

27 Şubat 2017 Pazartesi

MVP Reconnect Programı Anısı

1 ay önce LinkedIn'de Microsoft'un MVP Reconnect programını aşağıdaki gibi duyurmuştum.



Bu program çerçevesinde Microsoft bu ay bu programa dünya çapında kayıt olan ilk 200 kişiye bir hatıra gönderdi. Efendim benim hatıram da bugün geldi, resmini çekip sizlerle de paylaşmak istedim.



Sevgiler,
Ekrem Önsoy

15 Şubat 2017 Çarşamba

SQL Server 2016'da Database Mail ve .Net 3.5

Firma ziyaretlerimde sık karşılaştığım sorulardan biri şu:

"Ekrem, sen birçok firmaya girip çıkıyorsun, birçok ortam görüyorsun, şu anda sektörde en çok kullanılan SQL Server versiyonu nedir?"

Bu sorunun cevabı an itibariyle şu: "SQL Server 2012".

Sektör Microsoft'un hızına yetişemiyor. Bu sadece Türkiye'de değil, tüm dünyada böyle.

Efendim bu yazımın konusuna dönelim. Böyle bir giriş yapmamın nedeni, SQL Server 2016 ile fazla karşılaşmadığımızdan, SQL Server 2016'da Database Mail ile ilginç bir sorun yaşama olasılığınıza dikkat çekmekti. 

Belki bazılarınızın bildiği gibi SQL Server 2016 kurarken .Net 3.5 kurulumu zorunlu değil. SQL Server 2016 medyanızla doğrudan SQL Server 2016 Instance'ınızı kurabiliyorsunuz. Böyle kurulmuş bir ortamda Database Mail'i yapılandırdım ve test amaçlı bir eposta gönderdim ve beklemeye başladım. İlk dikkatimi çeken şey, Database Mail işleminin bir türlü başlamayışıydı. Task Manager'a baktım, DatabaseMail.exe yok. "sysmail_start_sp" isimli, Database Mail'i başlatmak için kullanılan sistem Stored Procedure'ünü çalıştırdım, ama gene tık yok.

DatabaseMail.exe'nin bulunduğu yola "C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn" gittim ve elle çalıştırmayı denedim ve bir sürpriz ile karşılaştım:

Genişletmek için resmin üstüne tıklayın
Bu ekranı görünce, önceden bu konuda bir yazı okuduğum geldi aklıma. SQL Server 2016 kurulumu için .Net 3.5 gerekmese de, SQL Server 2016'da Database Mail kullanmak için .Net 3.5 kurulumu gerekiyordu.

Genişletmek için resmin üstüne tıklayın
Ben de kurulumu gerçekleştirdim ve Database Mail'i tetiklemek için aşağıdaki Stored Procedure'ü çalıştırdım:

EXEC sysmail_start_sp;

Akabinde Task Manager'ı kontrol ettim ve aşağıdaki gibi DatabaseMail.exe'nin çalıştığını gördüm.


Genişletmek için resmin üstüne tıklayın

SQL Server 2016 kurulumlarınızda Database Mail'in bu durumuna dikkat etmeyi unutmayın. İşin kötüsü, herhangi bir yerde bu konuda bir hata veya kayıt da yok. Eğer ben de sorunu çözmek için izlediğim bu yöntemi izlemesem veya çook önceden okuduğum o yazı aklıma gelmese, bu sorun kim bilir ne saç baş yoldururdu.

Güncelleme: Bu sorun SQL Server 2016 Cumulative Update 2 ile çözülmüş ve Service Pack 1'e de yansıtılmış. Henüz kendim test etmedim, ama bu Connect'e göre Microsoft böyle diyor.

Ekrem Önsoy


7 Şubat 2017 Salı

Microsoft Azure: Query Editor

30 Ocak 2017 tarihinde Microsoft, Query Editor'ün ilk sürümü hakkında bir duyuru yayınladı.

Bugün bu yeni özelliği biraz inceleme fırsatım oldu, sizlerle de paylaşmak istedim.

Peki neden SQL Server Management Studio (SSMS) gibi, diğer benzeri araçlara nazaran çağlar ötesinde olan bir uygulama varken Query Editör gibi bir araca ihtiyaç duyulabilir? Eğer Azure Portal'da çalışıyorken portalı hiç terk etmeden, SSMS gibi harici bir uygulamaya geçiş yapmak zorunda kalmadan, güvenlik duvarı ayarlarıyla uğraşmadan Azure SQL Database veya Azure SQL Data Warehouse veritabanlarınızda komut çalıştırmak istiyorsanız Query Editor pratik bir seçenek olabilir.


SQL Database veya SQL Data Warehouse içerisinden Query Editor'e ulaşabilirsiniz. SQL Data Warehouse'taki ekran biraz daha farklı, ama Overview'üne giriş yapınca hemen fark edeceksinizdir.

Eğer Query Editor'ü ilk defa kullanacaksanız, özellik henüz deneme aşamasında olduğu için sizden onay istenecek. Sonrasında ise komutları çalıştırmak için aşağıdaki görselde gösterildiği gibi sisteme giriş yapmanız gerekecek.


Sisteme giriş ekranı
Sisteme başarılı bir şekilde giriş yaptıktan sonra SSMS'teki gibi yeni tablo oluşturabilir, SP yazabilirsiniz. Tabii SSMS gibi bir ortam beklemeyin, yani Object Explorer veya diyaloglar yok, adından da anlaşılabileceği gibi sadece kod yazılıyor Query Editor'de. Komutların sadece seçtiğiniz bölümlerini çalıştırabiliyorsunuz, yani kısmi kod çalıştırma özelliği mevcut. Ayrıca "Open query" düğmesine tıklayarak makinenizde varolan Script'lerinizi açıp çalıştırabilirsiniz ve "Save query" düğmesiyle de yeni Script'lerinizi yine kendi makinenizde saklayabilirsiniz.


Bir komutu çalıştırdığınızda "Authenticated as eonsoy" yazan bölümde saniye işlemeye başlıyor.

Sorguları çalıştırmak için alışkanlıkla F5'e basmayın sakın, tahmin edeceğiniz gibi tüm sayfa yenileniyor, yazdığınız onca Script'i kaybedebilirsiniz! Maalesef bu versiyonda henüz bu konuda bir önlem yok. Yani F5'e bastığınızda "Henüz kaydedilmemiş veriniz silinecektir" gibi bir uyarı gelmiyor. Microsoft'un ilgili bölümüne bu konuda geribildirimde bulundum, bunu dikkate almamaları imkansız. Bu konuda bir gelişme olursa, yine burada ayrıca paylaşırım.

Güncelleme: Az önce Microsoft'taki ilgili takımdan cevap geldi, bu sorunun farkındalarmış ve zaten üstünde çalışmaktalarmış.

Ekrem Önsoy



31 Ocak 2017 Salı

Ocak ayında oluşturduğum Microsoft SQL Server hata kayıtları

Sizlerle Ocak ayında oluşturduğum SQL Server'a ait hata (bug) kayıtlarını paylaşmak istiyorum. Ocak ayı hata kayıtları açısından biraz yoğun geçti.

Hata 1:
Aşağıdaki hata kaydı, SQL Server Management Studio'nun yeni versiyonlarında Task List'in hatalı oluşuyla ilgili. Hatalı derken kastettiğim şu, mesela yeni görev oluşturma düğmesi ve görevin türünün belirlendiği aşağı açılır kutu Task List penceresinde görünmüyor.

https://connect.microsoft.com/SQLServer/feedback/details/3118202/task-list-seems-incomplete


Hata 2:
Aşağıdaki diğer hata kaydı da veritabanınızı yerel sunucunuzda oluşturup, dosyalarını Microsoft Azure Blob Storage'da sakladığınızda oluşuyor. Hata, veritabanınız için oluşturduğunuz Database Snapshot'tan dönüş yapmaya çalıştığınızda oluşuyor. Aynı senaryo, veritabanı dosyaları yerel sunucuda konumlandığında oluşmuyor. İpucu: Database Snapshot'tan nasıl geri dönüş yapılacağı da ayrı bir blog konusu.

https://connect.microsoft.com/SQLServer/feedback/details/3117785/reverting-from-a-database-snapshot-when-database-files-on-azure-blob-storage


Hata 3:
Bu hata da Transparent Data Encryption özelliği etkinleştirildiğinde ve kapatıldığında SQL Server 2014 SP2 ve SQL Server 2016 SP1'deki sys.databases ve sys.dm_database_encryption_keys catalog view'lerinin farklı sonuçlar döndürmesiyle ilgili.

https://connect.microsoft.com/SQLServer/feedback/details/3118734/tempdb-looks-encrypted-but-it-shouldnt-have-been

Güncelleme 01.02.2017: Ben 13 Ocak tarihinde bu konuda yukarıdaki hata kaydını açtıktan sonra Microsoft'tan Bob Ward yine bu konuda 27 Ocak tarihinde bu konuyu incelemiş. Merak edenler yazıya buradan ulaşabilir.

Eğer açtığım hata kayıtlarına oy vermek isterseniz, bir Microsoft hesabı açmanız yeterli.


Ekrem Önsoy