Yazar : Çağlar Özenç
SQL Server kullanıcılarının yıllardır yaşadığı en yaygın performans sorunlarından biri, parametreli sorgularda karşımıza çıkan “parameter sniffing” problemidir. Özellikle dinamik yapıda çalışan ve opsiyonel parametrelerle yazılmış saklı yordamlar ya da raporlama sorguları, bazen bir kullanıcının sorgusu için iyi çalışan bir planın diğer kullanıcılar için felakete dönüşmesine neden olabilir. Bu durum sadece veritabanı yöneticilerinin değil, uygulama geliştiricilerinin de başını ağrıtır.
Microsoft, bu probleme yönelik ilk ciddi çözümünü SQL Server 2022’de Parameter Sensitive Plan Optimization (PSPO) ile getirmişti. Ancak bu mekanizma, sadece belirli türde parametre dağılımı olan sorgular için işe yarıyordu ve özellikle opsiyonel (NULL geçilebilen) parametrelerin kullanıldığı “mutfak lavabosu” prosedürlerde yetersiz kalıyordu.
İşte SQL Server 2025’te tanıtılan Optional Parameter Plan Optimization (OPPO), tam da bu noktada devreye giriyor. Bu yazıda, OPPO’nun neden önemli olduğunu, nasıl çalıştığını, gerçek dünya senaryolarında nasıl kullanılabileceğini ve sınırlılıklarını tüm teknik detaylarıyla ele alacağız.
1. OPPO Nedir? Hangi Problemi Çözüyor?
Parameter Sniffing Nedir?
SQL Server’da parametreli bir sorgu ilk kez çalıştırıldığında, sorgunun aldığı parametre değerine göre bir yürütme planı oluşturulur ve bu plan önbelleğe alınır. Problem şudur ki: aynı sorgu daha sonra farklı bir parametre değeriyle çalıştırılsa bile, ilk oluşturulan plan tekrar kullanılacaktır.
Bu durum bazı veri dağılımlarında felaketle sonuçlanabilir. Örneğin, ilk sorguda az satır dönen bir filtreleme varsa seek planı, sonrakinde çok geniş bir dağılım varsa scan planı gerekirken, SQL Server buna adapte olamaz. Bu problem, “parameter sniffing” olarak adlandırılır.
PSPO Ne Yaptı?
SQL Server 2022’de gelen PSPO, bu sorunu çözmek için ilk adımdı. PSPO, belirli bir parametrenin değer aralığına göre üç farklı plan varyantı oluşturabiliyordu (small, medium, large). Ancak PSPO sadece tek parametre üzerinde çalışan ve deterministik dağılımı olan sorgular için işe yarıyordu.
Peki Ya Opsiyonel Parametreler?
Şimdi düşünün: bir saklı yordamda 4-5 adet @param IS NULL OR column = @param şeklinde yazılmış koşullar var. Kullanıcı bazen @city, bazen @age, bazen hiç parametre göndermiyor. SQL Server hangisi için plan hazırlayacak?
Cevap: hiçbiri için doğru plan hazırlamıyor. Çünkü klasik planlama mantığı bu sorgulara “herkese uyan tek plan” yapar. Sonuç?
- Beklenmedik derecede yavaş sorgular
- Geciken raporlar
- Yüksek CPU ve I/O
OPPO’nun Getirdiği Yenilik
Optional Parameter Plan Optimization (OPPO), sorgunun çalışma zamanında parametrenin NULL olup olmadığını kontrol eder ve buna göre iki ayrı execution plan üretir:
- Parametre NULL ise → scan odaklı geniş plan
- Parametre NULL değilse → seek veya dar filtre odaklı plan
Bu planlar QueryVariantID ile işaretlenir ve execution sırasında dispatcher denen mekanizma doğru planı seçer.
OPPO, bu haliyle özellikle tek opsiyonel parametreye sahip sorgularda büyük performans kazancı sağlar. SQL Server, her iki ihtimali de bellekte tutarak her çalıştırmada doğru planı devreye alabilir.
2. OPPO’nun Çalışma Mantığı
OPPO’nun başarısının temelinde, SQL Server’ın parametrenin NULL olup olmadığını çalışma zamanında kontrol edebilmesi yatar. Bu kontrol sonucunda SQL Server, iki ayrı execution plan üretir ve bu planları koşullara göre yürütür.
optional_predicate Nedir?
SQL Server 2025 ile birlikte execution plan’larda yeni bir ifade görmeye başlıyoruz: optional_predicate. Bu ifade, planın opsiyonel bir parametre için optimize edildiğini ve plan varyantlarının çalışma zamanında seçileceğini gösterir.
Bu yapı, özellikle aşağıdaki gibi yazılmış sorgularda aktif hale gelir:
SELECT* FROMProducts WHERE(@CategoryId ISNULLORCategoryId = @CategoryId);
Bu örnekte, @CategoryId opsiyonel bir parametredir. Kullanıcı bu parametreyi göndermeyebilir (NULL bırakabilir). OPPO, bu sorgu için iki farklı yürütme planı oluşturur:
- Plan 1: @CategoryId IS NULL → geniş tarama planı (SCAN)
- Plan 2: @CategoryId = X → dar filtreleme planı (SEEK)
QueryVariantID ve Dispatcher
OPPO’nun önemli parçalarından biri olan QueryVariantID, SQL Server’ın aynı sorgu için farklı plan varyantlarını oluşturmasına ve ayırt etmesine imkân tanır. Her plan varyantı, farklı koşullara karşılık gelen yürütme senaryosunu temsil eder.
Dispatcher ise çalışma zamanında, parametrenin değerine bakarak uygun planı seçmekle görevlidir. Bu, aşağıdaki gibi işler:
- @param IS NULL → QueryVariantID = 1
- @param IS NOT NULL → QueryVariantID = 2
Dispatcher bu ayrımı yürütürken, parametrelerin dağılımına göre plan önbelleğiyle birlikte çalışır. Bu sayede plan yeniden derlenmeden en uygun olan çağrılır.
ShowPlan XML ile OPPO’nun İzlenmesi
Execution Plan analiz araçlarında (SSMS, Azure Data Studio, Plan Explorer vb.) OPPO’yu izleyebilmek için ShowPlan XML verilerine bakmak gerekir. Burada şu yapılar görülür:
- optional_predicate(…)
- QueryVariantID=…
- Plan varyantları için ilgili dağılım bilgileri
Bu alanlar, sorgunun gerçekten OPPO ile çalışıp çalışmadığını, hangi varyantın devreye alındığını ve ne tür bir plan üretildiğini görmemizi sağlar.
Plan Cache Davranışı
OPPO, OPTION(RECOMPILE) gibi planı her seferinde baştan üretmez. Bunun yerine, Multiplan cache yapısını kullanarak birden fazla planı bellekte tutar ve dispatcher aracılığıyla uygun olanı çağırır. Bu, plan önbelleğinin daha verimli çalışmasını sağlar.
3. OPPO’nun Uygulama Senaryoları
OPPO’nun getirdiği plan varyasyonu yaklaşımı, belirli senaryolarda ciddi performans artışı sağlayabilir. Ancak tüm sorgular için eşit düzeyde etkili değildir. Bu bölümde, OPPO’nun en başarılı olduğu senaryoları ve sınırlı kaldığı durumları inceleyeceğiz.
3.1 Tek Opsiyonel Parametreli Sorgular
OPPO’nun en verimli çalıştığı senaryo, tek bir opsiyonel parametreye sahip T-SQL sorgularıdır. Örnek bir yapı şu şekilde olabilir:
SELECT* FROMPropertiesWHERE@bedrooms ISNULLORbedrooms = @bedrooms;
Bu sorguda kullanıcı @bedrooms parametresi gönderirse, OPPO bunu bir arama (seek) planı ile çalıştırır. Göndermezse (NULL ise), sistem bir tablo taraması (scan) planı uygular. Böylece her iki durumda da uygun plan varyantı kullanılır.
Faydalar:
- Plan yeniden derlenmeden çalışma zamanında doğru seçim yapılır.
- OPTION(RECOMPILE) kullanımına kıyasla CPU maliyeti azalır.
- Plan önbelleği daha etkili kullanılır.
3.2 Birden Fazla Opsiyonel Parametreli Sorgular
Gerçek dünyada birçok sorgu birden fazla opsiyonel parametre içerir. Örneğin:
SELECT* FROMUsersWHERE(@age ISNULLORage = @age)AND(@city ISNULLORcity = @city)AND(@isActive ISNULLORisActive = @isActive);
Bu gibi “kitchen sink” tarzı prosedürlerde kullanıcı farklı kombinasyonlarda parametre gönderir. Ne yazık ki, OPPO şu an için sadece tek bir opsiyonel parametreyi yönetebiliyor. Bu nedenle yukarıdaki sorgu yapısında OPPO’nun etkinliği sınırlıdır.
Sonuç:
- OPPO bu yapıya sadece tek opsiyonel parametre olduğu sürece katkı sağlar.
- Birden fazla opsiyonel parametrede plan sayısı artmadığı için bazı koşullar yine suboptimal planlarla çalışabilir.
- Bu durumlarda OPTION(RECOMPILE) veya dinamik SQL hâlâ güçlü alternatiflerdir.
3.3 Kitchen Sink Prosedürlerde OPPO Kullanımı
Birçok uygulama, raporlama ekranları için çok sayıda opsiyonel filtre parametresi alabilen prosedürler barındırır. Örneğin:
CREATEPROCEDUREGetOrders@customerId INT= NULL,@status NVARCHAR(10) = NULL,@startDate DATE= NULL,@endDate DATE= NULLASBEGINSELECT* FROMOrdersWHERE(@customerId ISNULLORcustomerId = @customerId)AND(@status ISNULLORstatus = @status)AND(@startDate ISNULLORorderDate >= @startDate)AND(@endDate ISNULLORorderDate <= @endDate);END;
Bu tür prosedürler çok yönlüdür fakat plan üretiminde çok fazla belirsizlik barındırır. OPPO’nun tek parametre odaklı mimarisi, bu senaryolarda sınırlı kalır. Ancak en sık kullanılan opsiyonel parametreyi öne çıkararak bu yapıdan yine faydalanmak mümkündür.
4. OPPO ve PSPO: Farklar ve Birlikte Kullanım
SQL Server 2025, sorgu optimizasyon stratejilerini daha akıllı ve veri duyarlı hale getirmek için hem PSPO (Parameter Sensitive Plan Optimization) hem de OPPO (Optional Parameter Plan Optimization) özelliklerini birlikte sunuyor. Bu iki teknoloji, farklı ihtiyaçlara hitap eder ve birlikte kullanıldıklarında daha esnek plan üretimi sağlarlar.
PSPO ve OPPO’nun Temel Farkları
Nasıl Birlikte Çalışırlar?
PSPO ve OPPO aynı anda devrede olabilir. Örneğin, bir sorguda hem parametre değeri dağılımı yüksek (PSPO adayı), hem de opsiyonel parametre varsa (OPPO adayı), SQL Server bu sorgu için birden fazla varyantı birlikte üretir.SELECT* FROMSalesWHERE(@region ISNULLORregion = @region)ANDquantity > @minQty;
Bu örnekte:
- @region parametresi OPPO için uygundur.
- @minQty parametresi PSPO için uygundur.
SQL Server, bu iki optimizasyon için birbirinden bağımsız plan varyantları oluşturur. Bu planlar ShowPlan XML’de QueryVariantID ve ilgili predicate’lerle izlenebilir.
İzleme ve Teşhis
Her iki özelliğin neden devreye girip girmediğini kontrol etmek için parameter_sensitive_plan_optimization_skipped_reason gibi DMV’ler veya Showplan analizleri kullanılabilir.SELECT* FROMsys.query_store_plan WHEREparameter_sensitive_plan_optimization_skipped_reason ISNOTNULL;
Bu sorgu sayesinde, PSPO veya OPPO’nun neden aktifleşmediğini görebilirsiniz.
Performans Etkisi
PSPO ve OPPO birlikte kullanıldığında, sorgu başına daha fazla plan varyantı üretilebilir. Bu da plan cache üzerinde daha fazla yer kaplamasına neden olabilir. Ancak bu değişimin en büyük artısı, sorgu davranışının çalışma zamanında çok daha iyi ayarlanabilmesidir.
5. OPPO’nun Alternatifleri
OPPO, SQL Server 2025’te parametre sniffing sorunlarını çözmek için geliştirilen güçlü bir araç olsa da, hâlâ tek opsiyonel parametreyle sınırlı yapısı nedeniyle bazı durumlarda geleneksel yöntemlerle birlikte kullanılmaya devam ediliyor. Bu bölümde OPPO’nun alternatiflerini karşılaştırmalı olarak inceleyeceğiz.
5.1 OPTION(RECOMPILE)
OPTION(RECOMPILE) ipucu, her sorgu çalıştırıldığında planın yeniden derlenmesini sağlar. Bu yaklaşımda parametre değeri ne olursa olsun, her çalıştırma için özel olarak optimize edilmiş bir plan oluşturulur.
Avantajları:
- Her koşulda en uygun plan elde edilir.
- Karmaşık sorgularda bile geçerli sonuçlar üretir.
Dezavantajları:
- Plan yeniden derlendiği için CPU yükü artar.
- Plan cache kullanımı yoktur, sık çalıştırılan sorgularda pahalıdır.
SELECT* FROMProductsWHERE(@brand ISNULLORbrand = @brand)OPTION(RECOMPILE);
5.2 OPTION(OPTIMIZE FOR UNKNOWN)
Bu ipucu, SQL Server’a sorgunun optimize edilirken parametre değerini dikkate almamasını söyler. Bunun yerine istatistik histogramının ortanca değeri gibi genel dağılımlar kullanılarak plan oluşturulur.
Avantajları:
- Plan cache kullanılır.
- Plan tekrar kullanılabilir; daha az CPU yükü oluşturur.
Dezavantajları:
- Plan genellikle ortalama bir duruma göre optimize edilir, spesifik durumlar için kötü çalışabilir.
SELECT* FROMOrdersWHEREcustomerId =@customerIdOPTION(OPTIMIZE FORUNKNOWN);
5.3 Dinamik SQL
Dinamik SQL, sorgunun çalıştırılmadan önce ihtiyaca göre oluşturulması yöntemidir. Bu yöntem, yalnızca kullanılan parametreleri sorguya dahil ederek en küçük ve en etkili planın oluşturulmasını sağlar.
Avantajları:
- Kullanılan filtreye göre sorgu özelleştirilebilir.
- Daha küçük planlar ve daha iyi I/O performansı sağlanabilir.
Dezavantajları:
- Kod karmaşıklaşır, bakım zorluğu artar.
- SQL injection gibi güvenlik riskleri barındırabilir.
DECLARE@sql NVARCHAR(MAX) = 'SELECT * FROM Products WHERE 1=1';IF @categoryId ISNOTNULLSET@sql += ' AND categoryId = @categoryId';EXECsp_executesql @sql, N'@categoryId INT', @categoryId;
Özet Karşılaştırma Tablosu
6. OPPO’nun Sınırlamaları ve Gelecekteki Gelişim Potansiyeli
SQL Server 2025 ile hayatımıza giren OPPO, parametre sniffing sorunları için önemli bir iyileştirme sunmasına rağmen, henüz olgun bir çözüm değildir. Bu bölümde OPPO’nun mevcut sınırlamalarını ve Microsoft’un bu özelliği nasıl geliştirebileceğine dair beklentileri ele alacağız.
6.1 Mevcut Sınırlamalar
🔹 Yalnızca Tek Opsiyonel Parametreye Destek
OPPO’nun en büyük kısıtlaması, şu anda yalnızca tek bir opsiyonel parametre içeren sorgular için aktif olarak çalışabilmesidir. Gerçek dünyadaki birçok “mutfak lavabosu” prosedür, birden fazla opsiyonel parametre içerdiğinden, OPPO bu senaryolarda yeterince esnek değildir.
🔹 Plan Varyant Sayısının Sınırlı Olması
OPPO, her sorgu için yalnızca iki plan varyantı üretmektedir: biri parametre IS NULL, diğeri parametre IS NOT NULL için. Bu, daha fazla varyant ihtiyacı olan durumlarda sınırlayıcı olabilir.
🔹 Dispatcher Mantığının Sorguya Göre Değişmesi
İlk çalıştırılan sorguda hangi parametrenin kullanıldığına göre dispatcher mantığı şekillenir. Bu da farklı senaryolarda beklenmeyen plan seçimlerine neden olabilir.
🔹 QueryVariantID Yeniden Kullanım Davranışı
Bazı senaryolarda, OPPO daha önce oluşturulmuş plan varyantlarını yeniden kullanmayı tercih eder. Bu da aslında eski, artık optimal olmayan planların tekrar yürütülmesine neden olabilir.
6.2 Gelecekteki Gelişim Potansiyeli
Microsoft’un geçmişten gelen geliştirme stratejisine bakıldığında (örneğin: Adaptive Memory Grants, PSPO), OPPO’nun da zamanla daha kapsamlı hale geleceği öngörülebilir.
Beklenen Geliştirmeler:
- Çoklu Opsiyonel Parametre Desteği: OPPO’nun aynı anda birden fazla opsiyonel parametre için varyant üretebilmesi bekleniyor.
- Plan Varyantı Sayısında Artış: IS NULL, IS NOT NULL, DEFAULT gibi durumlara göre 2’den fazla plan varyantı oluşturulması hedeflenebilir.
- Query Store ile Daha İyi Entegrasyon: OPPO’ya özel performans metriklerinin Query Store üzerinden daha detaylı izlenebilmesi bekleniyor.
- Intelligent Query Processing ile Bütünleşme: OPPO’nun IQP ailesinin tam bir üyesi haline gelmesi ile birlikte, diğer özelliklerle (PSPO, AMGS) entegre çalışması sağlanabilir.
6.3 DBA ve Geliştiricilere Öneriler
- Şu an için OPPO’yu tek opsiyonel parametreli sorgularda aktif olarak değerlendirin.
- Karmaşık senaryolarda hâlâ OPTION(RECOMPILE) ve dinamik SQL gibi geleneksel çözümleri göz ardı etmeyin.
- OPPO’nun devreye girip girmediğini Showplan veya DMV’ler ile mutlaka izleyin.
- SQL Server 2028 ve sonrası için bu özelliğin daha güçlü hale gelmesini bekleyin; mimariyi şimdiden buna göre esnek kurgulayın.
7. Gerçek Dünya Senaryosu: OPPO ile Öncesi/Sonrası
OPPO’nun potansiyelini tam olarak anlayabilmek için teorik açıklamaların ötesine geçip gerçek dünya örneklerine bakmak gerekir. Bu bölümde, sık karşılaşılan bir sorgulama senaryosu üzerinden OPPO’nun ne tür farklar yarattığını inceleyeceğiz.
7.1 Senaryo Tanımı
Bir emlak portalında kullanıcılar, farklı kriterlere göre ilan araması yapabilmektedir. Uygulamada kullanılan prosedür aşağıdaki gibidir:
CREATEPROCEDURESearchProperties@bedrooms INT= NULLASBEGINSELECT* FROMPropertiesWHERE(@bedrooms ISNULLORbedrooms = @bedrooms);END;
Bu prosedürde @bedrooms parametresi opsiyoneldir. Kullanıcı filtre kullanmadığında tüm ilanlar listelenir (SCAN), filtre kullanıldığında ise yalnızca belirli yatak odası sayısına göre sonuç getirilir (SEEK).
7.2 OPPO Öncesi Durum
SQL Server, bu prosedürü ilk hangi parametre ile çalıştırdıysa ona göre bir plan üretir. Örneğin:
- İlk çağrıda @bedrooms = 3 ise → Seek plan oluşturulur.
- Sonraki çağrıda @bedrooms = NULL → Aynı Seek plan çalıştırılır ama çok sayıda satır taranır.
- Bu da parameter sniffing problemine neden olur.
Ölçülen Performans (örnek):
| Durum | CPU (ms) | I/O (Reads) | Süre (ms) |
|---|---|---|---|
| İlk çalıştırma (3) | 30 | 800 | 45 |
| Sonraki çalıştırma (NULL) | 3100 | 280.000 | 2900 |
7.3 OPPO Sonrası Durum
SQL Server 2025 OPPO aktif olduğunda, aynı sorgu için iki plan varyantı oluşturulur:
- @bedrooms IS NULL → SCAN planı
- @bedrooms = X → SEEK planı
Dispatcher, çalışma zamanında doğru planı çağırır.
Ölçülen Performans (örnek):
| Durum | CPU (ms) | I/O (Reads) | Süre (ms) |
|---|---|---|---|
| İlk çalıştırma (3) | 30 | 800 | 42 |
| Sonraki çalıştırma (NULL) | 65 | 6.500 | 70 |
7.4 Gözlemler
- Plan değişikliği manuel RECOMPILE olmadan otomatik olarak yapılmıştır.
- CPU ve I/O tüketimi büyük ölçüde azalmıştır.
- Kullanıcı deneyimi iyileşmiş, işlem süreleri dramatik şekilde düşmüştür.
- Query Store üzerinde iki ayrı QueryVariantID ile planlar izlenebilir.
8. SSS – Sıkça Sorulan Sorular
S1: OPPO nedir ve PSPO’dan farkı nedir?
OPPO (Optional Parameter Plan Optimization), SQL Server 2025’te tanıtılan bir sorgu optimizasyon teknolojisidir. Opsiyonel (nullable) parametreler için birden fazla plan varyantı oluşturur.
PSPO ise SQL Server 2022’de tanıtılmıştır ve parametre değer dağılımına göre plan varyantları üretir. PSPO değer aralığına bakarken, OPPO parametrenin NULL olup olmadığına odaklanır.
S2: OPPO şu anda hangi sınırlamalara sahiptir?
- Yalnızca tek opsiyonel parametre destekleniyor.
- Her sorgu için sadece iki plan varyantı üretilebiliyor.
- Dispatcher mantığı, sorgunun ilk çalıştırılışına bağlı olarak değişebiliyor.
- Plan varyantları bazen beklenmedik şekilde yeniden kullanılabiliyor.
S3: OPPO ile OPTION(RECOMPILE) birlikte kullanılmalı mı?
Genellikle gerekmez. OPPO, çalışma zamanında uygun planı seçtiği için OPTION(RECOMPILE) ihtiyacını ortadan kaldırır. Ancak OPPO’nun devreye girmediği karmaşık durumlarda OPTION(RECOMPILE) hâlâ geçerli bir alternatiftir.
S4: OPPO’yu nasıl izleyebilirim?
Execution plan’larda optional_predicate(…) ifadelerini arayarak OPPO’nun aktif olup olmadığını görebilirsiniz. Ayrıca Query Store’daki QueryVariantID bilgisiyle de hangi planların OPPO ile üretildiğini anlayabilirsiniz.
SELECT* FROMsys.query_store_plan WHEREquery_variant_id ISNOTNULL;
S5: OPPO ile dinamik SQL arasında ne fark var?
OPPO, SQL Server’ın kendi başına plan varyantlarını çalışma zamanında seçmesini sağlar.
Dinamik SQL ise geliştiricinin sorguyu koşula göre oluşturmasını gerektirir.
Dinamik SQL daha esnektir ama daha karmaşık ve hata/iş yüküne açıktır. OPPO daha sade ve yönetilebilir bir yaklaşımdır.
S6: OPPO gelecekte daha gelişmiş hale gelecek mi?
Evet. Microsoft’un geçmişteki geliştirme trendlerine göre, OPPO’nun:
- Çoklu opsiyonel parametre desteği,
- Daha fazla varyant üretimi,
- Daha iyi Query Store entegrasyonu gibi yönlerden gelişeceği öngörülmektedir.
9. Kaynakça
Bu yazıda sunulan bilgiler, Microsoft’un resmi dokümantasyonları, uzman blog yazıları ve topluluk kaynakları referans alınarak derlenmiştir. OPPO’nun teknik detayları, sınırları ve kullanım senaryoları, SQL Server 2025 Public Preview sürümünde yapılan testlere ve mevcut literatüre dayanmaktadır.
🔗 Resmi Microsoft Dokümantasyonları
- Optional Parameter Plan Optimization (MS Docs)
- Intelligent Query Processing – Overview
- Parameter Sensitive Plan Optimization (PSPO)
Topluluk ve Uzman Kaynakları
- Brent Ozar – How SQL Server 2025’s Optional Parameter Plan Optimization Works
- MSSQLTips – Understanding OPPO and PSPO
- Stack Overflow – OPTION(OPTIMIZE FOR UNKNOWN) vs OPTION(RECOMPILE)
- DBA StackExchange – With Recompile vs Cached Plans
Test ve Demo Ortamı
- SQL Server 2025 CTP 2.1 Public Preview
- Test ortamı: Azure SQL VM – Windows Server 2022 + SSMS 19
- Showplan XML ve Query Store analizi ile yapılan performans ölçümleri
Yazı boyunca kullanılan örnek sorgular, performans karşılaştırma tabloları ve execution plan analizleri bu kaynakların ışığında hazırlanmıştır.
