Udostępnij za pomocą

Repozytorium zapytań dla czytelnych replik wtórnych

Dotyczy: SQL Server 2025 (17.x) Azure SQL Database

Magazyn zapytań dla odczytywanych replik umożliwia uzyskiwanie wglądu w magazyn zapytań dla obciążeń działających na replikach wtórnych. Po włączeniu, repliki pomocnicze przesyłają informacje o wykonywaniu zapytań (takie jak czas wykonania i statystyki oczekiwania) do repliki podstawowej, gdzie dane są utrwalane w Query Store i udostępniane we wszystkich replikach.

Wsparcie platform

Obecnie funkcja Magazynu zapytań dla czytelnych plików pomocniczych jest dostępna i obsługiwana w środowisku produkcyjnym w programie SQL Server 2025 (17.x) i w usłudze Azure SQL Database. Począwszy od serwera SQL Server 2025 (17.x) i w usłudze Azure SQL Database, Query Store dla czytelnych replik jest domyślnie włączony.

W programie SQL Server 2022 (16.x) magazyn zapytań dla pomocniczych z możliwością odczytu pozostaje w wersji zapoznawczej i dlatego nie jest obsługiwany w środowisku produkcyjnym i jest domyślnie wyłączony. Aby włączyć magazyn zapytań dla replik drugorzędnych z możliwością odczytu w SQL Server 2022 (wersji 16.x), flaga śledzenia 12606 musi być włączona dla podstawowej i wszystkich replik drugorzędnych z możliwością odczytu. Flaga śledzenia 12606 nie jest przeznaczona dla wdrożeń produkcyjnych opartych na programie SQL Server 2022 (16.x). Aby uzyskać więcej informacji, zobacz informacje o wersji programu SQL Server 2022. W przypadku programu SQL Server 2025 (17.x) funkcja Magazynu zapytań w funkcjach pomocniczych z możliwością odczytu jest domyślnie włączona .

Usługa Azure SQL Database, wszystkie bazy danych są automatycznie rejestrowane i włączone, aby obsługiwać magazyn zapytań dla funkcji odczytu zapasowych baz danych, w obsługiwanych warstwach usług i scenariuszach wysokiej dostępności. Obecnie ta funkcja nie jest obsługiwana w hiperskali usługi Azure SQL Database.

Obecnie ta funkcja nie jest obsługiwana w usłudze Azure SQL Managed Instance ani w bazie danych SQL w usłudze Microsoft Fabric.

Obsługiwane scenariusze wysokiej dostępności

  • Przed użyciem magazynu zapytań dla dostępnych do odczytu serwerów drugorzędnych w wystąpieniu programu SQL Server 2025 (17.x), należy skonfigurować grupę dostępności Always On.

  • W przypadku usługi Azure SQL Database Magazyn zapytań dla czytelnych replik obsługuje następujące poziomy usług.

    • Ogólnego przeznaczenia z aktywną replikacją geograficzną (bez wbudowanych replik wysokiej dostępności; wymaga konfiguracji replikacji geograficznej w celu obsługi pomocniczej)
    • Premium (obejmuje wbudowane repliki zapewniające wysoką dostępność; obsługuje również aktywną replikację geograficzną)
    • Krytyczne dla działania firmy (obejmuje wbudowane repliki o wysokiej dostępności; obsługiwana jest również aktywna replikacja geograficzna)

Włącz magazyn zapytań dla odczytywanych replik wtórnych

Jeśli magazyn zapytań nie jest jeszcze włączony i w trybie READ_WRITE na repliki podstawowej, należy włączyć magazyn zapytań przed kontynuowaniem. Wykonaj następujący skrypt dla każdej żądanej bazy danych w repliki podstawowej:

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

Aby włączyć magazyn zapytań na wszystkich możliwych do odczytu replikach wtórnych, połącz się z repliką podstawową i wykonaj następujący skrypt dla każdej bazy danych, która ma być skonfigurowana do korzystania z tej funkcji.

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

Włączanie automatycznej korekty planu dla replik pomocniczych

Dotyczy: SQL Server 2022 (16.x) i nowsze wersje, Azure SQL Database.

Po włączeniu magazynu zapytań dla replik pomocniczych można opcjonalnie włączyć automatyczne dostrajanie, aby umożliwić automatyczne poprawianie planów i wymuszanie ich na replikach pomocniczych. Dzięki temu optymalizator zapytań może automatycznie identyfikować i rozwiązywać problemy z wydajnością zapytań spowodowane regresjami planu wykonywania w replikach pomocniczych.

Aby włączyć automatyczną korektę planu dla replik pomocniczych, połącz się z repliką podstawową i wykonaj następujący skrypt dla każdej żądanej bazy danych:

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

Wyłącz magazyn zapytań dla replik dodatkowych

Aby wyłączyć funkcję Magazyn zapytań dla replik pomocniczych na wszystkich replikach pomocniczych, połącz się z bazą danych na replice master i wykonaj poniższy skrypt dla każdej żądanej bazy danych.

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

Upewnij się, że magazyn zapytań jest włączony na replikach pomocniczych

Możesz sprawdzić, czy magazyn zapytań jest włączony na replice secondary pomocniczej, łącząc się z bazą danych i wykonując następującą instrukcję języka T-SQL.

SELECT desired_state_desc,
       actual_state_desc,
       readonly_reason
FROM sys.database_query_store_options;

Wyniki zapytań względem widoku katalogu sys.database_query_store_options powinny wskazywać, że rzeczywisty stan Query Store wynosi READ_CAPTURE_SECONDARY, przy czym readonly_reason ma wartość 8.

desired_state_desc actual_state_desc readonly_reason
READ_CAPTURE_SECONDARY READ_CAPTURE_SECONDARY 8

Uwagi

Terminologia

Zestaw replik jest definiowany jako replika odczytu/zapisu bazy danych (podstawowa) i co najmniej jedna replika tylko do odczytu (pomocnicza) traktowana jako jednostka logiczna. Rola w tym kontekście odnosi się do roli określonej repliki. Gdy replika pełni rolę podstawową, jest repliką do odczytu/zapisu, która może wykonywać zarówno modyfikacje danych, jak i operacje odczytu. Gdy replika jest skonfigurowana do wykonywania tylko działań tylko do odczytu, jest ona obsługiwana w roli pomocniczej (pomocnicza, pomocnicza, pomocnicza geograficzna, pomocnicza lokalizacja geograficzna, pomocnicza geograficzna ha pomocnicza). Role mogą się zmieniać podczas planowanych lub nieplanowanych zdarzeń failover; w takich przypadkach główna może stać się zapasową lub odwrotnie.

Obecnie obsługiwane role to:

  • Primary
  • Secondary
  • Wtórny geograficzny
  • Geo HA wtórny
  • Nazwana replika

Jak to działa

Dane przechowywane na temat zapytań można analizować jako obciążenia na podstawie roli. Magazyn zapytań dla czytelnych replik wtórnych umożliwia monitorowanie wydajności dowolnego jednoznacznego obciążenia tylko do odczytu, które może być wykonywane względem replik wtórnych. Dane są agregowane na poziomie roli. Na przykład konfiguracja rozproszonych grup dostępności programu SQL Server może obejmować następujące elementy:

  • Jedna replika podstawowa, część grupy dostępności 1 (AG1)

  • Dwie lokalne repliki wtórne są także częścią AG1

  • Jedna zdalna replika podstawowa w innej lokalizacji, która jest częścią oddzielnej grupy dostępności (AG2). Jeśli chodzi o terminologię SQL Server, jest on również często określany jako globalny forwarder, jednak funkcja Magazynu zapytań dla czytelnych pomocniczych replik rozpozna i odwołuje się do niej jako replika, zakładając, że jest to geograficznie rozproszona replika pomocnicza Geo secondary.

Jeśli grupy AG1 i AG2 są skonfigurowane tak, aby zezwalały na połączenia tylko do odczytu, gdy obciążenie tylko do odczytu jest wykonywane względem jednej z replik pomocniczych grupy AG1, statystyki dotyczące wykonywania zapytań są wysyłane do podstawowej repliki grupy AG1 i agregowane oraz utrwalane jako dane wygenerowane z roli secondary przed wysłaniem tych danych z powrotem do wszystkich replik pomocniczych, w tym globalnego forwardera w AG2. Po wykonaniu oddzielnego obciążenia względem podstawowej repliki AG2, globalny forwarder wysyła dane z powrotem do podstawowej repliki AG1, gdzie są one utrwalane jako dane wygenerowane z roli Geo secondary.

Z perspektywy obserwacji widok wykazu systemu sys.query_store_runtime_stats jest rozszerzony, aby ułatwić określenie roli, z której pochodzą statystyki wykonywania. Istnieje związek między tym widokiem a widokiem katalogu systemowego sys.query_store_replicas, który może zapewnić bardziej przyjazną nazwę dla zadania. W programie SQL Server kolumna replica_name jest NULL. Jednak dla warstwy usługi Hiperskala kolumna replica_name jest wypełniana, jeśli istnieje nazwana replika i jest używana wyłącznie do obciążeń odczytu.

Przykładem zapytania T-SQL, które może służyć do zapewnienia ogólnej analizy 50 najważniejszych zapytań w ciągu ostatnich 8 godzin, które zużywały zasoby procesora CPU ze wszystkich replik:

-- 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;

Raporty magazynu zapytań w programie SQL Server Management Studio (SSMS) 21 i nowszych wersjach udostępniają listę rozwijaną repliki , która umożliwia wyświetlanie danych magazynu zapytań w różnych zestawach replik/rolach. Ponadto w widoku Eksploratora obiektów węzeł "Magazyn zapytań" odzwierciedla bieżący stan Magazynu zapytań (tj. READ_CAPTURE_SECONDARY) w przypadku połączenia z pomocniczą repliką z możliwością odczytu.

Magazyn zapytań dla czytelnych danych telemetrycznych pomocniczych w usłudze Azure SQL Database

Dotyczy: Azure SQL Database

W przypadku przesyłania strumieniowego statystyk środowiska uruchomieniowego magazynu zapytań za pośrednictwem ustawień diagnostycznych platformy Azure są uwzględniane dwie kolumny ułatwiające zidentyfikowanie źródła danych telemetrycznych repliki:

  • is_primary_b: Wartość logiczna wskazująca, czy dane pochodzą z repliki podstawowej (true) lub repliki pomocniczej (false)
  • replica_group_id: liczba całkowita odpowiadająca roli repliki

Te kolumny są niezbędne do uściślania metryk i danych wydajności podczas analizowania obciążeń w zestawach replik. Podczas konfigurowania ustawień diagnostycznych w celu strumieniowego przesyłania statystyk czasu wykonywania Query Store do Log Analytics, Event Hubs lub Azure Storage, upewnij się, że Twoje zapytania i pulpity nawigacyjne uwzględniają te kolumny w celu właściwego segmentowania danych według roli repliki. Aby uzyskać więcej informacji na temat konfigurowania ustawień diagnostycznych i dostępnych metryk, zobacz Ustawienia diagnostyczne w usłudze Azure Monitor.

Ważne

Analiza wydajności zapytań dla usługi Azure SQL Database (QPI)does not obecnie obsługuje replica_group_id koncepcję. Dane wyświetlane na pulpicie będą agregować wszystkie dane dotyczące czasu wykonania i statystyki oczekiwania z wszystkich replik.

Zagadnienia dotyczące wydajności magazynu zapytań dla możliwych do odczytu pomocniczych

Kanał używany przez repliki pomocnicze do wysyłania informacji zapytania z powrotem do repliki podstawowej jest tym samym kanałem używanym do aktualizowania replik pomocniczych. channel Co to znaczy tutaj?

W konfiguracji grupy dostępności (HADR) repliki są synchronizowane ze sobą przy użyciu dedykowanej warstwy transportu, która przenosi bloki dziennika, potwierdzenia i komunikaty o stanie między repliką podstawową a repliką pomocniczą. Zapewnia to spójność danych i gotowość do pracy w trybie failover.

Gdy Query Store dla czytelnych replik zapasowych jest włączony, nie tworzy osobnego punktu końcowego w sieci. Zamiast tego ustanawia nową logiczną ścieżkę komunikacji na istniejącej warstwie transportu:

  • W przypadku usługi Azure SQL Database (oprócz opcji Hiperskala), usługi Azure SQL Managed Instance i programu SQL Server wykorzystywana jest warstwa transportowa Always On zapewniająca wysoką dostępność i odzyskiwanie po awarii (HADR).

  • Dla usługi Azure SQL Database Hyperscale używana jest inna warstwa transportu, nazywana zdalną warstwą transportową Remote Blob I/O. Warstwa transportu zdalnego we/wy obiektów blob jest kanałem komunikacji między węzłami obliczeniowymi a serwerami usługi dziennika/strony. Warstwa transportu zdalnego we/wy obiektów blob zapewnia niezawodny, zaszyfrowany kanał do przenoszenia rekordów dzienników i stron danych.

Ta ścieżka multiplikuje dane wykonywania Query Store (tekst zapytania, plany, statystyki czasu wykonywania/oczekiwania) obok normalnego przepływu dziennika przy użyciu tej samej zaszyfrowanej sesji. Funkcja ma własne kolejki przechwytywania i odbierania, które można wyświetlić, wykonując zapytanie o widok z perspektywy dowolnej repliki:

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

Dane z serwerów pomocniczych są utrwalane w tych samych tabelach Query Store na serwerze głównym, co może zwiększyć wymagania dotyczące magazynowania. W przypadku dużego obciążenia możesz obserwować opóźnienia lub ciśnienie wsteczne w kanale transportowym. Te same ograniczenia przechwytywania zapytań ad hoc, które mają zastosowanie do magazynu zapytań na głównym serwerze, mają również zastosowanie do serwerów pomocniczych. Aby uzyskać więcej informacji i wskazówek dotyczących zarządzania rozmiarem magazynu zapytań i zasadami przechwytywania, zobacz Przechowywanie najbardziej odpowiednich danych w magazynie zapytań.

Widoczność negatywnego identyfikatora zapytania/identyfikatora planu

Ujemne identyfikatory wskazują tymczasowe miejsce w pamięci dla zapytań/planów na serwerach pomocniczych przed zapisaniem na serwerze głównym.

Zanim dane magazynu zapytań zostaną utrwalone w podstawowej replice pomocniczej z możliwością odczytu, zapytania i plany mogą mieć przypisane tymczasowe identyfikatory w ramach lokalnej reprezentacji magazynu zapytań w pamięci — MEMORYCLERK_QUERYDISKSTORE_HASHMAP. Identyfikatory zapytań i planów mogą pojawić się jako liczby ujemne i są symbolami zastępczymi, dopóki replika podstawowa nie przypisze autorytatywnego identyfikatora, co ma miejsce po tym, jak Query Store stwierdzi, że zapytanie spełnia skonfigurowane wymagania dotyczące trybu przechwytywania. Jeśli obowiązują zasady przechwytywania niestandardowego , możesz przejrzeć wymagania, które muszą zostać spełnione, wykonując zapytanie dotyczące widoku wykazu systemowego sys.database_query_store_options .

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;

Po oznaczeniu zapytania jako przechwycone, jego statystyki czasu wykonania/statystyki oczekiwania i plan mogą być utrwalane, a identyfikatory lokalne tymczasowe są zastępowane pozytywnymi identyfikatorami. Umożliwia to również korzystanie z możliwości wymuszania lub sugerowania planu.

Treści powiązane

  • Last updated on