MsSQL Optimizasyonu — Sistem Çalışma Performansı

Bilgi Teknolojileri dünyasının en karmaşık ve etki noktalarına yönelik sınırları tam olarak çizilemeyen iki konusu Performans ve Güvenlik olarak yer almaktadır.

Bugün; Microsoft şirketinin geliştirmiş olduğu Microsoft SQL Server ve içindeki tüm bileşenleri yapılandırmak, yönetmek için kullanılan veritabanı yönetim sistemi hizmeti sağlayan Microsoft SQL Server Managment Studio aracı üzerinde yer alan veritabanı hizmeti üzerine sistem-uygulama çalışma performanslarının optimize edilmesine yönelik kısa notlarımı paylaşıyor olacağım.

Şimdiden iyi okumalar.

1-Sistem ve Mimari Performans Optimizasyonları

Veritabanı mimarilerinde sorgulama performansından önce planlanılması gerekli olan bir takım konular yer almaktadır.Bu konular doğrudan sistemsel ve yapısal olarak çalışma performansını etkilediğinden dolayı kimi durumlarda Sorgu Talep-Sorgu Yanıt/Tepki (Request Query -Response Query) konularında çeşitli problemler oluşturmaktadır.

Bu konuların-çözümlerin başlıcaları ise;

a-Sisteme Yönelik Donanımsal Çözüm Planlamaları

Birçok veritabanı uzmanın göz ardı ettiği (sonradan fark edilen); sistemi doğrudan etkileyen baz faktörlerin başında yer alan ve niceliksel bilgi gerektiren çözümlerin başında yer alan geliştirme/iyileştirme adımıdır.

Gerçekleştirilen projelerde (ölçeği gözetmeksizin) yoğunluklu olarak proje mimarisi, aksiyonel yapı üzerine planlanmaktadır.Yani kısacası; sadece projeye yönelik verilerin barındırılacağı veritabanının mimari yapısı göz önünde bulundurulmaktadır.

En iyi ya da optimum seviyedeki veritabanı tasarımına sahip olabilirsiniz; ancak eski bir donanım altyapısı ile süreçlerinizi devam ettiriyorsanız donanımsal yetersizlikten ilgili tüm sistemlerinizin çalışma yapıları doğrudan etkilenebilmektedir.

Planlanılan optimize olarak performanslı işlemlerde bulunan mimari yapı, belirli durumlarda beklenilenin aksine gelen talepleri karşılamakta çeşitli problemler yaşamaktadır.

Birçok geliştiricinin karşılaşımış olduğu basit bir senayroyaya dayalı durum örneklendirilecek olursa;

• Rutinde gerçekleşen performanslı sorguların belirli bir istek üzerinde gelmesi ile sistemin geç yanıtlar oluşturması,
• Geç dönülen yanıtların süresinin artarak ilgili sorguların askıya alınması,
• Askıya alınan sorguların belirli bir sayıdan sonra sistemi kilitlemesi (IDE-Arabirim ve Sunucu kilitlenmesi)

gibi durumlar gerçekleşmektedir. (Farklı durumlar türevlenebilir.)

Sisteme Yönelik Planlamalar kurgulanırken göz önünde bulundurulması gereken bazı genel performans etkileyici durumlar mevcuttur;

• İnşaa edilecek projenin mimari yapısına uygun optimum donanım öğelerine dayalı sistem oluşuturulmalıdır,
• Tüm donanımsal öğelere yönelik performans takibi gerçekleştirilmelidir,
• Tüm donanımsal öğelere yönelik çeşitli periyodik zaman dilimlerinde uygulanacak bakım planı oluşturulmalıdır,
• Tüm donanımsal öğelere yönelik optimum yazılım güncelleme planı (Güncel Yazılım) oluşturulmalıdır,

Bu durumların önüne geçmek için her zaman sorgu yada proje mimarisi optimizasyonu yeterli olmayabilir.
Karşılaşılan bu durumda ise sistemin donanımsal gereksinimlerini tekrardan kontrol etmek ilerleyen ve büyüyen projenin sağlıklı gelişmesini sağlayacaktır.

Gereksinimlere yönelik ek bilgilendirme detyaları için link üzerinden erişim gerçekleşitrebilirsiniz. EK

b-Veritabanı Mimari Planlamaları

Veritabanı mimarilerinde göz ardı edilen donanımsal çözümlere nazaran, sürekli olarak üzerine düşülen ve öncelikli olarak nitelendirilen; geliştiricilerin çokça varyasyonel alt çözümler ürettiği, planlama ve iyileştirmeler içeren sistematik bir geliştirme/iyileştirme adımıdır.

Hatırlatma: Literatür üzerinde temel olarak iki tip Veritabanı Mimarisi mevcuttur;

• Yerleşik Mimari Modeli (Standalone Architecture Model): Veritabanı ve Veritabanı Motoru aynı makine üzerinde yerleşik dosya sistemi içerisinde yer alan mimari modeldir.
  Sadece bir tek kullanıcının veri tabanına erişebildiği (Ayni anda iki kişi veri tabanına erişemez.) ağırlıklı olarak makine ağ sistemlerine bağlanmayan (ağ kullanıcılarına destek vermeyen), veritabanı içindeki bilgileri diğer makinelere paylaştırılamadığı, her kullanıcının “Local-Lokal” olarak kendi verisini düzenleyebildiği bir yapısı mevcuttur. Bu tip veri tabanlarına MS Access Veritabanı örnek olarak gösterilebilir.
• İstemci/Sunucu Mimari Modeli (Client/Server Architecture Model): Yerleşik Mimari Modeli veritabanlarına nazaran; sistem üzerinden devir alınan sınırlamaları kaldırması amacıyla geliştirilmiş ileri düzey mimari modeldir.
  Bu tür veritabanı sistemlerinde, veritabanı bir dosya sunucusu üzerinde bulundurlur ve veriler ilgili bilgisayar üzerinde saklanır. Buradaki bilgisayar İstemci/Sunucu veritabanı yapısının Sunucu yapısını temsil etmektedir.
  Bu veritabanına başka bilgisayarlar üzerinden erişen kullanıcılar ise İstemci kısmını temsil etmektedir.
  İstemci/Sunucu Veritabanı kullanıcıları bir ağ ortamına yayılmış yapıda kullanım gerçekleştirmekte ve bu şekilde her kullanıcı farklı konumlardan veritabanına aynı anda erişebilmekte, sınırlama problemleri yaşamamaktadırlar.

Bu mimariler üzerine çeşitli ihtiyaçlar ve gereklilikler doğrultusunda veri barındırma senaryoları inşaa edilir.
Kullanılan/Tercih edilen mimari tip çeşitli senaryolar doğrultusunda modellenir ve ilgili süreç çözümleri üzerine adapte edilir.

Ön planlamanın dışında gerçekleşen ve projeyi yeniden şekillendirebilecek ek geliştirme çalışmaları (kararlar) hassas planlama üzerinden geçmez ise; faal olarak yürütülen uygulama ya da işlemler üzerinde performanstan kaynaklı aksaklıklara neden olabilir.

Bu ana nedenden ötürü Mimari Plan ve Proje arasındaki çalışmalar hassas düzeyde planlı olması gerekmektedir.

c-Veritabanı Yedekleme Planlamaları

Veritabanı mimarilerinde çeşitli periyodik zaman dilimlerinde verilerin herhangi bir eylem dolayısıyla kaybının önüne geçmek için yedekleme işlemleri gerçekleştirilmektedir.

Hatırlatma: Literatür üzerinde temel olarak üç tip Veritabanı Yedekleme Tipi mevcuttur;

• Full Backup (Tam Yedekleme): Yedeklenme anında veritabanında bulunan herşeyin (Tüm Bilgilerin) yedeklendiği yedekleme tipidir.Yüksek veri miktarı içerdiğinden dolayı planlı zaman dilimlerinde gerçekleştirilmektedir.
• Differential Backup (Deferansiyel (Fark-Parçalı Dilimler) Yedekleme): Yüksek miktarda/düzeyde verinin bulunduğu veritabanları üzerinde belirli zaman dilimlerinde (Aralıklarında) ilgili iki zaman değeri arasındaki verilerin yedeklendiği yedekleme tipidir.Veritabanı geri dönüş senaryoları üzerinde sürekli başvurulan yedekleme çözümüdür. (Planlanılması dahilinde verimliliği yüksek düzeydedir.)
• Transaction Log Backup (İşlem Günlüğü Yedekleme): Veritabanları üzerinde yapılan her işleme ait bilgilerinin yer aldığı verilerin yedeklendiği yedekleme tipidir. (Veri içermez, sadece log dosyalarını baz alır.)

Bu yedekleme planlamaları; doğrudan sistem çalışması zaman çizelgesine göre planlanmaktadır.
Planlamanın merkezi değeri ise veri kaybının yaşanmaması (Hiç kayıp olmaması) ya da en iyi durum dahilinde mimimum veri kaybının gerçekleşmesini sağlamaktır.

Bu planlamalar kurgulanırken göz önünde bulundurulması gereken bazı genel performans etkileyici durumlar mevcuttur;

• Çalışan sistem Online Transaction Processing (OLTP) ortamında ise sistemlerin kilitlenmesi ya da askıya alınmasını önleyerek yoğun sıklıkta yedekleme alınmalıdır, (Özellikle Differential Backup Stratejisi)
• SQL Server üzerinde herhangi bir güncellenme gerçekleşmediğinde (Sistemsel) yedekleme stratejileri sistem performansına dayalı olarak tekrar tasarlanmalıdır,
• SQL Server üzerindeki sistemlerde gerçekleşen aktivite işlemlerinin planları çıkartılıp yoğunluk ve faaliyete göre sistemlerdeki yedeklemeler tekrar optimizasyona dayalı tasarlanmalıdır,
• SQL Server üzerinde yer alan ilgili veritabanlarına yönelik Log bilgileri sistem performansına göre en esnek ve kurtarılabilir zamanlama planına göre yedeklenecek şekilde tasarlanmalıdır,
• Mimari planlama yanlızca işleyen (İşlemesi öngörülen) proje süreçlerine göre değil yedekleme mimarisi altyapısıda planlanarak tasarlanmalıdır,
• Yedekleme gerçekleştirilecek genel dizin bağlantıları (Yerel ya da Bulut) üzerindeki veri aktarım zamanı durum çizelgeleri üzerinde iyi tasarlanmalıdır, (Yedek Alma ve Yedekten Dönme)
• Yedekleme gerçekleştirilecek dizine yönelik altyapı donanım gereksinimleri iyi planlanıp, sürece göre tasarlanmalıdır. (Gerekli yedekleme alanı olmamsından dolayı sistemin askıda kalması vb. nedenler…)

NOT-1: Veritabanı yedeği alınırken; veritabanı oluşturma ve güncelleme, yeni alt dizinler oluşturma, spesifik anahtar öğelerinin yer aldığı sorgulamalar (Updatetext, Writetext… vb.) yedek alınma işleminin gerçekleştirilmesini engeller.Yedekleme planının ilgili işlemler göz önünde bulundurularak oluşturulması gerekmektedir.

NOT-2: Transaction Log üzerine kaydedilemeyen işlemler (Non-Logged Data/Actions) yedekleme planları üzerinde ek planlama dahilinde yer alması gerekmektedir. (Spesifik Durumlar)

Veritabanı Yedekleme Planlaması doğrudan faal olan sistemler üzerinde performans kaybı ya da sistemin anlık askıda kalması gibi durumlara neden olabileceği için süreç mimarisinin planlı bir düzeyde olması gerekmektedir.

d-Veritabanı Bakım Planlamaları

Veritabanları üzerinde çeşitli durumlarda yıpranmalar ve performans kayıpları meydan gelmektedir.Bu problemler doğrudan sistematik işleyişi etkilediğinden dolayı çalışan yapılar üzerinde problemler oluşturmaktadır.

Genel olarak ortaya çıkan problemlerin başlıcaları;

• Veritabanı bütünlük yapısının bozulması,
• Veritabanlarının Index yapılarını bozulması,
• Veritabanlarının boyutlarının öngörülemez seviyede hendesi olarak büyümesi,
• Veritabanlarının veri barındırma alanlarının yetersiz kalması (Anlık olarak)

olarak ifade edilebilir.

Mevcut problemleri önlemek ve süreci takip etmek adına; çeşitli kompleks T-SQL sorgulamaları kurgulamak yerine SQL Server Mangment Studio içerisinde yer alan Maintance Plan (Bakım Planı) çözümleri çözüm olarak uygulanabilir.

Maintance Plan ile;

• Veritabanını planlanabilir olarak daraltabilir,
• Veritabanını planlanabilir olarak yedekleyebilir,
• Veritabanı istatistiklerini güncelleyebilir,
• Veritabanının bütünlüğünü takip edip, doğrulayabilir,
• Veritabanı eylem geçmişini düzenleyebilir,
• Planlanabilir operatör bildirimi gerçekleştirebilir,
• Sistemsel artık olan bakım dosyalarını temizleyebilir,
• SQL Server Agent eylemi gerçekleştirebilir,
• Transact-SQL deyimi yürütebilir,
• Index oluşturabilir ve düzenleyip yapılandırabilir

işlemlerini gerçekleştirebilirsiniz.

Veritabanı Bakım Planlaması doğrudan faal olan sistemler üzerinde performans kaybı ya da sistemin anlık askıda kalması gibi durumlara neden olabileceği için süreç mimarisinin planlı bir düzeyde olması gerekmektedir.

2-Sorgu Performans Optimizasyonları

SQL Sistem ve Mimari çözümlerinin yanı sıra; Sorgu Performans Optimizasyonları doğrudan nitelikli çözümlemede bulunma ve sistematik mimari inşaası gibi yetkinlik gerektiren baz konular içermektedir.
Ek olarak Sistem ve Mimari çözümlerine nazaran bir nebze daha uzun soluklu iyileştirme süreçleri yer almaktadır.

Proje inşa süreçlerinde yoğunluklu olarak akış ve süreçlerin planlaması gerçekleştirilmektedir.Bu eylemler üzerinde veri edinimi sağlayacak öğeler/yapılar performansa bağlı olarak çokça evrime uğramaktadır.

Kimi zaman dilimlerinde kullanmış olduğunuz sorgu kalıplaşmış hale gelip, birTable (Tablo) yada View (Görünüm) formatına dönüştürülüp Index Mimarisi ile üst seviye performansa çıkartılıp, kimi zaman diliminde ise sorgu cümleciği içerisinde yer alan dönüştürme operatörleri yerel bir formata dönüşüp fonksiyonel bir yapıya evrilmektedir…

Hatırlatma: Literatür üzerinde yer alan ve sorgulamalar içerisinde kullanılan (Öncesi-Sonrası) temel beş tip Veritabanı Öğesi mevcuttur;

• Table (Tablo): Veritabanı üzerinde yer alan satır ve sütunlardan oluşan verilerin barındırılmış olduğu öğedir.
• Temporary Table (Geçici Tablo): Veritabanı üzerinde geçici bir süre için T-SQL ile oluşturulan ve veri barındırılan tablo öğesidir.
• View (Görünüm): Veritabanı üzerinde çeşitli kıstaslar üzerine oluşturulmuş sanal tablo öğesidir.
• Function (Fonksiyon): Veritabanı üzerinde sürekli olarak tekrarladığımız sorgu cümleciklerine tek bir noktadan erişmemizi sağlayan kural öğesidir.
• Stored Procedure (Saklı Yordam): Veritabanı üzerinde özelleşmiş işleri-eylemleri yerine getirmek üzeri oluşturulmuş iş öğesidir.

Öğe kullanım planının sürekli evrime uğraması uygulama süreçlerinde gerçekleşen değişim ile oluşan farkındalıktan kaynaklanmaktadır.

Bu planlamalar kurgulanırken göz önünde bulundurulması gereken bazı genel performans etkileyici durumlar mevcuttur;

• Süreklilik arz eden sorgu cümlecikleri mevcut ise Table (Tablo) ya da View (Görünüm) öğelerine dönüştürülüp Index yapısı kurgulanarak performans yapılı tasarım oluşturulmalıdır,
• Table (Tablo) öğleri inşaa edilirken ilgili veri alanlarına atanacak veri tipleri doğru ve optimimum formatta belirlenmelidir,
• Table (Tablo) öğleri inşaa edilirken, tablolarda yer alacak Primary Key (Birincil Anahtar) alanları bağlantı kurulacak tablolar planlanarak atanmaya yönelik tasarım oluşturulmalıdır,
• Table (Tablo) öğeleri inşaa edilirken, tablolarda yer alacak Foreign Key (Yabancı Anahtar) alanları bağlantı kurulacak tablolar planlanarak atanmaya yönelik tasarım oluşturulmalıdır,
• Table (Tablo) öğeleri inşaa edilirken Index Mimari yapısı Non-Clustered Index yerine ağırlıklı Clustered Index kullanmaya yönelik tasarım oluşturulmalıdır,
  Non-Clustered Index verileri fiziksel değil mantıksal olarak sıralı bir şekilde tutmaktadır.
  Yani; Non-Clustered Index; Leaf yapısında Clustered Index’e fark olarak veriler değil, verilerin nerede olduğuna ilişkin bilgiler yer almaktadır.
  (Az sayıda sorgulama mevcut ise Non-Clustered Index önerilmektedir.)
• Table (Tablo) öğeleri sürekli olarak Insert (Eklemek) Update (Güncellemek) ve Delete (Silmek) işlemlerine maaruz kalıyor ve Index oluşturulmuş ise; takip ve izleme formatlarınızda Index Fragmantasyon analizi yer almalıdır,
• Tüm Table (Tablo) sorgulama işlemleriniz, anlık işlem yapılan öğeyi kilitlememek ve askıda işlem kalmasını bir nebze önlemek adına WITH (NOLOCK) anahtar deyimlerini kullanmaya yönelik gerçekleştirilmelidir,
• Tüm sorgulama işlemleriniz, optimum kapasitede Sadece kullanılacak ilgili veriler oluşturulmaya yönelik gerçekleştirilmelidir,
• Tüm sorgulama işlemleriniz, optimum kapasitede Temporary Table (Sanal Tablo) kullanmamaya yönelik gerçekleştirilmelidir,
• Tüm sorgulama işlemlerinin sorgulama performansı test edilip, kayıt altına alınacak şekilde süreç takip mekanizması (kurgusu) kurulumu gerçekleştirilmelidir.

Belirtilen çözümler dışında ek Öğe Kullanım Performansı kazanımı sağlayacak çözümlerde çeşitli kaynaklar üzerinde yer almaktadır, bunlar baskın olarak inşaa edilecek mimari yapıya yönelik ortaya çıkmakta ve kullanılmaktadır.

EK-Göz Ardı Edilen Sorgulama Hatalarından Kaçınmak

Sorgu Performansı optimizasyonlarına yönelik ek olarak hatırlatmada bulunulacak birkaç alt çözümde yer almaktadır.Bunlar;

• Kısıtlı sorgular oluşturmaya çalışınız,
  (WHERE, LIKE anahtarlarını kullanmaya özen gösteriniz.)
• Karmaşıklıktan kaçınmak için ALIAS (AS) özelliğini kullanınız,
  (Birden çok Table (Tablo) içeren sorgulamalarda değer kaynağı probleminden kaçınınız.)
• İç içe sorgulamalardan (SUBQUERY) kaçınınız,
  (Alt sorgular için imkan varsa Table (Tablo) ya da Function (Fonksiyon) oluşturunuz.)
• Birden çok Table (Tablo) birleştirme işlemi gereken durumlarda en az sayıda alan sorgulamaya çalışınız,
  (UNION ve UNION ALL içeren sorgularda gereksiz alanları sorgu içerisinden çıkartmaya özen gösteriniz.)
• Gerekmedikçe birden çok Table (Tablo) sorgulama işlemlerinden (JOIN) kaçınınız,
• Sorgulama algoritmasına uygunluğu değerlendirilerek verileri gruplayarak almaya özen gösteriniz.

olarak ifade edilebilir.

Bu bölümde genel manada SQL Management Studio ve Sorgulama Performansı iyileştirmelerine yönelik çözüm ve önerileri ele almaya çalıştım.
Gelecek yazımda SQL Management Studio Sistem Takibi üzerinde kullanılan popüler çözümler, araçlar ve teknolojilere değinmeye çalışacağım.

İyi günler, iyi çalışmalar…