Aracılığıyla paylaş

Akıllı sorgu işleme özellikleri ayrıntılı olarak

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen ÖrneğiMicrosoft Fabric'te SQL veritabanı

Bu makalede çeşitli akıllı sorgu işleme (IQP) özellikleri, sürüm notları ve daha ayrıntılı açıklamalar yer alır. Akıllı sorgu işleme (IQP) özellik ailesi, benimsemek için en az uygulama çabasıyla mevcut iş yüklerinin performansını geliştiren geniş kapsamlı etkiye sahip özellikler içerir.

Veritabanı için geçerli veritabanı uyumluluk düzeyini etkinleştirerek iş yüklerini akıllı sorgu işleme için otomatik olarak uygun hale getirebilirsiniz. Transact-SQL kullanarak bunu ayarlayabilirsiniz. Örneğin, veritabanının uyumluluk düzeyini SQL Server 2022 (16.x) olarak ayarlamak için:

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

Yeni sürümlerle sunulan değişiklikler hakkında daha fazla bilgi için bkz:

Batch modu Uyarlamalı Birleşimler

Şunlar için geçerlidir: SQL Server (SQL Server 2017 (14.x) ile başlayarak), Azure SQL Veritabanı

Toplu iş modu Uyarlamalı Birleştirmeler özelliği, tek bir önbelleğe alınmış plan kullanılarak ilk giriş tarandıktan sonraKarma Birleştirme veya İç İçe Döngü Birleştirmesi yönteminin seçiminin ertelenebilmesine olanak tanır. Uyarlamalı Birleştirme işleci, İç İçe Döngüler planına ne zaman geçeceğine karar vermek için kullanılan bir eşik tanımlar. Bu nedenle planınız yürütme sırasında dinamik olarak daha iyi bir birleştirme stratejisine geçebilir.

Uyumluluk düzeyini değiştirmeden Uyarlamalı birleştirmeleri devre dışı bırakma da dahil olmak üzere daha fazla bilgi için bkz. Uyarlamalı birleştirmeleri anlama.

MSTVF'ler için araya eklemeli yürütme

Şunlar için geçerlidir: SQL Server (SQL Server 2017 (14.x) ile başlayarak), Azure SQL Veritabanı

Çok deyimli tablo değerli işlev (MSTVF), parametreleri kabul eden, birden çok T-SQL deyimini ve RETURN tabloyu yürütebilen kullanıcı tanımlı bir işlev türüdür.

Aralıklı yürütme, MSTVF'lerle ilişkili sabit kardinalite tahminlerinden kaynaklanan iş yükü performans sorunlarını iyileştirmeye yardımcı olur. Araya eklemeli yürütme ile işlevdeki gerçek satır sayıları, daha iyi bilgilendirilmiş aşağı akış sorgu planı kararları almak için kullanılır.

MSTVF'ler, SQL Server 2014 (12.x) ile birlikte 100 ve daha önceki SQL Server sürümleri için 1 olan sabit bir kardinalite tahmini kullanır.

İç içe geçmiş yürütme, tek sorgulu yürütme için iyileştirme ve yürütme aşamaları arasındaki tek yönlü sınırı değiştirir ve planların düzeltilmiş kardinalite tahminlerine göre uyum sağlamasına olanak tanır. Veritabanı motoru, iç içe geçmiş yürütme adayı olarak çok deyimli tablo değerli işlevler (MSTVFs) kullanan bir durumla karşılaştığında iyileştirme duraklatılır, ilgili alt ağacı yürütür, doğru kardinalite tahminlerini elde eder ve ardından sonraki işlemler için iyileştirmeye devam eder.

Aşağıdaki görüntüde, MSTVF'lerden sabit kardinalite tahminlerinin etkisini gösteren bir genel yürütme planının alt kümesi olan Canlı Sorgu İstatistikleri çıkışı gösterilmektedir

Gerçek satır akışını ve tahmini satırları görebilirsiniz. Planın üç önemli alanı vardır (akış sağdan soladır):

  • MSTVF Tablo Taraması'nın sabit tahmini 100 satırdır. Ancak bu örnekte, Canlı Sorgu İstatistikleri'nde 527597'den 100 gerçek tahminin görüldüğü gibi, bu MSTVF Tablo Taramasında 527.597 satır akıyor; bu nedenle sabit tahmin önemli ölçüde dengesizdir.
  • İç İçe Döngüler işlemi için birleştirmenin dış tarafı tarafından yalnızca 100 satırın döndürüldiği varsayılır. MSTVF tarafından gerçekten döndürülen çok sayıda satırı dikkate alarak, farklı bir birleştirme algoritması kullanmanın daha iyi bir seçenek olabileceğini düşünebilirsiniz.
  • Karma Eşleştirme işlemi için, bu örnekte diske taşma olduğunu gösteren küçük uyarı simgesine dikkat edin.

Yürütme planı satır akışının tahmini satırlara göre diyagramı.

Önceki planı, arasıra yürütme etkinleştirildiğinde oluşturulan gerçek planla karşılaştırın.

İç içe geçmiş yürütme planının diyagramı.

  • MSTVF tablo taraması artık doğru bir kardinalite tahminini yansıtır. Ayrıca bu tablo taramasının ve diğer işlemlerin yeniden sıralı olduğunu da fark edin.
  • Birleştirme algoritmalarıyla ilgili olarak, İç İçe Döngü işleminden Karma Eşleştirme işlemine geçtik. Bu işlem, çok sayıda satır söz konusu olduğunda daha uygun olur.
  • Ayrıca MSTVF tablo taramasından akan gerçek satır sayısına göre daha fazla bellek sağladığımız için artık taşma uyarıları almadığımıza da dikkat edin.

İç içe geçmiş yürütme uygun komutlar

Şu anda ara yürütmede yer alan MSTVF başvuru deyimleri, salt okunur olmalı ve bir veri değiştirme işleminin parçası olmamalıdır. Ayrıca, çalışma zamanı sabitlerini kullanmazlarsa MSTVF'ler araya eklemeli yürütme için uygun değildir.

Araya kaydedilen yürütme avantajları

Genel olarak, tahmini ve gerçek satır sayısı arasındaki eğrilik ne kadar yüksekse, aşağı akış planı işlemlerinin sayısıyla birlikte performans etkisi o kadar yüksek olur.

Genel olarak, iç içe yürütme aşağıdaki durumlarda sorgulara fayda sağlar:

  • Ara sonuç kümesi (bu örnekte MSTVF) için tahmini ve gerçek satır sayısı arasında büyük bir dengesizlik vardır.

  • Genel sorgu da ara sonucun boyutundaki bir değişikliğe duyarlıdır. Bu durum genellikle sorgu planında bu alt ağacın üzerinde karmaşık bir ağaç olduğunda gerçekleşir.

    MSTVF'den alınan temel SELECT * bilgiler, araya kaydedilen yürütmeden yararlanmaz.

Parçalı yürütme ek yükü

Ek yük en az yok olmalıdır. ARAli yürütme kullanılmadan önce MSTVF'ler zaten gerçeklestiriliyordu, ancak fark, şimdi ertelenmiş iyileştirmeye izin vermemiz ve sonra gerçekleştirilmiş satır kümesinin kardinalite tahminini kullanmamızdır. Değişiklikleri etkileyen tüm planlarda olduğu gibi, bazı planlar da alt ağaç için daha iyi kardinaliteyle sorgu için genel olarak daha kötü bir plan elde edebilecek şekilde değişebilir. Risk azaltma, uyumluluk düzeyini geri almayı veya planın performans gerilemesi olmayan sürümünü zorlamak için Sorgu Deposu'nun kullanılmasını içerebilir.

Çapraz yürütme ve ardışık yürütmeler

Kesik bir yürütme planı önbelleğe alındıktan sonra, ilk yürütmedeki düzeltilmiş tahminlerle birlikte plan, ardışık yürütmeler için kesik yürütmeyi yeniden başlatmadan kullanılır.

Birbirine geçmiş yürütme etkinliğini izleme

Gerçek sorgu yürütme planında kullanım özniteliklerini görebilirsiniz:

Yürütme Planı özniteliği Description
ContainsInterleavedExecutionCandidates QueryPlan düğümü için geçerlidir. True olduğunda, planın karmaşık yürütme adaylarını içerdiği anlamına gelir.
IsInterleavedExecuted TVF düğümü için RelOp altındaki RuntimeInformation öğesinin özniteliği. True olduğunda, işlemin araya katılmış bir yürütme işleminin parçası olarak gerçekleştirildiği anlamına gelir.

Ayrıca, aşağıdaki genişletilmiş olaylar aracılığıyla araya kaydedilen yürütme oluşumlarını da izleyebilirsiniz:

XEvent Description
interleaved_exec_status Bu olay, iç içe geçmiş yürütme gerçekleştiğinde tetiklenir.
interleaved_exec_stats_update Bu olay, araya kaydedilen yürütme tarafından güncelleştirilen kardinalite tahminlerini açıklar.
Interleaved_exec_disabled_reason Bu olay, iç içe yürütme için olası bir aday içeren bir sorgu gerçekte iç içe yürütme almadığında tetiklenir.

MSTVF kardinalite tahminlerini gözden geçirmek amacıyla iç içe yürütmeye izin vermek için bir sorgu yürütülmelidir. Ancak, tahmini yürütme planı yine de showplan özniteliği aracılığıyla ContainsInterleavedExecutionCandidates araya katılmış yürütme adayları olduğunda gösterilir.

İç içe geçmiş yürütme önbelleğe alma

Bir plan silinir veya önbellekten çıkartılırsa, sorgu yürütüldüğünde iç içe geçmiş yürütmeyi kullanan yeni bir derleme olur. kullanan OPTION (RECOMPILE) bir deyim, önbelleğe alma yerine araya eklenen yürütmeyi kullanarak yeni bir plan oluşturur.

İç içe geçmiş yürütme ve Sorgu Deposu interoperabilitesi

Araya serpiştirilmiş yürütme kullanan planlar zorlanabilir. Plan, ilk yürütmeye göre kardinalite tahminlerini düzelten sürümdür.

Uyumluluk düzeyini değiştirmeden iç içe geçmiş yürütmeyi devre dışı bırakma

Veritabanı uyumluluk düzeyi 140 ve üzeri korunurken, veritabanı veya deyim kapsamında araya katılmış yürütme devre dışı bırakılabilir. Veritabanından kaynaklanan tüm sorgu yürütmelerinde ara sıra yürütmeyi devre dışı bırakmak için, geçerli veritabanı bağlamında aşağıdakileri yürütün:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Etkinleştirildiğinde, bu ayar sys.database_scoped_configurations etkin olarak görünür. Veritabanından kaynaklanan tüm sorgu yürütmeleri için araya kaydedilen yürütmeyi yeniden etkinleştirmek için, geçerli veritabanı bağlamında aşağıdakileri yürütün:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

DISABLE_INTERLEAVED_EXECUTION_TVF belirli bir sorgu için iç içe yürütmeyi devre dışı bırakmak için USE HINT sorgu ipucu olarak belirleyebilirsiniz. Örneğin:

SELECT [fo].[Order Key],
       [fo].[Quantity],
       [fol].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
     INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession', '1-01-2013', '10-15-2014') AS [fol]
         ON [fo].[Order Key] = [fol].[Order Key]
        AND [fo].[City Key] = [fol].[City Key]
        AND [fo].[Customer Key] = [fol].[Customer Key]
        AND [fo].[Stock Item Key] = [fol].[Stock Item Key]
        AND [fo].[Order Date Key] = [fol].[Order Date Key]
        AND [fo].[Picked Date Key] = [fol].[Picked Date Key]
        AND [fo].[Salesperson Key] = [fol].[Salesperson Key]
        AND [fo].[Picker Key] = [fol].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

USE HINT sorgu ipucu, veritabanı kapsamlı yapılandırma veya izleme bayrağı ayarının önüne geçer.

Skaler UDF satır içi yerleştirme

Şunlar için geçerlidir: SQL Server (SQL Server 2019 (15.x) ile başlayarak), Azure SQL Veritabanı

Skaler UDF inlining, skaler UDF'leri otomatik olarak ilişkisel ifadelere dönüştürür. Bunları çağıran SQL sorgusuna ekler. Bu dönüşüm, skaler UDF'lerden yararlanan iş yüklerinin performansını artırır. Skaler UDF inlining, UDF'ler içindeki işlemlerin maliyet tabanlı iyileştirmesini kolaylaştırır. Sonuçlar verimsiz, yinelemeli, seri yürütme planları yerine verimli, ayar odaklı ve paraleldir. Bu özellik, veritabanı uyumluluk düzeyi 150 veya üzeri altında varsayılan olarak etkindir.

Daha fazla bilgi için bkz . Scalar UDF inlining.

Tablo değişkeni ertelenen derleme

Şunlar için geçerlidir: SQL Server (SQL Server 2019 (15.x) ile başlayarak), Azure SQL Veritabanı

Tablo değişkeni ertelenen derleme, tablo değişkenlerine başvuran sorgular için plan kalitesini ve genel performansı artırır. İyileştirme ve ilk plan derlemesi sırasında, bu özellik, gerçek tablo değişkeni satır sayılarını baz alarak, kardinalite tahminlerini aktarır. Bu tam satır sayısı bilgileri daha sonra aşağı akış planı işlemlerini iyileştirmek için kullanılır.

Tablo değişkeninin ertelenmiş derlemesi ile, tablo değişkenine başvuran bir deyimin derlenmesi, deyimin ilk gerçek yürütülmesine kadar ertelenir. Bu ertelenen derleme davranışı, geçici tabloların davranışıyla aynıdır. Bu değişiklik, özgün tek satırlık tahmin yerine gerçek kardinalitenin kullanılmasına neden olur.

Tablo değişkeni ertelenmiş derlemesini etkinleştirmek için, sorgu çalıştırıldığında bağlandığınız veritabanı için veritabanı uyumluluk düzeyi 150 veya üzerini etkinleştirin.

Tablo değişkeni ertelenen derleme, tablo değişkenlerinin diğer özelliklerini değiştirmez . Örneğin, bu özellik tablo değişkenlerine sütun istatistikleri eklemez.

Tablo değişkeni ertelenen derleme , yeniden derleme sıklığını artırmaz. Bunun yerine, ilk derlemenin gerçekleştiği yeri değiştirir. Sonuçta elde edilen önbelleğe alınmış plan, ilk ertelenmiş derleme tablosu değişken satır sayısına göre oluşturur. Önbelleğe alınan plan ardışık sorgular tarafından yeniden kullanılır. Plan çıkarılana veya yeniden derlenene kadar kullanılmaya devam edilir.

İlk plan derlemesi için kullanılan tablo değişkeni satır sayısı, normal bir değeri temsil eder, sabit satır sayısı tahmininden farklı olabilir. Eğer farklıysa, aşağı akış işlemleri avantaj sağlar. Tablo değişkeni satır sayısı yürütmeler arasında önemli ölçüde değişiyorsa, performans bu özellik tarafından iyileştirilmeyebilir.

Uyumluluk düzeyini değiştirmeden tablo değişkeni ertelenen derlemeyi devre dışı bırakma

Veritabanı uyumluluk düzeyi 150 ve üzerini korurken, veritabanı veya sorgu düzeyinde tablo değişkeni ertelenen derlemeyi devre dışı bırakın. Veritabanından kaynaklanan tüm sorgu yürütmeleri için tablo değişkeni ertelenen derlemeyi devre dışı bırakmak için, geçerli veritabanı bağlamında aşağıdaki örneği yürütün:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Veritabanından kaynaklanan tüm sorgu yürütmeleri için tablo değişkeni ertelenen derlemeyi yeniden etkinleştirmek için, geçerli veritabanı bağlamında aşağıdaki örneği yürütün:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

DISABLE_DEFERRED_COMPILATION_TV USE HINT sorgu ipucu olarak atayarak belirli bir sorgu için tablo değişkeni ertelenen derlemeyi de devre dışı bırakabilirsiniz. Örneğin:

DECLARE @LINEITEMS TABLE (
    L_OrderKey INT NOT NULL,
    L_Quantity INT NOT NULL);

INSERT @LINEITEMS
SELECT L_OrderKey,
       L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
       O_CustKey,
       O_OrderStatus,
       L_QUANTITY
FROM ORDERS, @LINEITEMS
WHERE O_ORDERKEY = L_ORDERKEY
      AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Parametre Hassasiyet Planı Optimizasyonu

Şunlar için geçerlidir: SQL Server 2022 (16.x) ve sonraki sürümleri Azure SQL VeritabanıAzure SQL Yönetilen Örneği

Parametre Duyarlılık Planı (PSP) iyileştirmesi, Akıllı sorgu işleme özellik ailesinin bir parçasıdır. Parametreli sorgu için tek bir önbelleğe alınmış planın tüm olası gelen parametre değerleri için en uygun olmadığı senaryoyu ele alır. Bu durum, tek biçimli veri dağıtımlarında geçerlidir.

Yaklaşık sorgu işleme

Yaklaşık sorgu işleme, özellik ailesinin yeni bir üyesidir. Yanıt hızının mutlak duyarlıktan daha kritik olduğu büyük veri kümelerinde toplanır. Bir panoda görüntülenmek üzere 10 milyar satır üzerinde bir hesaplama yapmaya COUNT(DISTINCT()) bir örnektir. Bu durumda mutlak duyarlık önemli değildir, ancak yanıt verme kritik önem taşır.

Yaklaşık Sayı Ayrı

Şunlar için geçerlidir: SQL Server (SQL Server 2019 (15.x) ile başlayarak), Azure SQL Veritabanı

Yeni APPROX_COUNT_DISTINCT toplama işlevi, bir gruptaki benzersiz null olmayan değerlerin yaklaşık sayısını döndürür.

Bu özellik, uyumluluk düzeyinden bağımsız olarak SQL Server 2019 (15.x) ile başlayarak kullanılabilir.

Daha fazla bilgi için bkz. APPROX_COUNT_DISTINCT.

Yaklaşık Yüzdebirlik

Şunlar için geçerlidir: SQL Server (SQL Server 2022 (16.x) ile başlayarak), Azure SQL Veritabanı

Bu toplama işlevleri, kabul edilebilir derece tabanlı hata sınırlarına sahip büyük bir veri kümesinin yüzdebirlik dilimlerini hesaplar ve yaklaşık yüzdebirlik toplama işlevlerini kullanarak hızlı kararlar alınmasına yardımcı olur.

Daha fazla bilgi için bkz . APPROX_PERCENTILE_DISC ve APPROX_PERCENTILE_CONT

Satır deposunda toplu iş modu

Şunlar için geçerlidir: SQL Server (SQL Server 2019 (15.x) ile başlayarak), Azure SQL Veritabanı

Rowstore'da toplu iş modu, columnstore dizinlerine gerek kalmadan analiz iş yükleri için toplu iş modu yürütmeyi etkinleştirir. Bu özellik, disk üzerindeki yığınlar ve B ağaç dizinleri için toplu yürütme modu ve bitmap filtreleri desteği sunar. Satır depolama için toplu iş modu, mevcut toplu iş modu ile etkinleştirilmiş tüm işleçlere destek sağlar.

Note

Belgelerde genellikle dizinlere başvuruda B ağacı terimi kullanılır. Rowstore dizinlerinde Veritabanı Altyapısı bir B+ ağacı uygular. Bu, sütun deposu dizinleri veya bellek için iyileştirilmiş tablolardaki dizinler için geçerli değildir. Daha fazla bilgi için SQL Server ve Azure SQL dizin mimarisi ve tasarım kılavuzuna bakın.

Toplu işlem modu yürütmeye genel bakış

SQL Server 2012 (11.x), analitik iş yüklerini hızlandırmaya yönelik yeni bir özellik kullanıma sunuldu: columnstore dizinleri. SQL Server'ın sonraki her sürümünde columnstore dizinlerinin kullanım örnekleri ve performansı arttı. Tablolarda columnstore dizinleri oluşturmak analiz iş yüklerinin performansını artırabilir. Bununla birlikte, birbiriyle ilgili ancak farklı iki teknoloji kümesi vardır:

  • Columnstore dizinleri ile analiz sorguları yalnızca ihtiyaç duydukları sütunlardaki verilere erişir. Columnstore biçiminde sayfa sıkıştırma, geleneksel satır deposu dizinlerindeki sıkıştırmadan da daha etkilidir.
  • Toplu iş modu işleme ile sorgu işleçleri verileri daha verimli işler. Tek seferde bir satır yerine bir grup satır üzerinde çalışırlar. Diğer birçok ölçeklenebilirlik iyileştirmesi toplu iş modu işlemeye bağlıdır. Toplu iş modu hakkında daha fazla bilgi için bkz. Yürütme modları.

giriş/çıkış (G/Ç) ve CPU kullanımını geliştirmek için iki özellik kümesi birlikte çalışır:

  • Columnstore dizinlerini kullanarak verilerinizin daha fazlası belleğe sığar. Bu, giriş/çıkış (G/Ç) iş yükünü azaltır.
  • Toplu iş modu işleme, CPU'ları daha verimli bir şekilde kullanır.

İki teknoloji mümkün olduğunca birbirinden yararlanıyor. Örneğin, toplu iş modu toplamları columnstore dizin taramasının bir parçası olarak değerlendirilebilir. Ayrıca, sıkıştırılmış columnstore verileri, uzunluk-kodu kodlama kullanılarak, toplu modda birleşimler ve toplu modda birleştirmelerle çok daha etkili bir şekilde işlenir.

Ancak iki özelliğin birbirinden bağımsız olduğunu anlamak önemlidir:

  • Sütun deposu dizinlerini kullanan satır modu planlarını edinebilirsiniz.
  • Yalnızca satır deposu dizinlerini kullanan yığın modu için planlar alabilirsiniz.

Genellikle iki özelliği birlikte kullandığınızda en iyi sonuçları elde edersiniz. SQL Server 2019 (15.x) öncesinde, SQL Server sorgu iyileştirici, yalnızca columnstore dizinine sahip en az bir tablo içeren sorguları toplu işlem modu olarak değerlendirirdi.

Columnstore dizinleri bazı uygulamalar için uygun olmayabilir. Bir uygulama columnstore dizinleriyle desteklenmeyen başka bir özellik kullanabilir. Örneğin yerinde yapılan değişiklikler columnstore sıkıştırmasıyla uyumlu değildir. Bu nedenle tetikleyiciler kümelenmiş columnstore dizinlerine sahip tablolarda desteklenmez. Daha da önemlisi, columnstore dizinleri DELETE ve UPDATE deyimleri için ek yük ekler.

Bazı karma işlemsel analitik iş yüklerinde, işlem iş yükünün yükü columnstore dizinlerini kullanmanın sağladığı avantajlardan daha fazladır. Bu tür senaryolar, yalnızca toplu iş modu işlemesini kullanarak geliştirilmiş CPU kullanımından yararlanabilir. Bu nedenle batch-mode-on-rowstore özelliği, ne tür dizinlerin söz konusu olduğuna bakılmaksızın tüm sorgular için toplu iş modunu dikkate alır.

Rowstore'da toplu iş modundan yararlanabilecek iş yükleri

Aşağıdaki iş yükleri, rowstore'da toplu iş modundan yararlanabilir:

  • İş yükünün önemli bir bölümü analiz sorgularından oluşur. Bu sorgular genellikle yüz binlerce satırı veya daha fazlasını işleyen birleşimler veya toplamalar gibi işleçleri kullanır.
  • İş yükü CPU'ya bağlıdır. Performans sorunu G/Ç ise mümkün olduğunca columnstore dizinini göz önünde bulundurmanız önerilir.
  • Columnstore dizini oluşturmak, iş yükünüzün işlem bölümüne çok fazla ek yük ekler. Ya da uygulamanız henüz columnstore dizinlerinde desteklenmeyen bir özelliğe bağlı olduğundan columnstore dizini oluşturmak mümkün değildir.

Note

Rowstore'da toplu iş modu yalnızca CPU tüketimini azaltarak yardımcı olur. G/Ç ile ilgili bir tıkanıklık noktanız varsa ve veriler henüz önbelleğe alınmamışsa ("soğuk" önbellek), satır deposunda toplu mod sorgunun gerçekleşme süresini iyileştirmez. Benzer şekilde, makinede tüm verileri önbelleğe almak için yeterli bellek yoksa performans geliştirme olasılığı düşüktür.

Rowstore üzerinde toplu mod ile neler değişir?

Rowstore'da toplu iş modu için veritabanının uyumluluk düzeyi 150 olması gerekir.

Sorgu columnstore dizinleri olan tablolara erişmese bile sorgu işlemcisi, toplu iş modunun dikkate alınıp alınmayacağına karar vermek için buluşsal yöntemler kullanır. Buluşsal yöntemler şu denetimlerden oluşur:

  1. Giriş sorgusunda tablo boyutlarının, kullanılan işleçlerin ve tahmini kardinalitelerin ilk denetimi.
  2. Optimizatör, sorgu için yeni ve daha ucuz planlar keşfettikçe ek kontrol noktaları ekler. Bu alternatif planlar toplu iş modundan önemli ölçüde yararlanmıyorsa, iyileştirici toplu iş modu alternatiflerini keşfetmeyi durdurur.

Satır deposunda toplu iş modu kullanılıyorsa, gerçek çalıştırma modunu sorgu planında toplu iş modu olarak görürsünüz. Tarama işleci, disk üzerindeki yığınlar ve B ağacı dizinleri için toplu iş modunu kullanır. Bu toplu iş modu taraması, toplu iş modu bit eşlem filtrelerini değerlendirebilir. Planda diğer toplu iş modu işleçlerini de görebilirsiniz. Karma birleşimler, karma tabanlı toplamalar, sıralamalar, pencere toplamaları, filtreler, birleştirme ve işlem skaler işleçleri örnek olarak verilebilir.

Remarks

Sorgu planları her zaman toplu modunu kullanmaz. Sorgu İyileştiricisi, toplu iş modunun sorgu için yararlı olmadığına karar verebilir.

Sorgu İyileştirici arama alanı değişiyor. Bu nedenle, satır modu planı alırsanız, daha düşük bir uyumluluk düzeyinde elde ettiğiniz planla aynı olmayabilir. Toplu iş modu planı alırsanız bu, columnstore diziniyle elde ettiğiniz planla aynı olmayabilir.

Sütun deposu ve satır deposu dizinlerini karıştıran sorgular için planlar, yeni toplu iş modu satır deposu taraması nedeniyle de değişebilir.

Satır depolarında tarama için yeni toplu iş modunun mevcut sınırlamaları vardır.

  • Bellek içi OLTP tabloları veya disk üzerinde depolanan yığınlar ve B-ağaçları dışındaki diğer dizinler için devreye girmez.
  • Ayrıca büyük bir nesne (LOB) sütunu getirildiğinde veya filtrelendiğinde de etkinleşmez. Bu sınırlama seyrek sütun kümelerini ve XML sütunlarını içerir.

Sorgular, columnstore dizinleriyle bile toplu iş modunun kullanılmadığı durumlardır. Örnek olarak imleç içeren sorgular verilebilir. Bu aynı dışlamalar, satır deposunda toplu işlem moduna da uygulanır.

Satır tabanlı veritabanında toplu iş modunu yapılandırma

BATCH_MODE_ON_ROWSTORE Veritabanı kapsamlı yapılandırma varsayılan olarak ON'dır.

Veritabanı uyumluluk düzeyini değiştirmeden rowstore'da toplu iş modunu devre dışı bırakabilirsiniz:

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

Veritabanı kapsamlı yapılandırma aracılığıyla satır deposunda toplu iş modunu devre dışı bırakabilirsiniz. Ancak yine de sorgu ipucunu kullanarak ALLOW_BATCH_MODE sorgu düzeyinde ayarı geçersiz kılabilirsiniz. Aşağıdaki örnek, veritabanı kapsamlı yapılandırma aracılığıyla özellik devre dışı bırakılmış olsa bile satır deposunda toplu iş modunu etkinleştirir:

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

Satır deposunda toplu iş modunu belli bir sorgu için devre dışı bırakmak için DISALLOW_BATCH_MODE sorgu ipucu seçeneğini kullanabilirsiniz. Aşağıdaki örneğe bakın:

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Sorgu işleme geri bildirim özellikleri

Sorgu işleme geri bildirim özellikleri, Akıllı sorgu işleme özellikleri ailesinin bir parçasıdır.

Sorgu işleme geri bildirimi, SQL Server, Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'ndeki sorgu işlemcisinin sorgunun derlenme ve yürütülürken bir veya daha fazla değişiklikten yardım alıp alamayacağına karar vermek için sorgunun yürütülmesiyle ilgili geçmiş verileri kullandığı bir işlemdir. Performans verileri Sorgu Deposu'nda toplanır ve sorgu yürütmeyi geliştirmeye yönelik çeşitli öneriler sağlanır. Başarılı olursa, diskte yapılan bu değişiklikleri gelecekte kullanmak üzere bellekte ve/veya Sorgu Deposu'nda kalıcı hale getirilir. Öneriler yeterli iyileştirme sağlamazsa atılır ve sorgu bu geri bildirim olmadan yürütülmeye devam eder.

SQL Server'ın farklı sürümlerinde veya Azure SQL Veritabanı veya Azure SQL Yönetilen Örneği'nde hangi sorgu işleme geri bildirim özelliklerinin kullanılabildiği hakkında bilgi için bkz. SQL veritabanlarında akıllı sorgu işleme veya her geri bildirim özelliği için aşağıdaki makaleler.

Bellek tahsis geri bildirimi

Bellek verme geri bildirimi, SQL Server'ın geçmiş önemli sürümleri üzerinde dalgalar halinde kullanıma sunulmuştur.

Toplu iş modu bellek tahsis geri bildirimi

Batch modu bellek verme geri bildirimi hakkında bilgi için Batch modu bellek verme geri bildirimi adresini ziyaret edin.

Satır modu bellek tahsis geri bildirimi

Satır modu bellek verme geri bildirimi hakkında bilgi için Satır modu bellek verme geri bildirimi adresini ziyaret edin.

Yüzdelik ve kalıcılık modu bellek verme geri bildirimi

Yüzdebirlik ve kalıcılık modu bellek verme geri bildirimi hakkında bilgi için Bkz. Yüzdebirlik ve kalıcılık modu bellek verme geri bildirimi.

Paralellik derecesi (DOP) geri bildirimi

DOP geri bildirimi hakkında bilgi için Paralellik derecesi (DOP) geri bildirimi adresini ziyaret edin.

Kardinalite tahmini (CE) geri bildirimi

CE geri bildirimi hakkında bilgi için Kardinalite tahmini (CE) geri bildirimi adresini ziyaret edin.

Sorgu Deposu ile plan zorlama optimizasyonu

Sorgu Deposu ile en iyi duruma getirilmiş plan zorlama hakkında bilgi için Bkz. Sorgu Deposu ile en iyi duruma getirilmiş plan zorlama.

İlgili içerik

  • Last updated on