18 Mayıs 2017 Perşembe

Bir sorun "çözme" yöntemi: SQL Server servisinin düzenli olarak kapatılıp açılması fenomeni

Microsoft SQL Server ortamları için "sağlık-kontrolü / healthcheck" ve performans iyileştirme çalışmaları için yeni müşterilere gittiğimde zaman zaman "Procedure ve Data Cache"in düzenli olarak boşaltıldığını veya Microsoft SQL Server sunucusunun düzenli olarak (mesela haftada bir veya ayda bir) yeniden başlatıldığını görüyorum. Müşteriye nedenini sorduğumda ise şöyle yanıtlar geliyor:

  1. Zamanla SQL Server çok RAM kullanıyor, bunu düzeltmek için,
  2. CPU kullanımı zaman zaman tavan yapıyor, sunucuyu yeniden başlatınca düzeliyor,
  3. Tam emin değiliz; ama zamanla SQL Server'da çalışan sorgular yavaşlıyor, yeniden başlatmak sorunları çözüyor.
  4. Sizden önceki gelen danışman veya X arkadaş böyle tavsiye etti,


    Bahsettiğim senaryoda aldığım yanıtlar aşağı yukarı hep böyle. Bu yanıtları özellikle numaralandırdım, çünkü aşağıda tek tek özetle açıklayacağım.

    1- SQL Server kurulumlarında varsayılan olarak SQL Server sunucuda varolan tüm hafıza kaynağını kullanmak üzere ayarlıdır ve doğası gereği sadece SQL Server değil, tüm veritabanı sistemleri olabildiğince RAM kullanmak ister. Ne kadar çok işlem diskten değil de doğrudan hafızadan yapılabilirse, işlemler o kadar hızlı gerçekleşir. 

    İşletim sistemi, SQL Server'ın kendi diğer bileşenleri veya sunucu üstündeki diğer uygulamaların da hafıza ihtiyacı vardır ve SQL Server yapılandırması da bu çerçevede ayarlanmalıdır. Aksi takdirde "Paging / Swap" oluşur, bu da uygulamaların ağır çalışmasına, yani performans sıkıntılarına neden olur. Çünkü yetersiz hafıza kaynağı nedeniyle uygulamalar çatışır ve Windows işletim sisteminin Page File'ı kullanılmaya başlanır. Yani hafıza (RAM) yerine bazı uygulamalar için fiziksel disk hafıza niyetiyle kullanılmaya başlanır, ki bu yöntem hafızaya göre defalarca kat yavaştır. Donmalara, uzun süreli beklemelere neden olur.

    2- Bunun nedeni genellikle "Parameter sniffing"tir. Parameter sniffing normal şartlar altında kendi başına bir sorun değildir, ama planlar anormal değerlere göre derlendiğinde parameter sniffing can yakabilir. Her sorgu çalışmadan önce o sorgu için bir çalıştırma planı (Execution Plan) oluşturulur ve bu çalıştırma planı da sorgu çalıştırılırken kullanılan ilk parametre değerine göre oluşturulur. Çalıştırma planı Plan Cache'te konumlandıktan sonra (parameterize sorgular, stored procedure'ler ve diğer basit sorgular gibi) ilgili sorgular artık bu planı kullanarak çalışır. Eğer plan en uygun şekilde ve en genel talebe hitap edecek değerlerle oluşmadıysa, kötü bir performans ile çalışabilir ve bu da CPU'nun ve diğer donanım kaynaklarının verimsiz olarak kullanılmasına neden olabilir.

    Plan Cache'i boşalttığınızda veya SQL Server servisini yeniden başlattığınızda (veya bazı SQL Server Instance'ı düzeyinde ayarı değiştirdikten sonra veya tekil bir planı Plan Cache'ten sildikten sonra) sorunlu çalıştırma planı gitmiş olur ve ilgili sorgu veya stored procedure ilk çalıştırışınızda yeni bir plan oluşturulur. Şansınıza yeni plan daha uygun değerler kullanılarak oluşturulabileceği için o anda "sorun çözüldü" sanabilirsiniz. Fakat Plan Cache'in bir dahaki sıfırlanışında veya herhangi başka bir nedenle ve zamanda bu plan yeniden kötü bir şekilde derlendiğinde yine bu sorunu yaşarsınız.

    Yani sunucuyu veya SQL Server servisini kapatıp açmak kalıcı bir çözüm değildir, bu nedenle sürekli kapatıp açmaya devam edersiniz.

    3- Bunun nedeni genellikle ya 2. maddede açıkladığım neden veya sorguların bloklanması (blocking) kaynaklı oluyor. Haliyle sunucu veya servis yeniden başlatılırken tüm bloke eden sorgular da sonlandırılmış oluyor ve servis yeniden başlayınca bloke olma sorunu "çözülmüş" oluyor.

    4- Eğer bir danışman veya X arkadaş ilk 3 maddede yaşanılan sorunlar için size en iyi pratik olarak "SQL Server servisini veya sunucusunu düzenli olarak yeniden başlatmayı" veya "Cache'leri boşaltmayı" önerirse arkanıza bakmadan kaçın. Tabii ofis ve ortam sizin olacağı için kaçamayacağınıza göre "arkadaşa" veya her ne sıfatla size bunu öneriyorsa ona bir çay ısmarlayıp nazikçe konuyu düşüneceğinizi iletebilir ve numarasını telefonunuzdan silebilirsiniz.

    Peki "Cache"lerin boşaltılması neden kötü?
    • Ad-hoc ve dinamik olmayan, parameterize olan tüm sorguların ilk çalışışlarında bir çalıştırma planı oluşturulur ve (sunucu ayarlarınıza göre) bu plan ilk veya ikinci seferinde Plan Cache'te konumlandırılır. Daha sonra ilgili sorgu / stored procedure her çalıştığında bu planı kullanır. Çalıştırma planının oluşturulma işlemi CPU yüklü bir işlemdir. Eğer sık sık Plan Cache'i boşaltırsanız veya ilgili sorgu her çalıştığında planın yeniden derlenmesini sağlarsanız sık sık tüm ilgili işlemler için yeniden çalıştırma planı oluşturulması gerekir ve bu da işlemlerinizin anlık olarak yavaşlamasına, genel olarak sunucu işlemci masraflarınızın artmasına neden olur.
    • SQL Server'da geleneksel (In-memory / Hekaton olmayan) bir tablodaki kayıtlar için işlem yapacağınız zaman bu işlem hafızada (RAM) yapılır ve daha sonra Lazy Writer veya Checkpoint ile diske aktarılır. Update, Delete ve Insert hangi DML komutu çalıştırırsanız çalıştırın, ilgili kayıtlar önce hafızada değiştirilir doğrudan diskteki kayıt değiştirilmez. Eğer değişiklik yapılmak istenen kayıtlar Data Cache'te / Buffer Pool'da yoksa, önce diskten okunur ve Buffer Pool'a getirilir ve kayıtlardaki değişiklik hafızada yapılır (bu durumda ilgili kayıtlar "Dirty Page" olur). Select için de aynı şey söz konusu, sorguladığınız kayıtları içeren Page'ler hafızada yoksa önce diskten Buffer Pool'a taşınır ve sorgunuz ondan sonra cevap verir. Bu nedenle işlem yapılacak kayıtların ne kadar çoğu hafızadaysa, işlemler o kadar hızlı gerçekleşir. Eğer siz düzenli olarak Buffer Pool / Data Cache'i boşaltırsanız, bu sefer her seferinde, her kayıt için önce diske gidip o kayıtları hafızaya yüklemek gerekiyor. Böyle bir ortamda da bol bol PAGEIOLATCH bekleme tipleri görürsünüz, çünkü diskleriniz harıl harıl çalışır durur, kullanıcılar yavaşlık hisseder. Bazı senaryolarda Deadlock ve Blocking'in nedeni de budur.
    Veritabanı sunucunuzu sürekli yeniden başlatarak ve Cache'leri düzenli olarak boşaltarak sorunları sadece ötelemiş olursunuz. Bu sorunları çözmek için SQL Server Instance'larınızın doğru yapılandırılması, sorunlu sorguların iyileştirilmesi, çalıştırma planlarının çeşitli tekniklerle istikrarlı hale getirilmesi ve gerekiyorsa dondurulması gerekiyor. Yukarıda maddeler halinde sıraladığım sorunların tek çözümü budur.

    Ekrem Önsoy
    Microsoft SQL Server Danışmanı

    4 Mayıs 2017 Perşembe

    Bir Cumulative Update kazası

    Bu sıralar bir müşterimin canlı veritabanı sunucusu için SQL Server 2012'den SQL Server 2016'ya sürüm yükseltme çalışmaları yapıyorum. Bu çalışmalar sırasında geçen sene de karşılaştığım, ama hakkında yazı yazamadığım bir sorun ile tekrar karşılaştım. Bu sefer bu sorunu günlüğüme kaydediyorum.

    Bu çalışma kapsamında yeni bir Windows Server 2016 kurulumu ve üstüne de SQL Server 2016 kurulumu yaptık. Müşterim SQL Server Standard Edition kullandığı için, SQL Server 2016 Service Pack 1 ile gelen birçok Enterprise Edition özelliğinden faydalanabileceği gibi SQL Server 2016 ile gelen yeniliklerden de faydalanabilecek. Bu ortamdaki en büyük maliyet disklerden kaynaklanıyor. Bu sürüm yükseltme çalışmasıyla Data Compression ve Columnstore indeksler ile müşterimin disk maliyetlerini ciddi oranda düşürmeyi ve aynı zamanda performansın iyileşmesini hedefliyorum. Ayrıca dahili ve harici denetim firmaları hassas verilerin maskelenmesini ve nesne düzeyinde kayıt tutulmasını talep ediyor; Dynamic Data Masking ile verilerin maskelenmesini ve Database Level Auditing ile de nesne düzeyinde kayıt tutulmasını sağlayacağız. Tüm bu ihtiyaçlar ekstra bir ürün alıp hem karmaşaya hem de ekstra maliyete neden olmadan sağlanmış olacak.

    Windows Server 2016'yı, SQL Server 2016'yı ve Service Pack 1'i kurduktan sonra en son Cumulative Update'i de kurarken, kurulumun sonunda gereğinden uzun süre bekleyince bir sorunun olduğunu anlamıştım. Tabii ki bekledim ve ardından beni bekleyen hata mesajıyla karşılaştım:


    Cumulative Update (KB4013106) kurulumunda oluşan hata mesajı
    Başlatılamayan tek servis "SQLSERVERAGENT" değildi, "MSSQLSERVER" yani Database Engine servisi de "Change Pending" durumunda kalmıştı. Windows Event Log'larını ve SQL Server Error Log'larını inceledim, şu mesajlar vardı:

    "Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 226, state 6, severity 16. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion."

    "Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online."

    Nasıl, mesajlar yeterince korkutucu mu? Bu sefer bu sorun ile yeni, geçiş sunucusunda karşılaştım; ama geçen sene bu sorunla karşılaştığımda ortam canlı ortamdı. Benzer hataları bir de canlı bir ortamda aldığınızı düşünün...

    SQL Error Log'da aşağıdaki mesaj öbeğine odaklandım:


    SQL Server Error Log'tan bir görüntü

    Mesajlardan da görebileceğiniz üzere haliyle önce replikasyondan şüphelendim, bu sunucuda 70 küsur veritabanı var ve canlıda 2 tanesi Transactional Replication ile raporlama sunucusuna replike ediliyor. Önce bu 2 veritabanındaki replikasyon artıklarını kaldırmayı düşündüm ve bunu yapmam için de [sp_removedbreplication] sistem SP'sini çalıştırmam gerekiyor, ama Database Engine servisi hiç açılmıyor, bunu nasıl yapacağım?

    Neyse ki böyle durumlarda kullanabileceğimiz bir Trace Flag var, T902. Database Engine servisini Trace Flag 902 ile başlatırsanız, Service Pack veya Cumulative Update Script'leri servis açılışında çalıştırılmaz ve böylece Database Engine servisiniz açılabilir. Ben de böyle yaptım ve Database Engine servisini T902 ile çalıştırdım ve ardından ilgili 2 veritabanı için [sp_removedbreplication] komutunu çalıştırıp veritabanlarındaki replikasyon artıklarını temizledim ve Database Engine servisini T902'siz çalıştırdım. Maalesef sorun çözülmemişti.

    Not: Unutmayın, Trace Flag'leri bilinçli bir şekilde kullanmalısınız. Örneğin Trace Flag 902 sadece böyle bir durumda ve geçici olarak kullanılmalıdır. Canlı ortamınızı sürekli Trace Flag 902 çalıştırmamalısınız.

    Bu sefer hata mesajının oluştuğu silsileye odaklandım ve tam olarak her seferinde Upgrade Script'inin belli bir veritabanı adından sonra hata aldığını fark ettim. Bu veritabanı da önceden replike ediliyordu, ama uzun süre önce ilgili arkadaşların talebiyle replikasyondan çıkartmıştım. Database Engine servisini yine T902 ile çalıştırdım ve bu veritabanını bu SQL Server Instance'ından Detach ettim, yani bu veritabanının ilişiğini kestim. Daha sonra Upgrade Script'i olan [sp_vupgrade_replication] isimli Script'i Query Editor'den elle çalıştırınca hata oluşmadığını gördüm. Database Engine servisini T902'siz tekrar çalıştırdım ve Viola! Database Engine servisim artık sorunsuz çalışıyordu. Demek ki bir şekilde, kim bilir neden, ama bu veritabanımın içinde eski replikasyon kurulumuyla ilgili bazı sıkıntılar/artıklar vs kalmıştı ve Service Pack 1 kurulumunda değil, ama Cumulative Update kurulumunda hataya neden olmuştu.

    Tabii ki konuyu burada bırakamazdım, sonuçta bu veritabanının da Upgrade işlemini tamamlatmam ve taşımam gerekiyordu. İçimden bir ses veritabanını tekrar Attach edince, yani tekrar SQL Server Instance'ına bağlayınca sorunun kendiliğinden çözüleceğini söylüyordu ve aynen öyle de oldu. Cumulative Update ve Upgrade Script'lerinin çalıştırılması sırasında hataya neden olan veritabanı, tekrar Attach edilince herhangi bir sıkıntıya neden olmamıştı.

    Böylece bir güncelleme sürecini daha kazalı belalı da olsa atlatmış oldum. Olur da benzer bir sorun ile karşılaşırsınız ve faydası olabilir diye sizlerle de paylaşmak istedim.

    Kazasız, belasız günler dilerim!

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



    20 Nisan 2017 Perşembe

    Duyuru: Microsoft İş Ortaklığı

    Gün itibariyle, gerek Microsoft Azure bulut ortamında, gerekse geleneksel ortamlardaki Microsoft SQL Server konusunda kurulum, sağlık bakımı (healthcheck), performans iyileştirme çalışmaları, sürekli kullanılabilirlik ve felaket önleme planlama ve kurulumları konusunda uzmanlaşmış olan ve hizmet veren şirketimin Microsoft Silver Cloud Partner olduğunu iftihar ile ilan ederim efendim.

    Bu iş ortaklığı sayesinde, yaptığımız projelerde Microsoft ile daha yakın çalışabileceğiz. Projelerimizde Microsoft ürünleriyle ilgili karşılaştığımız sorunlar için Microsoft'tan daha iyi destek alabileceğiz.

    Bu süreçteki desteği için Hakan Türköner'e ve bu vesileyle benimle çalışmayı tercih eden değerli tüm müşterilerime teşekkür ederim.

    Verdiğimiz hizmetler hakkında daha fazla bilgi için lütfen tıklayın.


    4 Nisan 2017 Salı

    Olası gizemli kesintilere hazırlıklı mısınız?

    Yoğunluktan dolayı yine uzun bir süre yazamadım, projelerden kalan bu aralıkta hemen bu yazıyı yazmak istedim.

    Bir müşterimde bir süredir büyük bir tabloda yaşanan dahili kayıt tekilleştirici mekanizmasının yarattığı kesinti sorununun giderilmesi konusunda çalışıyorduk. Nihayet sorunu giderdik. Bu yazımda sorunun tanımından ve çözmek için neler yapılabileceğinden özetle bahsedeceğim.

    Yazının başında belirtmem gerekir ki bu yazı Microsoft SQL Server konusunda bazı ileri seviye terim ve kavramları bilmenizi gerektiriyor. Bu yazıda her kavramı tek tek açıklamayı hedeflemiyorum.

    "Dahili kayıt tekilleştirici" nedir önce ondan bahsedeyim. Muhtemelen oldukça küçük bir azınlığın haberdar olduğu bir terim olduğu için ilk bakışta ilginç görünse de Türkçe olarak tanımlamak istedim ki biraz daha anlaşılabilir olsun. Efendim bahsettiğim kavram Microsoft SQL Server ürünündeki Clustered tablolardaki tekrar eden kayıtların tekilleştirilmesi için kullanılan Uniquifier kavramı. Öncelikle bu kavram tam olarak nerede, nasıl ve neden kullanılıyor ondan bahsedeyim.

    Bir tabloyu Clustered yaptığınızda, yani bir tabloda bir Clustered indeks oluşturduğunuzda, o tablodaki tüm kayıtların eşsiz olması gerekiyor. Bu eşsizliği, oluşturacağınız Clustered indeksi Unique Clustered indeks olarak oluşturarak sağlayabilirsiniz; aksi takdirde, yani indeksinizi Unique Clustered indeks olarak değil de sadece Clustered olarak oluşturursanız SQL Server indeksinize Uniquifier adında dahili bir alan ekleyecektir. Normal şartlar altında, SELECT sorgularınızda veya [sp_helpindex] ile ve benzeri diğer yöntemlerle bu alanı görmezsiniz. Bu alanın varlığını ve etkilerini görebilmek için özel bazı yöntemler kullanmak gerekiyor. Heap tablolarda, yani bir Clustered indeks tanımlanmamış bir tablodaki kayıtların bir Unique indeks ile veya Uniquifier ile eşsizleştirilmesine ihtiyaç yoktur.

    Uniquifier isimli alanın veritipi INT'tir, tutabileceği azami değer 2.147.483.647'dir ve diskte 4 baytlık yer kaplar. Cluster Key kendini tekrar etmedikçe Uniquifier'ın değeri artmaz, 0 olarak kalır ve diskte de yer kaplamaz. Cluster Key, Clustered indeksi oluşturan alandır. Clustered indeksi oluşturan alan sayısı birden fazla da olabilir, birden fazla alandan oluşan indekslere de Composite indeks denir.

    Biraz da örnek ve görsellerle anlatayım, bu kavramlara çok yabancı olan arkadaşlar için daha anlaşılabilir olsun.

    Not: Öncelikle şunu belirtmek gerekiyor ki DBCC PAGE komutu Microsoft tarafından resmen desteklenen ve dokümante edilmiş bir komut değildir. Bu ve diğer komutları canlı/üretim sunucularınızda çalıştırmamanızı öneririm.

    Bu örnekte önce [uniq_test] adında bir tablo oluşturuyorum ve bu tablodaki [id] alanı için de bir Clustered indeks oluşturuyorum. Sonra aynı kayıttan 2 tane oluşturuyorum. DBCC IND komutuyla [test] veritabanındaki [uniq_test] tablosunun Page'lerini tespit ediyorum. DBCC PAGE komutuyla da yine [test] veritabanındaki birinci veri dosyasındaki 36296 numaralı Page'in içeriğine bakıyorum.

    CREATE TABLE [uniq_test](id INT, isim NVARCHAR(50), soyisim NVARCHAR(50));
    GO
    CREATE CLUSTERED INDEX [CIX] ON [uniq_test]([id]);
    GO
    INSERT INTO [uniq_test] VALUES(1, 'Ekrem', 'Önsoy');
    GO 2
    DBCC IND([test], [uniq_test], 1);
    GO
    DBCC PAGE(test, 1, 36296, 3) WITH TABLERESULTS;


    DBCC PAGE'in sonucu

    Not: Burada [isim] ve [soyisim] alanlarının aynı olması değil, [id] alanının aynı olması Uniquifier'ın kullanılmasını sağlıyor. [isim] ve [soyisim] alanları farklı da olsa yine de Uniquifier değeri artacaktı.

    Not: DBCC IND komutu sizde muhtemelen farklı bir Page numarası döndürecektir, bunda hiçbir gariplik veya sakınca yok. Eğer örneği siz de kendi test ortamınızda uygulamak istiyorsanız DBCC PAGE komutuyla sizde dönen Page numarasını kullanın.

    DBCC PAGE ile ilgili Page'in içerisine baktığımda yukarıdaki ekran görüntüsünde paylaştığım gibi bir sonuç görüyorum. Önceden de belirttiğim gibi eğer Clustered indeksimi oluştururken Unique Clustered indeks olarak oluştursaydım veya hiç Clustered indeks oluşturmasaydım ve yine bu Page'in içine baksaydım o zaman UNIQUIFIER diye bir alanı hiç görmeyecektim.

    Yukarıdaki ekran görüntüsünde oluşturduğum 2 kayda ait değerleri her kayıt için ayrı ayrı renklerle ve dikdörtgen ile işaretledim. Önce lütfen daha uzun olan kırmızı ve mavi dikdörtgenlere bakın. Bu değerlere dikkatlice baktığınızda UNIQUIFIER'ın normalde 4 bayt uzunluğunda oduğunu, diskte ne kadar yer kapladığını ve o anki değerini göreceksiniz. (physical) 0 olduğunda diskte yer kaplamıyor demektir, yani aynı değer birden fazla tekrar etmemiş demektir. Bu nedenle uzun kırmızı dikdörtgende (physical)'ın yanında 0 varken, uzun mavi dikdörtgen ile işaretlediğim 2. kayda ait değer 4. Kırmızı ile işaretlediğim ilk kayda ait UNIQUIFIER'ın değil de mavi ile işaretlediğim ikinci kayda ait UNIQUIFIER'ın diskte 4 bayt yer kapladığını da küçük dikdörtgenlerle çevrelediğim Record Size değerlerinden anlayabilirsiniz. İlk kaydın boyutu 39 bayt iken, ikinci kaydın boyutu 4 baytlık UNIQUIFIER değer nedeniyle 43 bayt.

    Eğer aynı kaydı 3. kere ekleseydim UNIQUIFIER'ın değeri 2 olacaktı ve INT veritipindeki bir alanın alabileceği azami değer olan 2.147.483.647'ye kadar gidecekti. Şayet aynı Cluster Key değeriyle bir kayıt bu kadar tekrar ederse, bir sonraki kaydı oluşturamazsınız ve aşağıdaki hatayı alırsınız:

    "The maximum system-generated unique value for a duplicate group was exceeded for index with partition ID XXX. Dropping and re-creating the index may resolve this; otherwise, use another clustering key."

    Emin olun, böyle bir durumla karşılaşmak istemezsiniz. Çünkü bu durumla karşılaştığınızda bu demektir ki tablonuzda en az 2 küsur milyar kayıt var ve muhtemelen önemli bir tablonuzdur ki bu kadar besleniyordur.

    Bu sorun, hatalı tablo tasarımından kaynaklanır. Kayıtları blok blok silmeniz bir şey ifade etmez, çünkü UNIQUIFIER değeri böyle sıfırlanmaz. UNIQUIFIER değerinin sıfırlanması için tekrar eden kaydın tamamının silinmesi veya blokları sildikten sonra tabloyu hata mesajında da belirtildiği gibi komple yeniden oluşturmanız gerekir. Bu da size ancak bir sonraki hataya kadar zaman kazandırır.

    Firmalar iş hayatlarına başlarken genelde düşük bütçeyle başlar, bu nedenle her konuda uzmanı bünyelerinde barındıramazlar ve böyle tasarımlar da genelde bu gibi nedenlerden kaynaklanır. Çünkü eğer firmanın bünyesinde donanımlı bir veritabanı yöneticisi varsa ve tasarım sırasında kendisine tablo tasarımı danışılsa, o böyle bir tasarımın yaratacağı olası sonuçları önceden öngörebilir.

    Bu sorunu düzeltmek için tablonuzu Heap'e çevirebilir veya Clustered indeksinizi değiştirebilirsiniz. Tabii ki bunlar çok ciddi süreçler, çok iyi hazırlık ve doğru aksiyon gerekiyor. Aksi takdirde, performans sorunu gibi yeni sorunlarla karşılaşabilirsiniz. Belki fırsat olursa ileride de bu konulardan bahsederim.

    Ekrem Önsoy




    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