Aracılığıyla paylaş

Sorgu Deposu ile iş yüklerini izlemek için en iyi yöntemler

Şunlar için geçerlidir: SQL Server 2016 (13.x) ve sonraki sürümleri Azure SQL VeritabanıAzure SQL Yönetilen ÖrnekAzure Synapse Analytics (yalnızca ayrılmış SQL havuzu)Microsoft Fabric'de SQL veritabanı

Bu makalede, iş yükünüzle SQL Server Sorgu Deposu'nu kullanmaya yönelik en iyi yöntemler özetlenmiştir.

  • Sorgu Deposu ile yapılandırma ve yönetme hakkında daha fazla bilgi için bkz. Sorgu Deposukullanarak performansı izleme.
  • Sorgu Deposu ile eyleme dönüştürülebilir bilgileri bulma ve performansı ayarlama hakkında bilgi için bkz. Sorgu Deposukullanarak performansı ayarlama.
  • Azure SQL Veritabanı'nda Sorgu Deposu'yu çalıştırma hakkında bilgi için bkz. Azure SQL Veritabanı'nde Sorgu Deposunu çalıştırma.
  • Azure Synapse Analytics'te Sorgu Deposu ayrılmış SQL havuzları için varsayılan olarak etkin değildir, ancak etkinleştirilebilir. Sorgu Deposu için diğer yapılandırma seçenekleri desteklenmez. Daha fazla bilgi için bkz. Azure Synapse Analytics'te geçmiş sorgu depolama ve analiz.

En son SQL Server Management Studio'yu kullanma

SQL Server Management Studio, Sorgu Deposu'nu yapılandırmak ve iş yükünüz hakkında toplanan verileri tüketmek için tasarlanmış bir kullanıcı arabirimleri kümesine sahiptir. SQL Server Management Studio'nun en son sürümünüindirin.

Sorun giderme senaryolarında Sorgu Deposu'yu kullanma hakkında hızlı bir açıklama için bkz. Query Store Azure blogs.

Azure SQL Veritabanı'nda Sorgu Performansı İçgörüleri'ni kullanma

Azure SQL Veritabanı'nda Sorgu Deposu çalıştırıyorsanız, zaman içindeki kaynak tüketimini analiz etmek için Sorgu Performansı İçgörüleri kullanabilirsiniz. CPU, bellek ve G/Ç gibi tüm sorgularınızın ayrıntılı kaynak tüketimini elde etmek için Management Studio ve Azure Data Studio kullanabilirsiniz ancak Sorgu Performansı İçgörüleri, veritabanınızın genel DTU tüketimi üzerindeki etkisini saptamak için hızlı ve verimli bir yol sağlar. Daha fazla bilgi için bkz. Azure SQL Veritabanı Sorgu Performansı İçgörüleri.

Doku SQL veritabanında performansı izlemekiçin Performans panosunukullanın.

Elastik Havuz veritabanlarıyla Sorgu Deposu kullanma

Sorgu Deposu'yu tüm veritabanlarında, hatta yoğun paketlenmiş Azure SQL Veritabanı elastik havuzlarında kullanabilirsiniz. Elastik havuzlardaki çok sayıda veritabanı için Sorgu Deposu etkinleştirildiğinde ortaya çıkan aşırı kaynak kullanımıyla ilgili önceki tüm sorunlar çözüldü.

Sorgu performansı sorunlarını giderme ile başlayın

Sorgu Deposu ile ilgili sorun giderme iş akışı, aşağıdaki diyagramda gösterildiği gibi basittir:

Sorgu Deposu diyagramı sorun giderme: Sorgu Deposu'nun etkinleştirilmesi, Sorgu Deposu'nun verileri toplamasına izin verme, Sorunlu sorguları belirleme ve düzeltme.

Önceki bölümde açıklandığı gibi Management Studio'yu kullanarak Sorgu Deposu'yu etkinleştirin veya aşağıdaki Transact-SQL deyimini yürütebilirsiniz:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Sorgu Deposunun iş yükünüzü doğru şekilde temsil eden veri kümesini toplaması biraz zaman alır. Genellikle, çok karmaşık iş yükleri için bile bir gün yeterlidir. Ancak, verileri keşfetmeye başlayabilir ve özelliği etkinleştirdikten hemen sonra dikkat etmeniz gereken sorguları belirleyebilirsiniz. Belirli senaryolar için sorun giderme görünümlerini açmak için, Management Studio Nesne Gezgini'ndeki veritabanı düğümünün altındaki Sorgu Deposu alt klasörüne gidin.

Management Studio Sorgu Deposu görünümleri, her biri aşağıdaki istatistik işlevlerinden biri olarak ifade edilen yürütme ölçümleri kümesiyle çalışır:

SQL Server sürümü Uygulama metriği İstatistik işlevi
SQL Server 2016 (13.x) CPU süresi, Süre, Yürütme sayısı, Mantıksal okumalar, Mantıksal yazmalar, Bellek tüketimi, Fiziksel okumalar, CLR süresi, Paralellik derecesi (DOP) ve Satır sayısı Ortalama, Maksimum, Minimum, Standart Sapma, Toplam
SQL Server 2017 (14.x) CPU süresi, Süre, Yürütme sayısı, Mantıksal okumalar, Mantıksal yazmalar, Bellek tüketimi, Fiziksel okumalar, CLR süresi, Paralellik derecesi, Satır sayısı, Günlük belleği, TempDB belleği ve Bekleme süreleri Ortalama, Maksimum, Minimum, Standart Sapma, Toplam

Aşağıdaki grafikte Sorgu Deposu görünümlerini bulma gösterilmektedir:

Sorgu Deposu görünümlerinin konumunu gösteren SSMS ekran görüntüsü.

Aşağıdaki tabloda Sorgu Deposu görünümlerinin her birinin ne zaman kullanılacağı açıklanmaktadır:

SQL Server Management Studio görünümü Senaryo
Geri Dönen Sorgular Yürütme ölçümlerinin kısa süre önce gerilediği (örneğin, daha kötüye değiştirilmiş) sorguları belirleme.
Uygulamanızdaki gözlemlenen performans sorunlarını düzeltilmesi veya geliştirilmesi gereken gerçek sorgularla ilişkilendirmek için bu görünümü kullanın.
Genel Kaynak Tüketimi Yürütme ölçümlerinden herhangi biri için veritabanı için toplam kaynak tüketimini analiz edin.
Kaynak desenlerini (günlük ve gecelik iş yükleri) tanımlamak ve veritabanınız için genel tüketimi iyileştirmek için bu görünümü kullanın.
En Çok Kaynak Tüketen Sorgular İlgi çekici bir yürütme ölçümü seçin ve sağlanan zaman aralığı için en aşırı değerlere sahip sorguları belirleyin.
Dikkatinizi veritabanı kaynak tüketimi üzerinde en büyük etkiye sahip en ilgili sorgulara odaklamanız için bu görünümü kullanın.
Zorlamalı Planlı Sorgular Sorgu Deposu kullanılarak önceden zorlanan planları listeler.
Şu anda zorlanan tüm planlara hızla erişmek için bu görünümü kullanın.
Yüksek Çeşitliliğe Sahip Sorgular İşlem süresi, CPU süresi, Girdi/Çıktı ve Bellek kullanımı gibi kullanılabilir boyutlardan herhangi biriyle ilişkili olan yüksek yürütme varyasyonlu sorguları, istenen zaman aralığında analiz edin.
Uygulamalarınız genelinde kullanıcı deneyimini etkileyebilecek, çok çeşitli performansa sahip sorguları tanımlamak için bu görünümü kullanın.
Sorgu Bekleme İstatistikleri Veritabanında en etkin olan bekleme kategorilerini ve seçilen bekleme kategorisine en çok katkıda bulunan sorguları analiz edin.
Bekleme istatistiklerini analiz etmek ve uygulamalarınızda kullanıcı deneyimini etkileyebilecek sorguları belirlemek için bu görünümü kullanın.

Şunlar için geçerlidir: SQL Server Management Studio v18.0 ve SQL Server 2017 (14.x) ile başlayarak.
İzlenen Sorgular En önemli sorguların yürütülmesini gerçek zamanlı olarak izleyin. Bu görünümü genellikle zorlamalı planlara sahip sorgularınız olduğunda ve sorgu performansının kararlı olduğundan emin olmak istediğinizde kullanırsınız.

Bahşiş

Management Studio'yu kullanarak en çok kaynak tüketen sorguları tanımlama ve plan seçimi değişikliği nedeniyle gerileyenleri düzeltme hakkında ayrıntılı bir açıklama için bkz. Query Store Azure Blogs.

En iyi olmayan performansa sahip bir sorgu tanımladığınızda, eyleminiz sorunun doğasına bağlıdır.

  • Sorgu birden çok planla yürütüldüyse ve son plan öncekine göre çok daha kötü durumdaysa, plan zorlama mekanizmasını kullanabilirsiniz. SQL Server, planı optimizatörde zorlamaya çalışır. Plan zorlama başarısız olursa bir XEvent tetiklenir ve optimizatöre normal şekilde optimize etmesi talimatı verilir.

SSMS'den Sorgu Deposu zorla plan düğmesinin ekran görüntüsü.

Not

Önceki grafikte, belirli sorgu planları için farklı şekiller ve her olası durum için aşağıdaki anlamlar yer alabilir:

Şekil Anlam
Daire Sorgu tamamlandı, bu da normal yürütmenin başarıyla tamamlandığı anlamına gelir.
Kare İptal edildi, yani müşteri tarafından başlatılan bir yürütme durduruldu.
Üçgen Başarısız oldu, bu da bir özel durumun yürütmeyi durdurduğunu gösterir.

Ayrıca şeklin boyutu, belirtilen zaman aralığındaki sorgu yürütme sayısını yansıtır. Boyut, daha fazla sayıda işlem ile artar.

  • Sorgunuzda en iyi yürütme için bir dizin eksik olduğu sonucuna varabilirsiniz. Bu bilgiler sorgu yürütme planı içinde ortaya çıkar. Eksik dizini oluşturun ve Sorgu Deposu'nı kullanarak sorgu performansını denetleyin.

Sorgu Deposu planının SSMS'sinden alınan ve eksik dizin bildiriminin vurgulandığı ekran görüntüsü.

İş yükünüzü SQL Veritabanı'nda çalıştırırsanız, dizin önerilerini otomatik olarak almak için SQL Veritabanı Dizin Danışmanı'na kaydolun.

  • Bazı durumlarda, yürütme planındaki tahmini ve gerçek satır sayısı arasındaki farkın önemli olduğunu görürseniz istatistik yeniden derlemesini zorunlu kabilirsiniz.
  • Sorgu parametreleştirmeden yararlanmak veya daha iyi mantık uygulamak için sorunlu sorguları yeniden yazın.

Bahşiş

Azure SQL Veritabanı'nda, kod değişikliği yapmadan sorgulara ipuçları uygulamak için Sorgu Deposu ipuçları özelliğini göz önünde bulundurun. Daha fazla bilgi ve örnek için bkz. Sorgu Deposu ipuçları.

Sorgu Deposu'un sorgu verilerini sürekli topladığını doğrulayın

Sorgu Deposu işlem modunu sessizce değiştirebilir. Sorgu Deposu'nun çalıştığından emin olmak ve önlenebilir nedenlerden kaynaklanan hataları önlemek için işlem yapmak için Sorgu Deposu'nun durumunu düzenli olarak izleyin. İşlem modunu belirlemek ve en uygun parametreleri görüntülemek için aşağıdaki sorguyu yürütür:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

actual_state_desc ile desired_state_desc arasındaki fark, işlem modu değişikliğinin otomatik olarak gerçekleştiğini gösterir. En yaygın değişiklik Sorgu Deposu'na sessizce salt okunur moda geçiş yapmaktır. Son derece nadir durumlarda, Sorgu Deposu iç hatalar nedeniyle HATA durumu içine girebilir.

Gerçek durum salt okunur olduğunda, kök nedeni belirlemek için readonly_reason sütununu kullanın. Genellikle boyut kotası aşıldığı için Sorgu Deposu'nun salt okunur moda geçtiğini fark edebilirsiniz. Bu durumda, readonly_reason 65536 olarak ayarlanır. Diğer nedenlerle bkz. sys.database_query_store_options (Transact-SQL).

Sorgu Deposu'nu okuma-yazma moduna geçirmek ve veri toplamayı etkinleştirmek için aşağıdaki adımları göz önünde bulundurun:

  • ALTER DATABASE MAX_STORAGE_SIZE_MB seçeneğini kullanarak maksimum depolama boyutunu artırın.

  • Aşağıdaki deyimi kullanarak Sorgu Deposu verilerini temizleyin:

    ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;

İşlem modunu açıkça okuma-yazma olarak değiştiren aşağıdaki deyimi yürüterek bu adımlardan birini veya her ikisini de uygulayabilirsiniz:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);

Proaktif olmak için aşağıdaki adımları uygulayın:

  • En iyi yöntemleri uygulayarak işlem modunda sessiz değişiklikleri önleyebilirsiniz. Salt okunur moda geçme olasılığını önemli ölçüde azaltmak için Sorgu Deposu boyutunun her zaman izin verilen en yüksek değerin altında olduğundan emin olun. Boyut sınırına yaklaştığında Sorgu Deposunun verileri otomatik olarak temizlemesi için, Sorgu Deposu Yapılandırma bölümünde açıklandığı gibi boyut tabanlı ilkeyi etkinleştirin.
  • En son verilerin korunmasını sağlamak için, eski bilgileri düzenli olarak kaldırmak için zamana bağlı ilkeyi yapılandırın.
  • Son olarak, Sorgu Deposu Yakalama Modu'i Otomatik olarak ayarlamayı düşünün çünkü genellikle iş yükünüz için daha az uygun olan sorguları filtreler.

HATA durumu

Sorgu Deposu'nu kurtarmak için okuma-yazma modunu açıkça ayarlamayı deneyin ve gerçek durumu yeniden denetleyin.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Sorun devam ederse, Diskte Sorgu Deposu verilerinin bozulmasının kalıcı olduğunu gösterir.

SQL Server 2017(14.x) ile başlayarak, etkilenen veritabanındaki sys.sp_query_store_consistency_check saklı yordamı yürütülerek Sorgu Deposu kurtarılabilir. Kurtarma işlemini denemeden önce Sorgu Deposu devre dışı bırakılmalıdır. QDS'nin tutarlılık denetimini ve kurtarmasını gerçekleştirmek için kullanılacak veya değiştirebileceğiniz örnek bir sorgu aşağıda verilmiştir:

IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) 
BEGIN
  BEGIN TRY
    ALTER DATABASE [QDS] SET QUERY_STORE = OFF
    Exec [QDS].dbo.sp_query_store_consistency_check
    ALTER DATABASE [QDS] SET QUERY_STORE = ON
    ALTER DATABASE [QDS] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)
  END TRY
 
  BEGIN CATCH 
    SELECT  
      ERROR_NUMBER() AS ErrorNumber  
      ,ERROR_SEVERITY() AS ErrorSeverity  
      ,ERROR_STATE() AS ErrorState  
      ,ERROR_PROCEDURE() AS ErrorProcedure  
      ,ERROR_LINE() AS ErrorLine  
      ,ERROR_MESSAGE() AS ErrorMessage; 
  END CATCH;   
END

SQL Server 2016 (13.x) için, verileri gösterildiği gibi Sorgu Deposu'ndan temizlemeniz gerekir.

Kurtarma başarısız olduysa, okuma-yazma modunu ayarlamadan önce Sorgu Deposu'nu temizlemeyi deneyebilirsiniz.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE CLEAR;
GO

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Parametreli olmayan sorgular kullanmaktan kaçının

Gerekli olmadığında parametrelenmemiş sorgular kullanmak en iyi yöntem değildir. Geçici analiz örneği verilmiştir. Önbelleğe alınmış planlar yeniden kullanılamaz ve bu da Sorgu İyileştirici'yi her benzersiz sorgu metni için sorgu derlemeye zorlar. Daha fazla bilgi için bkz. Zorlamalı parametreleştirmekullanma yönergeleri.

Ayrıca, Sorgu Deposu büyük olasılıkla çok sayıda farklı sorgu metni ve bunun sonucunda benzer şekilde çok sayıda farklı yürütme planı nedeniyle boyut kotasını hızla aşabilir. Sonuç olarak, iş yükünüzün performansı yetersizdir ve Sorgu Deposu salt okunur moda geçebilir veya gelen sorgulara ayak uydurmaya çalışmak için verileri sürekli silebilir.

Aşağıdaki seçenekleri göz önünde bulundurun:

  • Uygun olduğunda sorguları parametreleştirin. Örneğin, sorguları bir saklı yordamın içine veya sp_executesql'un içine sar. Daha fazla bilgi için bkz. Parametreler ve yürütme planının yeniden kullanımı.
  • İş yükünüz farklı sorgu planlarına sahip çok sayıda tek kullanımlık geçici toplu iş içeriyorsa geçici iş yükleri için iyileştirme seçeneğini kullanın.
    • Ayrı query_hash değerlerinin sayısını sys.query_store_queryiçindeki toplam girdi sayısıyla karşılaştırın. Oran 1'e yakınsa geçici iş yükünüz farklı sorgular oluşturur.
  • Farklı sorgu planlarının sayısı büyük değilse veritabanı veya bir sorgu alt kümesi için zorlamalı parametreleştirme uygulayın.
    • Parametreleştirmeyi yalnızca seçili sorgu için zorlamak için plan kılavuzunu kullanın.
    • İş yükünüzde az sayıda farklı sorgu planı varsa, parametreleştirme veritabanı seçeneğini komutunu kullanarak zorlamalı parametreleştirmeyi yapılandırın. Örnek olarak, ayrı query_hash sayısı ile sys.query_store_query içindeki toplam girdi sayısı arasındaki oran 1'den çok daha azdır.
  • Küçük kaynak tüketimine sahip geçici sorguları otomatik olarak filtrelemek için QUERY_CAPTURE_MODEAUTO olarak ayarlayın.

Bahşiş

Entity Framework (EF) gibi bir Object-Relational Eşleme (ORM) çözümü kullanılırken, el ile LINQ sorgu ağaçları gibi uygulama sorguları veya belirli ham SQL sorguları parametrelendirilmeyebilir; bu da plan yeniden kullanımını ve Sorgu Deposu'ndaki sorguları izleme özelliğini etkiler. Daha fazla bilgi için bkz. EF Sorgu önbelleğe alma ve parametreleştirme ve EF Raw SQL Sorguları .

Sorgu Deposu'nda parametrelenmemiş sorguları bulma

Sorgu Deposu'nda depolanan plan sayısını aşağıdaki sorguyu kullanarak, Sorgu Deposu DMV'lerini kullanarak SQL Server, Azure SQL Yönetilen Örneği veya Azure SQL Veritabanı'nda bulabilirsiniz:

SELECT count(Pl.plan_id) AS plan_count, Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry
    ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id
GROUP BY Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
ORDER BY plan_count desc;

Sorgu kaynak tüketimini tanılamada yararlı olabilecek olay query_store_db_diagnostics'yi yakalamak için aşağıdaki örnek, bir Genişletilmiş Olaylar oturumu oluşturur. SQL Server'da, bu genişletilmiş olay oturumu varsayılan olarak SQL Server Günlük klasöründe bir olay dosyası oluşturur. Örneğin, Windows'da varsayılan SQL Server 2019 (15.x) yüklemesinde, olay dosyası (.xel dosyası) C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Logklasöründe oluşturulmalıdır. Azure SQL Yönetilen Örneği için bunun yerine bir Azure Blob Depolama konumu belirtin. Daha fazla bilgi için bkz. Azure SQL Yönetilen Örneği için XEvent event_file. 'qds.query_store_db_diagnostics' olayı Azure SQL Veritabanı için kullanılamaz.

CREATE EVENT SESSION [QueryStore_Troubleshoot] ON SERVER 
ADD EVENT qds.query_store_db_diagnostics(
      ACTION(sqlos.system_thread_id,sqlos.task_address,sqlos.task_time,sqlserver.database_id,sqlserver.database_name))
ADD TARGET package0.event_file(SET filename=N'QueryStore',max_file_size=(100))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF);

Bu verilerle, plan sayısını Sorgu Deposu'nda ve diğer birçok istatistikte bulabilirsiniz. Sorgu Deposu tarafından izlenen bellek miktarını ve plan sayısını anlamak için olay verilerinde plan_count, query_count, max_stmt_hash_map_size_kbve max_size_mb sütunlarını arayın. Plan sayısı normalden yüksekse parametrelenmemiş sorgularda artış olduğunu gösterebilir. Sorgu Deposu'ndaki parametreli sorguları ve parametrelenmemiş sorguları gözden geçirmek için aşağıdaki Sorgu Deposu DMV'leri sorgusunu kullanın.

Parametreli sorgular için:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE qsq.query_parameterization_type<>0 or qsqt.query_sql_text like '%@%';

Parametrelenmemiş sorgular için:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE query_parameterization_type=0;

Nesneleri içermek için DROP ve CREATE deseni kullanmaktan kaçının

Sorgu Deposu, sorgu girdisini saklı yordam, işlev ve tetikleyici gibi bir içeren nesneyle ilişkilendirir. İçeren bir nesneyi yeniden oluşturduğunuzda, aynı sorgu metni için yeni bir sorgu girişi oluşturulur. Bu, zaman içinde bu sorgu için performans istatistiklerini izlemenizi ve bir plan zorlama mekanizması kullanmanızı önler. Bu durumu önlemek için, ALTER <object> işlemini kullanarak mümkün olduğunda içeren bir nesne tanımını değiştirin.

Zorunlu planların durumunu düzenli olarak denetleyin

Plan zorlama, kritik sorgular için performansı düzeltmek ve bunları daha öngörülebilir hale getirmek için kullanışlı bir mekanizmadır. Plan ipuçları ve plan kılavuzlarında olduğu gibi, bir planı zorlamak, gelecekteki yürütmelerde kullanılacağı garanti değildir. Genellikle veritabanı şeması, yürütme planı tarafından referans alınan nesnelerin değiştirildiği veya kaldırıldığı şekilde değiştiğinde plan zorlama başarısız olmaya başlar. Bu durumda SQL Server sorgu yeniden derlemesine geri dönerken, gerçek zorlama hatasının nedeni sys.query_store_planiçinde ortaya çıkar. Aşağıdaki sorgu zorlamalı planlar hakkındaki bilgileri döndürür:

USE [QueryStoreDB];
GO

SELECT p.plan_id, p.query_id, q.object_id as containing_object_id,
    force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan AS p
JOIN sys.query_store_query AS q on p.query_id = q.query_id
WHERE is_forced_plan = 1;

Nedenlerin tam listesi için bkz. sys.query_store_plan. Ayrıca query_store_plan_forcing_failed XEvent'i kullanarak plan zorlama hatalarını izleyebilir ve sorunlarını giderebilirsiniz.

Bahşiş / Tüyo / İpucu

Azure SQL Veritabanı'nda kod değişikliği olmayan sorgularda sorgu ipuçlarını zorlamak için sorgu deposu ipuçları özelliğini göz önünde bulundurun. Daha fazla bilgi ve örnek için bkz. Sorgu Deposu ipuçları.

Zorunlu planlara sahip sorgular için veritabanlarını yeniden adlandırmaktan kaçının

Yürütme planları, database.schema.objectgibi üç bölümlü adları kullanarak nesnelere başvurur.

Veritabanını yeniden adlandırırsanız plan zorlama başarısız olur ve bu da sonraki tüm sorgu yürütmelerinde yeniden derlemeye neden olur.

Görev açısından kritik sunucularda Sorgu Deposu kullanma

Genel izleme bayrakları 7745 ve 7752, Sorgu Deposu kullanılarak veritabanlarının kullanılabilirliğini geliştirmek için kullanılabilir. Daha fazla bilgi için bkz. İzleme bayrakları.

  • İzleme bayrağı 7745, SQL Server kapatılmadan önce Sorgu Deposunun diske veri yazdığı varsayılan davranışı engeller. Bu, DATA_FLUSH_INTERVAL_SECONDSile tanımlanan zaman penceresine kadar toplanan ancak diskte henüz kalıcı olmayan Sorgu Deposu verilerinin kaybolacağı anlamına gelir.
  • İzleme bayrağı 7752, Sorgu Deposu'nun eşzamanlı olmayan yüklenmesini etkinleştirir. Bu, veritabanının çevrimiçi olmasına ve Sorgu Deposu tamamen kurtarılmadan önce sorguların yürütülmesine olanak tanır. Varsayılan davranış, Sorgu Deposu'nun zaman uyumlu yükünü gerçekleştirmektir. Varsayılan davranış, Sorgu Deposu kurtarılmadan önce sorguların yürütülmesini engeller, aynı zamanda veri koleksiyonunda tüm sorguların kaçırılmasını önler.

Not

SQL Server 2019 (15.x) ile başlayarak bu davranış altyapı tarafından denetlenir ve izleme bayrağı 7752'nin hiçbir etkisi yoktur.

Önemli

SQL Server 2016'da (13.x) tam zamanında iş yükü içgörüleri için Sorgu Deposu kullanıyorsanız, SQL Server 2016 (13.x) SP2 CU2'de (KB 4340759) en kısa sürede performans ölçeklenebilirliği iyileştirmelerini yüklemeyi planlayın. Bu geliştirmeler olmadan veritabanı yoğun iş yükleri altında olduğunda spinlock çekişmesi oluşabilir ve sunucu performansı yavaşlayabilir. Özellikle, QUERY_STORE_ASYNC_PERSIST spinlock veya SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlock üzerinde yoğun çekişme görebilirsiniz. Bu geliştirme uygulandıktan sonra Sorgu Deposu artık spinlock çekişmesi oluşturmaz.

Önemli

SQL Server'da (SQL Server 2016 (13.x) ile SQL Server 2017 (14.x) arasında tam zamanında iş yükü içgörüleri için Sorgu Deposu kullanıyorsanız, SQL Server 2016 (13.x) SP2 CU15'te performans ölçeklenebilirliği iyileştirmesini yüklemeyi planlayın. SQL Server 2017 (14.x) CU23 ve SQL Server 2019 (15.x) CU9 en kısa sürede. Bu geliştirme olmadan, veritabanı yoğun geçici iş yükleri altında olduğunda Sorgu Deposu büyük miktarda bellek kullanabilir ve sunucu performansı yavaşlayabilir. Bu geliştirme uygulandıktan sonra Sorgu Deposu, çeşitli bileşenlerinin kullanabileceği bellek miktarına iç sınırlar uygular ve Veritabanı Altyapısı'na yeterli bellek döndürülene kadar işlem modunu otomatik olarak salt okunur olarak değiştirebilir. Sorgu Deposu iç bellek sınırları, değiştirilebilir olduğundan belgelenmez.

Azure SQL Veritabanı etkin coğrafi çoğaltmada Sorgu Deposu kullanma

Azure SQL Veritabanı'nın ikincil etkin coğrafi çoğaltması üzerindeki Sorgu Deposu, birincil çoğaltmadaki etkinliğin salt okunur bir kopyası olacaktır.

Azure SQL Veritabanı'nın coğrafi çoğaltmasında uyumsuz hizmet seviyelerinden kaçının. İkincil veritabanı, birincil veritabanının aynı işlem boyutunda veya yakınında ve birincil veritabanının aynı hizmet katmanında olmalıdır. Birincil kopyada, ikincil kopya gecikmesi nedeniyle işlem günlüğü hızının azaltıldığını gösteren HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO bekleme türünü sys.dm_db_wait_statsiçinde bulun.

Etkin coğrafi çoğaltmanın ikincil Azure SQL veritabanının boyutunu tahmin etme ve yapılandırma hakkında daha fazla bilgi için bkz. İkincil veritabanı yapılandırma.

Sorgu Deposu'yu iş yükünüzle uyumlu tutun

Sorgu Deposu'nun yapılandırılması ve yönetilmesi için en iyi yöntemler ve öneriler şu makalede genişletilmiştir: Sorgu Deposuyönetmek için en iyi yöntemler.

İlgili içerik