Deneyimli veritabanı uzmanları bile SQL Server’da belirli hataları gözden kaçırabilir. Peki neden? Veritabanı komutlarının karmaşık yapısı, farklı kullanım senaryoları ve sistemin kendine özgü davranışları, en tecrübeli kullanıcıları bile zor durumda bırakabilir. SQL hatalarının çoğu, sorguların, tabloların veya ilişkilerin yanlış yapılandırılmasından kaynaklanır ve bu hatalar sistem performansını beklenmedik şekilde düşürebilir.
Veritabanı hatalarını incelediğimizde karşımıza beş temel kategori çıkar: “Syntax Error” (sözdizimi hatası), “Table Not Found” (tablo bulunamadı), “Column Not Found” (sütun bulunamadı), “Duplicate Entry” (yinelenen kayıt) ve “Foreign Key Constraint Violation” (yabancı anahtar kısıtlaması ihlali). ‘John’ gibi bir ismi tırnak içine almamak sözdizimi hatasına neden olurken, olmayan bir tablo adını sorgulamak “Table Not Found” hatasıyla sonuçlanır. Doğru tasarlanmış sorgular sadece veritabanının hızını artırmakla kalmaz, aynı zamanda gereksiz kaynak tüketimini engeller. Bu sebeple, veritabanı komutlarının doğru yazımı hem veri bütünlüğü hem de performans açısından hayati önem taşır.
Bu makalede SQL Server ortamında en yaygın sorgu hatalarını, bu hataların sonuçlarını ve çözüm yöntemlerini sistematik bir yaklaşımla ele alacağız. Veritabanı yöneticisi olarak yıllardır çalışıyor veya geliştirici olarak yeni başlıyor olsanız da, veritabanı bağlantısı ve sorgu optimizasyonu konularında kritik bilgileri edineceksiniz.
Sorgu Yazımında Sık Yapılan Hatalar
SQL sorgu yazımı, veritabanı performansını şekillendiren kritik bir süreçtir. Deneyimli geliştiriciler bile farkında olmadan performansı düşüren hatalar yaparlar. Bu hataları tanımak ve önlemek, verimli veritabanı sistemleri oluşturmanın ilk adımıdır.
SELECT * Kullanımı
“SELECT *” ifadesi, veritabanı dünyasındaki en yaygın anti-paternlerden biri olarak kabul edilmektedir. Bu komut, gerçekte ihtiyacımız olmayan veriyi de belleğe yükleyerek, gereksiz I/O işlemleri ile CPU kullanımına neden olur ve bu durum sistemin genel performansını olumsuz etkileyebilir. Pratikte yalnızca gerekli sütunları belirtmek, iki açıdan önemli fayda sağlar: Öncelikle, sorgu performansını iyileştirir ve daha hızlı sonuçlar elde etmemizi sağlar. İkinci olarak, tabloya ileride eklenecek sütunların mevcut kodunuzu etkilemesini engelleyerek, kodunuzu daha sürdürülebilir hale getirir. Sorgu optimizeri, yalnızca ihtiyaç duyulan sütunları seçtiğinizde daha etkili ve verimli planlar oluşturabilir. Bu nedenle, dikkatli bir şekilde sorgu yazmak büyük önem taşır.
Parametresiz Sorgular
Parametresiz sorgular, hem güvenlik hem de performans açısından ciddi sorunlar oluşturur ve bu durum, veritabanı yöneticileri için önemli bir endişe kaynağıdır. SQL enjeksiyonu riski bir yana, bu tür sorgular, sorgu optimizasyonu sürecini de olumsuz etkileyerek sistemin genel verimliliğini düşürürler. SQL Server’ın execution plan oluşturma mekanizması, stored procedure’ler ilk çalıştırıldığında aldığı parametrelere göre plan üretir. Bu süreç, veritabanının performansını etkileyen kritik bir adımdır. Sonraki çağrılarda parametreler değişse bile, aynı plan kullanılır ve bu durum, “parameter sniffing” sorunu olarak bilinir. Bu sorun, performans düşüşlerine yol açarak kullanıcı deneyimini olumsuz etkileyebilir. SQL Server 2022’de tanıtılan Parameter Sensitive Plan özelliği, farklı parametreler için ayrı planlar saklayarak bu sorunu azaltır ve böylece sistemin performansını artırmayı hedefler.
SQL Server 2022, bu tür sorunları minimize etmek için daha akıllı planlama algoritmaları sunar. Bu sayede, veritabanı yöneticileri, sorguların performansını artırmak için daha etkili stratejiler geliştirebilirler. Ayrıca, sistemin genel verimliliğini artırmak için sorgu yazımında dikkat edilmesi gereken en iyi uygulamaları takip etmek de önemlidir.
Non-SARGable Koşullar
Non-SARGable koşullar, indeks kullanımını engelleyen sorgu yapılarıdır. İndekslenmiş sütunlara fonksiyon uygulandığında (SUBSTRING, YEAR, DATEDIFF), SQL Server indeksi kullanamaz ve tablo taraması yapmak zorunda kalır.
-- Non-SARGable sorgu
SELECT * FROM Person WHERE YEAR(BirthDate) > 1987
-- Sargable alternatifi
SELECT * FROM Person WHERE BirthDate > '19871231'
İlk sorguda, özellikle BirthDate sütunundaki indeks işlevsiz kalır ve bu durum, sorgunun genel performansını olumsuz etkiler. İkinci sorguysa, indeksten tam verim alarak performansı önemli ölçüde artırır.
JOIN ve Filtre Sıralaması
Filtreleme stratejisi, sorgu performansını belirleyen önemli faktörlerden biri olarak kabul edilmektedir. Özellikle veri tabanı yönetim sistemlerinde, sorgu performansını etkileyen birçok unsur bulunmaktadır. JOIN üzerinde yapılan filtreleme, WHERE ile yapılan filtrelemeden daha verimlidir. Bu durum, JOIN filtresinin tabloları birleştirmeden önce veriyi azaltmasıyla ilgilidir; bu sayede daha az veri ile işlem yapılır. Diğer yandan, WHERE filtresi önce birleştirme işlemini gerçekleştirir, ardından filtreleme işlemi yapılır. Özellikle büyük tablolarda, JOIN filtrelemesi, gereksiz işlemleri önleyerek Disk I/O ve CPU kullanımını önemli ölçüde azaltır. Bu nedenle, sorgu tasarımında JOIN ve WHERE ifadelerinin doğru bir şekilde kullanılması, performans iyileştirmeleri için kritik öneme sahiptir. Ayrıca, sorguların karmaşıklığını azaltmak ve okunabilirliği artırmak amacıyla, mümkün olduğunca basit ve etkili filtreleme yöntemleri tercih edilmelidir. Bu yaklaşım, hem geliştiricilerin hem de sistem yöneticilerinin işini kolaylaştıracaktır.
Gereksiz Subquery ve CTE Kullanımı
CTE’ler, karmaşık sorguların daha anlaşılır hale gelmesine yardımcı olsa da, aşırı kullanımları sorgu performansını olumsuz etkileyebilir. Özellikle büyük veri setlerinde, CTE’lerin yeniden hesaplanması gerektiğinde, bu durum önemli bir zaman kaybına yol açabilir ve bu da genel verimliliği düşürebilir. Bu nedenle, CTE’lerin yalnızca gerçekten gerekli olduğunda ve performansın kritik olduğu durumlarda tercih edilmesi önerilir. Kullanıcıların, CTE’leri kullanmadan önce sorgularının gereksinimlerini dikkatlice değerlendirmeleri ve alternatif yöntemleri düşünmeleri önemlidir. Bu, daha iyi bir performans elde etmek için faydalı olabilir.
GROUP BY ve HAVING Yanlışları
Veri gruplandırma işlemlerinde WHERE ve HAVING ifadelerinin doğru kullanımı önemlidir. WHERE ifadesi kümeleme fonksiyonlarıyla (COUNT, AVG, SUM) kullanılamayacağından, gruplandırılmış veriler üzerinde filtreleme yapmak için HAVING gereklidir. Sık yapılan hatalardan biri, WHERE koşulunu GROUP BY’dan sonra uygulamaya çalışmaktır. Optimum performans için WHERE filtresini gruplandırma öncesinde, HAVING filtresini ise gruplandırma sonrasında kullanmak gerekir.
Hataların Sonuçları
Image Source: SeattleDataGuy’s Newsletter – Substack
Hatalı SQL Server sorguları, veritabanı sisteminde gözle görülmeyen ancak derinden hissedilen etkiler yaratır. Bu etkiler, genellikle kademeli olarak ortaya çıkar ve sistem yavaşlamaları başladığında, çoğu zaman kök nedenin hatalı sorgular olduğunu fark etmek oldukça güçleşir. Sorunların etkilerini sistematik olarak anlayabilmek, bu sorunların kök nedenlerini tespit edebilmek açısından son derece önemlidir; bu da erken müdahale şansımızı artırır ve sistemin genel performansını korumamıza yardımcı olur. Bu nedenle, sorguların dikkatli bir şekilde gözden geçirilmesi gerekmektedir.
Execution Plan Karmaşası
SQL Server’ın sorgu optimizasyon mekanizması, her sorgu için bir execution plan (yürütme planı) oluşturur. Karmaşık SELECT ifadeleri söz konusu olduğunda, binlerce farklı yürütme planı olasılığı ortaya çıkar [3]. Query Optimizer bu olasılıklar arasından en düşük maliyetli planı seçmeye çalışır, ancak hatalı yazılmış sorgular bu seçim sürecini önemli ölçüde zorlaştırır.
Execution plan’lar iki temel formda karşımıza çıkar: tahmini (estimated) ve gerçek (actual). Tahmini planlar sorgu çalıştırılmadan önce oluşturulur ve olası kaynak kullanımını öngörür. Gerçek planlar ise çalıştırma sonrasında fiili kaynak kullanımını gösterir [3]. Sorun şu ki, hatalı sorgular, özellikle istatistiklerin güncel olmadığı durumlarda, optimizerin yanlış plan seçmesine yol açar. Bu da indekslerin verimli kullanılamaması ve gereksiz tablo taramalarıyla sonuçlanır.
Bu durum, sorguların bekleme sürelerini artırarak genel sistem performansını olumsuz etkileyebilir. Özellikle yüksek yük altında çalışan sistemlerde, TempDB’nin aşırı kullanımı, kaynakların verimli dağıtımını zorlaştırır ve bu da daha fazla gecikmeye yol açar. Dolayısıyla, sorguların optimize edilmesi ve kaynakların dikkatli yönetilmesi, performans kayıplarını en aza indirmek için kritik öneme sahiptir.
Performans Kaybı (I/O, CPU, TempDB)
Performans sorunlarını “bekleyen” (waiting) veya “çalışan” (running) olmak üzere iki ana kategoride değerlendirebiliriz [3]. CPU bağımlı sorgularda, CPU süresi toplam geçen süreye yakın veya daha fazladır. Somut bir örnek vermek gerekirse: geçen süre 3000 ms, CPU süresi 2900 ms ise, zamanın neredeyse tamamı CPU işlemleriyle harcanmıştır [3].
Önbellekteki verileri okuma işlemleri (mantıksal okumalar), SQL Server’da yüksek CPU kullanımının birincil nedenidir. Disk I/O sorunları ise daha yaygın bir etki alanına sahiptir ve sistemdeki çoğu sorguyu olumsuz etkileyebilir [4]. Yavaş I/O performansının arkasında genellikle üç temel etken bulunur:
- Donanım yapılandırma sorunları, özellikle SAN konfigürasyonları ile ilgili olanlar, sıkça karşılaşılan zorluklardır.
- I/O kapasitesinin sistemin ihtiyaçlarını karşılayamaması, performans sorunlarına yol açabilir.
- Sürücü veya yazılım düzeyinde karşılaşılan teknik problemler, sistemin işleyişini olumsuz etkileyebilir.
TempDB çekişmesi, göz ardı edilen ancak ciddi performans kayıplarına neden olan başka bir faktördür. Birden fazla işlem eş zamanlı olarak TempDB’deki aynı kaynaklara erişmeye çalıştığında PAGELATCH_EX ve PAGELATCH_SH gibi bekleme durumları ortaya çıkar [5]. Bu durum, sorguların ve işlemlerin tamamlanma süresini uzatarak nihai kullanıcı deneyimini olumsuz yönde etkiler [6].
Özetle, hatalı veritabanı komutları yalnızca bireysel sorguların yavaşlamasına değil, tüm sistemin performansının düşmesine, CPU ve I/O kaynaklarının tükenmesine ve bazı durumlarda sistemin tamamen yanıt vermemesine kadar varan sonuçlar doğurabilir.
Veritabanı performans sorunlarının çözümünde, sistem yöneticilerinin ve geliştiricilerin bu etkenleri göz önünde bulundurarak proaktif bir yaklaşım benimsemeleri önemlidir. Ayrıca, düzenli olarak performans izleme ve analiz araçları kullanmak, potansiyel sorunları erken aşamada tespit etmeye yardımcı olabilir. Bu sayede, sistemin genel verimliliği artırılabilir ve kullanıcı deneyimi iyileştirilebilir.
Doğru Yaklaşımlar ve Çözümler
Veritabanı performans sorunlarını etkili bir şekilde çözmek için, öncelikle problemi doğru bir şekilde tanımlamalı ve ardından bu tanıma uygun sistematik çözümler geliştirmeliyiz. SQL Server’da optimum performans sağlayan stratejileri ise üç ana kategori altında detaylı bir şekilde inceleyebiliriz.
İndeks Bilinçli Sorgular
İndeksler, veritabanı sorgularını hızlandıran temel veri yapılarıdır. Ancak indeks tasarımı gelişigüzel yapılamaz. Etkili bir indeks stratejisi için şu kriterleri göz önünde bulundurmalısınız:
- Sorgularda sık filtrelenen ve join koşullarında kullanılan (SARGable) sütunlar için indeks oluşturun
- İndekslere sadece gerekli sütunları dahil edin; her fazla sütun disk alanını ve bakım maliyetini artırır
- Covering indeksler kullanarak sorgunun ihtiyaç duyduğu tüm verileri indeks yapısı içinde tutun
İndekslerin veri erişimini hızlandırdığını unutmayın, ancak her INSERT ve UPDATE işlemi, veritabanındaki indekslerin güncellenmesini gerektirir. Bu dengeyi kurmak, veritabanı tasarımının en kritik aşamalarından biri olup, performans ile veri bütünlüğü arasında sağlıklı bir denge oluşturmak için dikkatlice düşünülmelidir.
Query Hint Kullanımında Dikkatli Olun
Query hint’ler, SQL Server’ın sorgu optimizasyon mekanizmasına müdahale etmenizi sağlayan araçlardır. Bu araçlar, optimizerin seçtiği execution plan’ı değiştirerek çalışır. Ancak query hint’leri son çare olarak düşünmelisiniz. SQL Server genellikle mevcut istatistiklere göre en uygun planı seçer, bu nedenle hint’leri yalnızca problem kesin olarak tanımlandığında kullanın.
RECOMPILE hint’i her çalıştırmada yeni plan oluşturulmasını sağlarken, MAXDOP sorgunun paralel işlem sınırını belirler. Bu hint’leri uygulamadan önce test ortamında sonuçları doğrulamanız gerekmektedir.
Query Store ile Sistematik İzleme
Query Store, SQL Server 2016 ile eklenen ve sorgu performansını izlemeyi kolaylaştıran güçlü bir araçtır. Bu özellik, sorguların geçmiş performansını, uygulanan planları ve çalışma zamanı metriklerini saklar.
Query Store’un en büyük avantajı, plan değişikliklerinden kaynaklanan sorunları hızlıca tespit etmenizi sağlamasıdır. Sistem, farklı execution plan’ları saklayabilir ve gerektiğinde belirli bir planın kullanılmasını zorlayabilir (plan forcing). SQL Server 2017’den itibaren wait istatistiklerini de göstererek darboğazların tam olarak nerede oluştuğunu belirlemenize yardımcı olur.
Bu özelliği veritabanı seviyesinde etkinleştirebilir ve çeşitli parametrelerle (çalışma modu, veri yazma aralığı, istatistik toplama sıklığı) yapılandırabilirsiniz.
Query Store ile birlikte kullanıldığında, bu hint’ler sorgu performansını optimize etmek için etkili bir yöntem sunar. Ancak, her durumda kullanılmaları önerilmez; dikkatli bir analiz ve test süreci gerektirir. Bu nedenle, uygulamadan önce potansiyel etkilerini değerlendirmek ve sistemin genel performansını göz önünde bulundurmak önemlidir.
Sonuç ve Öneriler
SQL Server veritabanı komutlarını yazarken gösterdiğimiz özen, hem sistemin performansını hem de veri bütünlüğünü doğrudan etkiler. “SELECT *” kullanımı, parametresiz sorgular ve Non-SARGable koşullar gibi yaygın hatalar, execution plan karmaşasına ve performans kayıplarına yol açar. Bu hatalar öyle incelikli olabilir ki, yıllarca deneyime sahip veritabanı yöneticileri bile bunları gözden kaçırabilir.
Veritabanı performans sorunlarını çözmek, önce bu hataları tespit etmeyi, sonra sistematik çözümler uygulamayı gerektirir. İndeks yapılarını sorgu ihtiyaçlarına göre tasarlamak, SARGable koşullar kullanmak ve Query Store ile sorgu planlarını düzenli olarak izlemek, performans sorunlarını ciddi oranda azaltır. Özellikle karmaşık sorgularda doğru indeks tasarımı, veritabanı yanıt sürelerini dramatik şekilde iyileştirebilir.
Query hint’ler konusunda ihtiyatlı bir yaklaşım benimsemek gerekir. Bu araçlar, SQL Server’ın kendi optimizasyon mekanizması yetersiz kaldığında son çare olarak kullanılmalıdır. SQL Server genellikle en verimli execution plan’ı seçer, ancak bazı özel durumlarda manuel müdahale gerekebilir. Query Store gibi araçlar, bu kararları verirken bizlere gerekli görünürlüğü sağlar.
Veritabanı yönetiminde uzmanlaşmak, hataları tanımak ve önleyici stratejiler geliştirmekle mümkündür. Bu makalede anlattığım yaklaşımları uyguladığınızda, SQL Server veritabanlarınız daha hızlı, daha güvenilir ve daha verimli çalışacaktır. Çoğu zaman sorgu yazımındaki küçük düzeltmeler, sistem genelinde dikkat çekici performans iyileştirmeleri sağlar. Bu bilgileri günlük çalışmalarınıza dahil ettiğinizde, kullanıcılarınız ve iş süreçleriniz bundan önemli ölçüde fayda görecektir.
Sık Sorulan Sorular (SSS)
Veritabanı uzmanlığında ilerlemenin önemli bir parçası, doğru soruları sormak ve kapsamlı yanıtlar aramaktır. Aşağıda, SQL Server kullanımında karşılaşılan temel zorlukları ele alan sorular ve bu sorunların altında yatan teknik nedenleri açıklayan yanıtlar bulacaksınız.
SELECT * neden kötü?
“SELECT ” ifadesi veri çekme işlemlerinde sık kullanılan ama ciddi dezavantajlar barındıran bir yöntemdir. Bu yaklaşımda iki ana sorun göze çarpar. Birincisi, gerçekte ihtiyaç duyduğunuzdan çok daha fazla veri çekilerek gereksiz I/O ve CPU kaynağı tüketilir. İkincisi, tabloya ileride yeni sütunlar eklendiğinde kodunuzun davranışı beklenmedik şekilde değişebilir.
Yalnızca gerekli sütunları belirttiğinizde hem veri boyutunu küçültür hem de SQL Server’ın execution plan oluşturma sürecini ve indeks kullanımını optimize edersiniz. Bu basit değişiklik, özellikle yüksek hacimli veritabanlarında kaynak kullanımını önemli ölçüde azaltır.
İndeks neden kullanılmaz?
İndeksler doğru koşullarda veritabanı performansını artırsa da, her senaryo için uygun değildir. Küçük tablolarda indeks kullanımı genellikle gereksizdir; çünkü tüm tabloyu taramak zaten yeterince hızlıdır ve indeks ek yük getirir.
İndekslerin verimsiz olduğu diğer durumlar şunlardır:
- Nadiren sorgulanan sütunlarda indeks oluşturmak disk alanı israfıdır
- Çok sayıda NULL değeri içeren sütunlar indeks yapısı için ideal değildir
- Yüksek tekrar oranına sahip verilerde indeks faydası sınırlıdır
- Okuma işlemlerinden çok yazma işlemi yapılan tablolarda indeksler her yazma işleminde güncelleneceğinden performans düşüşüne neden olabilir
İndeks stratejinizi belirlerken sorgu desenlerinizi ve veri karakteristiklerinizi dikkatle analiz etmeniz gerekir.
Parametrik sorgular neden gereklidir?
Parametrik sorgular iki temel avantaj sunar: güvenlik ve performans. Güvenlik açısından, parametreli sorgular SQL enjeksiyonu gibi saldırı risklerini büyük ölçüde azaltır. String birleştirme ile sorgu oluşturduğunuzda (“+” operatörü kullanarak), kötü niyetli kullanıcılara veritabanınızda beklenmedik yetkiler vermiş olabilirsiniz.
Performans açısından parametreli sorgular, SQL Server’ın execution plan önbelleğini daha verimli kullanmasını sağlar. SQL Server 2022 ile sunulan Parameter Sensitive Plan (PSP) özelliği, tek bir sorgu için parametrelere bağlı olarak birden fazla execution plan saklayabilir. Bu sayede farklı veri dağılımları için optimize edilmiş planlar kullanılabilir ve geçmiş sürümlerde yaşanan Parameter Sniffing sorunu büyük ölçüde çözülür.
Parametreli sorguların etkin kullanımı, hem sistem güvenliğini artırır hem de sorgu performansını iyileştirir.
SSS
S1. SQL Server’da “SELECT ” kullanmanın sakıncaları nelerdir? “SELECT *” kullanmak gereksiz veri çekimine, yüksek I/O ve CPU kullanımına neden olur. Ayrıca, tabloya yeni sütunlar eklendiğinde kodun davranışı değişebilir. Bunun yerine sadece ihtiyaç duyulan sütunları belirtmek daha verimlidir.
S2. Parametresiz sorguların riskleri nelerdir? Parametresiz sorgular SQL enjeksiyonu gibi güvenlik açıklarına neden olabilir ve SQL Server’ın execution plan oluşturma sürecini olumsuz etkiler. Özellikle stored procedure’lerde ilk çalıştırmada oluşturulan plan, sonraki parametrelerle verimsiz olabilir.
S3. Non-SARGable koşullar neden performansı düşürür? Non-SARGable koşullar, SQL Server’ın indeksleri etkili kullanmasını engeller. Özellikle WHERE veya JOIN koşullarında indekslenmiş sütunlara fonksiyonlar uygulandığında (örneğin YEAR(BirthDate) > 1987), SQL Server indeksi kullanamaz ve tüm tabloyu taramak zorunda kalır.
S4. Query Store’un faydaları nelerdir? Query Store, sorguların, query plan’ların ve çalışma zamanı istatistiklerinin geçmişini saklar. Bu önemli ve kullanışlı özellik, plan değişikliği nedeniyle oluşan performans sorunlarını hızlıca çözmeye yardımcı olur ve bu sayede kullanıcıların belirli bir sorgu planının kullanılmasını sağlayabilir. Böylece, sistem yöneticileri ve geliştiriciler, sorgu performansını optimize etmek için gerekli verileri kolayca elde edebilirler. Bu, genel veritabanı yönetimi açısından büyük bir avantajdır.
S5. İndeksler her zaman faydalı mıdır? İndeksler her durumda yararlı olmayabilir. Küçük tablolarda, çok sık kullanılmayan sütunlarda veya çok fazla NULL değeri içeren sütunlarda indeks kullanımı verimsiz olabilir. Ayrıca, yazma işlemlerinin okuma işlemlerinden çok daha fazla olduğu tablolarda indeksler performansı düşürebilir.
Referanslar
[1] – https://learn.microsoft.com/en-us/sql/relational-databases/query-processing-architecture-guide?view=sql-server-ver16
[2] – https://www.geeksforgeeks.org/query-execution-plan-in-sql/
[3] – https://learn.microsoft.com/tr-tr/troubleshoot/sql/database-engine/performance/troubleshoot-slow-running-queries
[4] – https://learn.microsoft.com/tr-tr/troubleshoot/sql/database-engine/performance/troubleshoot-sql-io-performance
[5] – https://support.microsoft.com/tr-tr/topic/kb4131193-sql-server-2016-kullanırken-performans-sorunları-pagelatch-ex-pagelatch-sh-ve-tempdb-de-bekler-5ca96298-65d1-274c-0570-6e9d0bc17c6a
[6] – https://www.dmcteknoloji.com/blog-detay/tempdb-sql-server-performansinin-gizli-katili