Aracılığıyla paylaş

Okunabilir ikincil öğeler için Sorgu Deposu

Şunlar için geçerlidir: SQL Server 2025 (17.x) Azure SQL Veritabanı

Okunabilir ikinciller için Sorgu Deposu, ikincil çoğaltmalarda çalışan iş yükleri için Sorgu Deposu içgörülerini etkinleştirir. etkinleştirildiğinde, ikincil çoğaltmalar sorgu yürütme bilgilerini (çalışma zamanı ve bekleme istatistikleri gibi) birincil çoğaltmaya akışla gönderir; burada veriler Sorgu Deposu'nda kalıcı hale getirilir ve tüm çoğaltmalarda görünür hale getirilir.

Platform desteği

Şu anda okunabilir ikincil öğeler için Sorgu Deposu özelliği SQL Server 2025 (17.x) ve Azure SQL Veritabanı'nda üretimde kullanılabilir ve desteklenir. SQL Server 2025 (17.x) ve Azure SQL Veritabanı'nda başlayarak, okunabilir ikincil öğeler için Sorgu Deposu varsayılan olarak etkinleştirilir.

SQL Server 2022'de (16.x), okunabilir ikincil öğeler için Sorgu Deposu önizlemede kalır ve bu nedenle üretimde desteklenmez ve varsayılan olarak devre dışı bırakılır. Sorgu Deposu'nu yalnızca SQL Server 2022'de (16.x) okunabilir ikincil öğeler için etkinleştirmek için, birincil ve tüm okunabilir ikincil çoğaltmalar için 12606 izleme bayrağının etkinleştirilmesi gerekir. İzleme bayrağı 12606, SQL Server 2022 (16.x) tabanlı üretim dağıtımlarına yönelik değildir. Daha fazla bilgi için bkz. SQL Server 2022 sürüm notları. SQL Server 2025 (17.x) için, okunabilir ikincil öğelerde Sorgu Deposu özelliği varsayılan olarak açıktır .

Azure SQL Veritabanı, tüm veritabanları otomatik olarak kaydedilir ve desteklenen hizmet katmanları ve yüksek kullanılabilirlik senaryolarında okunabilir ikinciller için Sorgu Deposu özelliğini destekleyecek şekilde etkinleştirilir. Şu anda bu özellik Azure SQL Veritabanı Hiper Ölçek'te desteklenmiyor.

Şu anda bu özellik Azure SQL Yönetilen Örneği'nde veya Microsoft Fabric'teki SQL veritabanında desteklenmiyor.

Desteklenen yüksek kullanılabilirlik senaryoları

  • SQL Server 2025 (17.x) örneğinde okunabilir ikincil öğeler için Sorgu Deposu'nu kullanmadan önce Always On kullanılabilirlik grubunun yapılandırılması gerekir.

  • Azure SQL Veritabanı için, okunabilir ikincil öğeler için Sorgu Deposu aşağıdaki hizmet katmanlarını destekler:

    • Etkin coğrafi çoğaltma ile genel amaçlı (yerleşik yüksek kullanılabilirlik çoğaltması yoktur; ikincil destek için coğrafi çoğaltma yapılandırması gerektirir)
    • Premium (yerleşik yüksek kullanılabilirlik çoğaltmaları içerir; etkin coğrafi çoğaltma da desteklenir)
    • İş açısından kritik (yerleşik yüksek kullanılabilirlik çoğaltmaları içerir; etkin coğrafi çoğaltma da desteklenir)

Okunabilir ikincil öğeler için Sorgu Deposu'yu etkinleştirme

Birincil çoğaltmada Sorgu Deposu henüz etkinleştirilmemiş ve READ_WRITE modunda değilse, devam etmeden önce bunu etkinleştirmeniz gerekir. Birincil çoğaltmada istenen her veritabanı için aşağıdaki betiği çalıştırın:

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

Birincil çoğaltmaya bağlanın ve Sorgu Deposu'nu tüm okunabilir ikincil üzerlerinde etkinleştirmek için, özelliği kullanacak şekilde listeye eklenecek her veritabanı için aşağıdaki betiği çalıştırın.

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_WRITE);

İkincil çoğaltmalar için otomatik plan düzeltmeyi etkinleştirme

Şunlar için geçerlidir: SQL Server 2022 (16.x) ve sonraki sürümleri, Azure SQL Veritabanı.

İkincil çoğaltmalar için Sorgu Deposu'yu etkinleştirdikten sonra, otomatik plan düzeltme özelliğinin ikincil çoğaltmalardaki planları zorlamasına izin vermek için isteğe bağlı olarak otomatik ayarlamayı etkinleştirebilirsiniz. Bu, sorgu iyileştiricinin ikincil çoğaltmalardaki yürütme planı regresyonlarından kaynaklanan sorgu performansı sorunlarını otomatik olarak tanımlamasını ve düzeltmesini sağlar.

İkincil çoğaltmalar için otomatik plan düzeltmesini etkinleştirmek için birincil çoğaltmaya bağlanın ve istenen her veritabanı için aşağıdaki betiği yürütebilirsiniz:

ALTER DATABASE [Database_Name]
FOR SECONDARY
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);

İkincil çoğaltmalar için Sorgu Deposu'yu devre dışı bırakma

İkincil çoğaltmalar için Sorgu Deposu özelliğini tüm ikincil çoğaltmalarda devre dışı bırakmak için, master çoğaltmasındaki primary veritabanına bağlanın ve istenen her veritabanı için aşağıdaki betiği çalıştırın.

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_ONLY);

İkincil çoğaltmalarda Sorgu Deposu'nun etkinleştirildiğini doğrulayın

İkincil çoğaltmadaki veritabanına bağlanarak ve aşağıdaki T-SQL deyimini yürüterek Sorgu Deposunun bir secondary çoğaltmada etkinleştirildiğini doğrulayabilirsiniz:

SELECT desired_state_desc,
       actual_state_desc,
       readonly_reason
FROM sys.database_query_store_options;

sys.database_query_store_options katalog görünümü sorgulandığında elde edilen sonuçlar, Sorgu Deposu'nun gerçek durumunun READ_CAPTURE_SECONDARYile readonly_reason olduğunu 8 göstermelidir.

desired_state_desc actual_state_desc readonly_reason
READ_CAPTURE_SECONDARY READ_CAPTURE_SECONDARY 8

Açıklamalar

Terminoloji

Çoğaltma kümesi, veritabanının okuma/yazma çoğaltması (birincil) ve mantıksal birim olarak ele alınan bir veya daha fazla salt okunur çoğaltma (ikincil) olarak tanımlanır. Bu bağlamdaki bir rol , belirli bir çoğaltmanın rolünü ifade eder. Bir replika, birincil replika olarak hizmet ettiğinde, hem veri değişikliklerini gerçekleştirebilen hem de okuma etkinliğinde bulunabilen bir okuma/yazma replikası olarak işlev görür. Bir kopya yalnızca salt okunur etkinlik gerçekleştirecek şekilde yapılandırıldığında, ikincil bir rolde (ikincil, coğrafi ikincil, coğrafi yüksek erişilebilirlik ikincil) hizmet eder. Roller planlı veya plansız yük devretme olayları aracılığıyla değişebilir; bu durumda birincil bir ikincil veya tam tersi olabilir.

Şu anda desteklenen roller şunlardır:

  • Primary
  • Secondary
  • Coğrafi ikincil
  • Coğrafi HA ikincil
  • Adlandırılmış Replika

Nasıl çalışır?

Sorgular hakkında depolanan veriler, iş yükü olarak rol temelinde analiz edilebilir. Okunabilir ikinciller için Sorgu Deposu, ikincil çoğaltmalarda yürütülebilecek benzersiz, salt okunur iş yüklerinin performansını izleme olanağı sağlar. Veriler rol düzeyinde toplanır. Örneğin, SQL Server dağıtılmış kullanılabilirlik grupları yapılandırması şunlardan oluşabilir:

  • Birincil kopya, Kullanılabilirlik Grubu 1'in (AG1) parçası

  • İki yerel ikincil replika, ayrıca AG1'in bir parçası.

  • Ayrı bir kullanılabilirlik grubunun (AG2) parçası olan başka bir konumdaki uzak birincil çoğaltma. SQL Server terimleriyle buna küresel iletici denir; okunabilir ikinciller için Sorgu Deposu özelliği ise bunu coğrafi olarak dağıtılmış bir Geo secondary ikincil çoğaltma olduğu varsayılarak tanır ve Geo secondary çoğaltma olarak adlandırır.

AG1 ve AG2, AG1'in ikincil çoğaltmalarından birinde salt okunur iş yükü yürütürken salt okunur bağlantılara izin verecek şekilde yapılandırılırsa, Sorgu Deposu yürütme istatistikleri AG1'in birincil çoğaltmasına gönderilir ve veriler AG2'deki genel iletici de dahil olmak üzere tüm ikincil çoğaltmalara geri gönderilmeden önce rolden secondary oluşturulan veriler olarak toplanır ve kalıcı hale gelir. AG2'nin birincil kopyasına yönelik ayrı bir iş yükü yürütüldüğünde, küresel yönlendirici aracılığıyla verileri AG1'in birincil çoğaltma kopyasına geri gönderilir ve Geo secondary rolünden üretilen veriler gibi kalıcı hale getirilir.

Gözlemlenebilirlik perspektifinden bakıldığında sys.query_store_runtime_stats sistem kataloğu görünümü, yürütme istatistiklerinin kaynağı olan rolü belirlemeye yardımcı olmak için genişletilir. Bu görünümle sys.query_store_replicas sistem kataloğundaki görünüm arasında, rolün daha anlaşılır bir ismini sağlayabilecek bir ilişki vardır. SQL Server'da replica_name sütun şeklindedir NULL. Ancak, replica_name adlandırılmış bir çoğaltma varsa ve salt okunur iş yükleri için kullanılıyorsa, bu sütun Hiper Ölçek hizmet katmanı için doldurulur.

Bir T-SQL sorgusu örneği, son 8 saat boyunca tüm replikalardan CPU kaynaklarını kullanan ilk 50 sorguya dair genel bir analiz sağlamak için kullanılabilir.

-- Top 50 queries by CPU across all replicas in the last 8 hours
DECLARE @hours AS INT = 8;

SELECT TOP 50 qsq.query_id,
              qsp.plan_id,
              CASE qrs.replica_group_id WHEN 1 THEN 'PRIMARY' WHEN 2 THEN 'SECONDARY' WHEN 3 THEN 'GEO SECONDARY' WHEN 4 THEN 'GEO HA SECONDARY' ELSE CONCAT('NAMED REPLICA_', qrs.replica_group_id) END AS replica_type,
              qsq.query_hash,
              qsp.query_plan_hash,
              SUM(qrs.count_executions) AS sum_executions,
              SUM(qrs.count_executions * qrs.avg_logical_io_reads) AS total_logical_reads,
              SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) AS total_cpu_ms,
              AVG(qrs.avg_logical_io_reads) AS avg_logical_io_reads,
              AVG(qrs.avg_cpu_time / 1000.0) AS avg_cpu_ms,
              ROUND(TRY_CAST (SUM(qrs.avg_duration * qrs.count_executions) AS FLOAT) / NULLIF (SUM(qrs.count_executions), 0) * 0.001, 2) AS avg_duration_ms,
              COUNT(DISTINCT qsp.plan_id) AS number_of_distinct_plans,
              qsqt.query_sql_text
FROM sys.query_store_runtime_stats_interval AS qsrsi
     INNER JOIN sys.query_store_runtime_stats AS qrs
         ON qrs.runtime_stats_interval_id = qsrsi.runtime_stats_interval_id
     INNER JOIN sys.query_store_plan AS qsp
         ON qsp.plan_id = qrs.plan_id
     INNER JOIN sys.query_store_query AS qsq
         ON qsq.query_id = qsp.query_id
     INNER JOIN sys.query_store_query_text AS qsqt
         ON qsq.query_text_id = qsqt.query_text_id
WHERE qsrsi.start_time >= DATEADD(HOUR, -@hours, GETUTCDATE())
GROUP BY qsq.query_id, qsq.query_hash, qsp.query_plan_hash, qsp.plan_id, qrs.replica_group_id, qsqt.query_sql_text
ORDER BY SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) DESC, AVG(qrs.avg_cpu_time / 1000.0) DESC;

SQL Server Management Studio (SSMS) 21 ve sonraki sürümlerindeki Sorgu Deposu raporları, Çoğaltma açılan listesi aracılığıyla çeşitli çoğaltma kümeleri/rolleri arasında Sorgu Deposu verilerini görüntülemenin bir yolunu sağlar. Ayrıca, Nesne gezgini görünümü içinde Sorgu Deposu özelliği düğümü, okunabilir bir ikincil kopyaya bağlıysa Sorgu Deposu'nun geçerli durumunu (READ_CAPTURE_SECONDARY) yansıtır.

Azure SQL Veritabanı'nda okunabilir ikincil telemetri için Sorgu Deposu

için geçerlidir: Azure SQL Veritabanı

Sorgu Deposu çalışma zamanı istatistiklerini Azure tanılama ayarları aracılığıyla akışla aktarırken, telemetri verilerinin çoğaltma kaynağını tanımlamaya yardımcı olmak için iki sütun eklenir:

  • is_primary_b: Verilerin birincil çoğaltmadan mı (true) yoksa ikincil çoğaltmadan mı (false) kaynaklandığını gösteren Boole değeri
  • replica_group_id: Çoğaltma rolüne karşılık gelen bir tamsayı

Bu sütunlar, çoğaltma kümeleri arasında iş yüklerini analiz ederken ölçümleri ve performans verilerini kesinleştirmek için gereklidir. Sorgu Deposu çalışma zamanı istatistiklerini Log Analytics, Event Hubs veya Azure Depolama'ya akışla aktarmak için tanılama ayarlarını yapılandırırken, çoğaltma rolüne göre verileri düzgün bir şekilde segmentlere ayırmak için sorgularınızın ve panolarınızın bu sütunlar için hesaplandığından emin olun. Tanılama ayarlarını ve kullanılabilir ölçümleri yapılandırma hakkında daha fazla bilgi için bkz. Azure İzleyici'de tanılama ayarları.

Önemli

Azure SQL Veritabanı (QPI) için Sorgu Performansı İçgörüleri şu anda kavramı destekliyordoes not.replica_group_id Panoda görüntülenen veriler, tüm replika kaynaklarından çalışma zamanı ve bekleme istatistikleri verilerini birleştirir.

Okunabilir ikincil öğeler için Sorgu Deposu için performansla ilgili dikkat edilmesi gerekenler

İkincil çoğaltmalar tarafından sorgu bilgilerini birincil çoğaltmaya geri göndermek için kullanılan kanal, ikincil çoğaltmaları güncel tutmak için kullanılan kanalla aynıdır. Burada channel ne anlama gelmektedir?

Kullanılabilirlik grubu (HADR) yapılandırmasında, çoğaltmalar birincil ve ikincil çoğaltmalar arasında günlük blokları, onaylar ve durum iletilerini taşıyan özel bir aktarım katmanı kullanarak birbirleriyle eşitlenir. Bu, veri tutarlılığı ve yük devretme hazırlığı sağlar.

Okunabilir ikincil öğeler için Sorgu Deposu etkinleştirildiğinde ayrı bir ağ uç noktası oluşturmaz. Bunun yerine, mevcut aktarım katmanı üzerinde yeni bir mantıksal iletişim yolu oluşturur:

  • Azure SQL Veritabanı (Hiper Ölçek olmayan), Azure SQL Yönetilen Örneği ve SQL Server için bu, yüksek kullanılabilirlik ve olağanüstü durum kurtarma (HADR) Always On aktarım katmanını kullanır.

  • Azure SQL Veritabanı Hiper Ölçeği için Uzak Blob G/Ç aktarım katmanı olarak adlandırılan farklı bir aktarım katmanı kullanılır. Uzak Blob G/Ç taşıma katmanı, hesaplama düğümleri ile Günlük Hizmeti/Sayfa Sunucuları arasındaki iletişim kanalını oluşturur. Uzak Blob G/Ç aktarım katmanı, günlük kayıtlarını ve veri sayfalarını taşımak için güvenilir, şifrelenmiş bir kanal sağlar.

Bu yol, aynı şifrelenmiş oturumu kullanarak normal günlük kaydı trafiğiyle birlikte Sorgu Deposu yürütme verilerini (sorgu metni, planlar, çalışma zamanı/bekleme istatistikleri) çoğullar. Özelliğin kendi yakalama ve alma kuyrukları vardır ve bu kuyruklar herhangi bir çoğaltmanın perspektifinden sorgulanarak sys.database_query_store_internal_state görünümü ile görüntülenebilir.

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

İkincillerden alınan veriler birincil sorgu deposu tablolarında kalıcı hale getirildiğinden depolama gereksinimleri artırılabilir. Yoğun yük altında, aktarım kanalında gecikme veya geri basınç gözlemleyebilirsiniz. Birincilde Sorgu Deposu için geçerli olan geçici sorgu yakalama sınırlamaları ikinciller için de geçerlidir. Sorgu Deposu boyutunu ve yakalama ilkelerini yönetme hakkında daha fazla bilgi ve kılavuz için bkz. Sorgu Deposu'nda en uygun verileri tutma.

Negatif sorgu kimliği/plan kimliği görünürlüğü

Negatif kimlikler, birincil kimlikte kalıcı olmadan önce ikincillerdeki sorgular/planlar için geçici bellek içi yer tutucuları gösterir.

Sorgu Deposu verileri, okunabilir ikincil kopyalardan birincil sunucuya kalıcı hale gelmeden önce, sorgular ve planlar, yerel bellek içi temsil olan Sorgu Deposu'nun (MEMORYCLERK_QUERYDISKSTORE_HASHMAP) içinde geçici tanımlayıcılar atanabilir. Sorgu ve plan kimlikleri negatif sayılar şeklinde görünebilir ve birincil kopya, sorgunun yapılandırılmış yakalama modu gereksinimlerini karşıladığını belirledikten sonra bu da yetkili bir tanımlayıcı atayana kadar yer tutucudur. Özel yakalama ilkesi varsa, sistem kataloğu görünümünü sorgulayarak sys.database_query_store_options karşılanması gereken gereksinimleri gözden geçirebilirsiniz.

SELECT query_capture_mode_desc,
       capture_policy_execution_count,
       capture_policy_total_compile_cpu_time_ms,
       capture_policy_total_execution_cpu_time_ms
FROM sys.database_query_store_options;

Sorgu yakalanmış olarak belirlendikten sonra çalışma zamanı/bekleme istatistikleri ve planı kalıcı hale gelebilir ve yerel geçici kimlikler pozitif kimliklerle değiştirilir. Bu ayrıca plan zorlama veya ipucu oluşturma özelliklerini kullanmanıza da olanak tanır.

İlgili içerik

  • Last updated on