Endlich: Query Store auch auf Read-Only Replikaten

Früher konntest Du Query Store nur auf dem Primärserver nutzen.
Die sekundären Replikate? Blackbox.
Kein Einblick in Abfragen. Keine Laufzeiten. Keine Ausreißer sichtbar.

Seit SQL Server 2022: Query Store ist auch auf Read-Only-Replikaten verfügbar.
Du kannst endlich sehen, was Deine Reports, Schnittstellen und Benutzer da wirklich treiben.

Warum das wichtig ist

• Du erkennst Performance-Probleme auch auf der Reporting-Seite
• Du siehst Unterschiede zwischen Replikat und Primär (z. B. durch Statistiken)
• Du kannst Queries gezielt optimieren, bevor sich jemand beschwert
• Du kannst Lastverteilung messbar machen

Aktivierung des Query Store für ein sekundäres Replikat

Ab SQL Server 2022 brauchst Du nur einen Parameter:

ALTER DATABASE DeineDatenbank 
SET QUERY_STORE = ON 
(READ_WRITE, 
 OPERATION_MODE = READ_ONLY_SECONDARY);

Alternativ (z. B. über SSMS oder Skript):

ALTER DATABASE DeineDatenbank 
SET QUERY_STORE (OPERATION_MODE = READ_ONLY_SECONDARY);

Wichtig: Das geht nur, wenn die Datenbank im sekundären Modus läuft.
Du musst also direkt auf dem Replikat arbeiten.

Abfragen gegen Query Store am Replikat

Alles, was Du vom Primärsystem kennst, geht jetzt auch hier:

SELECT TOP 10 
    qs.query_id,
    qt.query_sql_text,
    rs.avg_duration,
    rs.execution_type_desc
FROM sys.query_store_query_text qt
JOIN sys.query_store_query qs ON qt.query_text_id = qs.query_text_id
JOIN sys.query_store_plan p ON qs.query_id = p.query_id
JOIN sys.query_store_runtime_stats rs ON p.plan_id = rs.plan_id
ORDER BY rs.avg_duration DESC;

Oder konkret:

-- Abfragen mit vielen Reads
SELECT TOP 10 
    qt.query_sql_text,
    SUM(rs.total_logical_reads) AS Reads
FROM sys.query_store_query_text qt
JOIN sys.query_store_query q ON qt.query_text_id = q.query_text_id
JOIN sys.query_store_plan p ON q.query_id = p.query_id
JOIN sys.query_store_runtime_stats rs ON p.plan_id = rs.plan_id
GROUP BY qt.query_sql_text
ORDER BY Reads DESC;

So siehst Du, welche Reports oder Power BI-Modelle Deinen Replikat-Server stressen.

Unterschiede zwischen Primär und Sekundär

Achte auf:

• unterschiedliche Ausführungspläne (andere Statistiken, andere Caches)
• längere Wartezeiten (z. B. durch Netzwerk oder Lesezugriffe auf kalte Daten)
• inkonsistente Parameter Sniffing-Effekte

Beispiel:

-- Vergleich Plan Hash auf Primär vs. Sekundär
SELECT query_id, plan_id, query_plan_hash
FROM sys.query_store_plan
WHERE query_id = 1234;

Wenn die query_plan_hash unterschiedlich ist, weißt Du, warum es ruckelt.

Tabelle: Unterschiede Query Store vorher / jetzt

Feature	Früher (bis SQL 2019)	Jetzt (ab SQL 2022)
Query Store auf Replikat	Nicht möglich	Ja, vollständig
Zugriff auf Read-Only-Workloads	Nur über Logging / Tracing	Query Store möglich
Plananalyse pro Standort	Nur Primär	Jetzt auch Sekundär
Vergleich zwischen Replikaten	Manuell mit Aufwand	Direkt über T-SQL
Nutzung in Azure SQL MI / AG	Teilweise	Vollständig unterstützt

Was ich regelmäßig prüfe

• Query Store Größe und Speicherdauer
• Welche Queries kommen von Report-Usern?
• Welche Pläne weichen ab?
• Wo sind die meisten Leseoperationen?
• Gibt es lange Laufzeiten, obwohl CPU kaum genutzt wird?

-- Query Store Größe prüfen
SELECT actual_state_desc, readonly_reason
FROM sys.database_query_store_options;

Mein trockener Schlussgedanke

Du schiebst die Reports auf die Replikate, damit’s schneller läuft.
Aber wenn Du da nicht reinguckst, weißt Du nicht, ob es das wirklich tut.

Jetzt kannst Du.
Also: Mach’s.