Aktive sekundäre Replikate: Lesbare sekundäre Replikate (AlwaysOn-Verfügbarkeitsgruppen)

Die Funktionen für aktive sekundäre Replikate in AlwaysOn-Verfügbarkeitsgruppen umfassen Unterstützung für den schreibgeschützten Zugriff auf ein oder mehrere sekundäre Replikate (lesbare sekundäre Replikate). Lesbare sekundäre Replikate lassen den schreibgeschützten Zugriff auf alle eigenen sekundären Datenbanken zu. Bei lesbaren sekundären Datenbanken ist jedoch kein Schreibschutz festgelegt. Sie sind dynamisch. Eine sekundäre Datenbank wird geändert, wenn Änderungen an der zugehörigen primären Datenbank auf die sekundäre Datenbank angewendet werden. Bei einem typischen sekundären Replikat liegen die Daten in den sekundären Datenbanken beinahe in Echtzeit vor. Weiterhin werden Volltextindizes mit den sekundären Datenbanken synchronisiert. In vielen Fällen beträgt die Datenlatenz zwischen einer primären Datenbank und der zugehörigen sekundären Datenbank nur wenige Sekunden.

Sicherheitseinstellungen, die in den primären Datenbanken auftreten, werden in den sekundären Datenbanken beibehalten. Dazu gehören Benutzer, Datenbankrollen und Anwendungsrollen sowie die jeweiligen zugehörigen Berechtigungen und die transparente Datenverschlüsselung (TDE), wenn diese in der primären Datenbank aktiviert ist.

Hinweis
Sie können zwar keine Daten in sekundäre Datenbanken schreiben, aber in Datenbanken mit Lese-/Schreibzugriff auf der Serverinstanz, auf der die sekundären Replikate gehostet werden, einschließlich Benutzerdatenbanken und Systemdatenbanken, wie tempdb.

AlwaysOn-Verfügbarkeitsgruppen unterstützt auch das Umleiten von Verbindungsanforderungen für beabsichtigte Lesevorgänge an ein lesbares sekundäres Replikat (schreibgeschütztes Routing). Informationen zum schreibgeschützten Routing finden Sie unter Verwenden eines Listeners zum Herstellen einer Verbindung mit einem schreibgeschützten sekundären Replikat (schreibgeschütztes Routing).

In diesem Thema:

• Vorteile

• Voraussetzungen für die Verfügbarkeitsgruppe

• Einschränkungen

• Überlegungen zur Leistung

• Aspekte der Kapazitätsplanung

• Verwandte Aufgaben

• Verwandte Inhalte

Vorteile

Die Weiterleitung schreibgeschützter Verbindungen an lesbare sekundäre Replikate bietet die folgenden Vorteile:

• Lädt die sekundären schreibgeschützten Arbeitsauslastungen vom primären Replikat, wodurch dessen Ressourcen für unternehmenswichtige Arbeitsauslastungen bewahrt werden. Falls Sie über unternehmenswichtige Arbeitsauslastung oder die Arbeitsauslastung verfügen, die keine Wartezeit tolerieren kann, sollten Sie sie auf dem primären Replikat ausführen.

• Verbessert die Rendite für die Systeme, auf denen lesbare sekundäre Replikate gehostet werden.

Außerdem bieten lesbare sekundäre Replikate folgendermaßen stabile Unterstützung für schreibgeschützte Vorgänge:

• Mit temporären Statistiken werden auf einer lesbaren sekundären Datenbank schreibgeschützte Abfragen optimiert. Weitere Informationen finden Sie unter Statistiken für Datenbanken mit schreibgeschütztem Zugriff später in diesem Thema.

• Schreibgeschützte Arbeitsauslastungen verwenden die Zeilenversionsverwaltung, um den blockierenden Konflikt der sekundären Datenbanken aufzuheben. Alle Abfragen an den sekundären Datenbanken werden automatisch der Momentaufnahme-Isolationstransaktionsebene zugeordnet, selbst wenn andere Transaktionsisolationsebenen explizit festgelegt sind. Zudem werden alle Sperrhinweise ignoriert. Dies schließt Leser-/Schreiberkonflikte aus.

[Nach oben]

Voraussetzungen für die Verfügbarkeitsgruppe

• Lesbare sekundäre Replikate (erforderlich)

  Der Datenbankadministrator muss mindestens ein Replikat so konfigurieren, dass es bei Ausführung in der sekundären Rolle alle Verbindungen (nur für den schreibgeschützten Zugriff) oder aber nur Verbindungen für beabsichtigte Lesevorgänge zulässt.

  Hinweis
  Optional kann der Datenbankadministrator eines der Verfügbarkeitsreplikate so konfigurieren, dass schreibgeschützte Verbindungen bei Ausführung in der primären Rolle ausgeschlossen werden.

  Weitere Informationen finden Sie unter Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server).

• Verfügbarkeitsgruppenlistener

  Um schreibgeschütztes Routing zu unterstützen, muss eine Verfügbarkeitsgruppe einen Verfügbarkeitsgruppenlistener besitzen. Der schreibgeschützte Client muss die eigenen Verbindungsanforderungen an diesen Listener weiterleiten, und in der Verbindungszeichenfolge des Clients muss die Anwendungsabsicht als "schreibgeschützt" angeben sein. Es muss sich also um Verbindungsanforderungen für beabsichtigte Lesevorgänge handeln.

• Schreibgeschütztes Routing

  Als schreibgeschütztes Routing wird die Fähigkeit von SQL Server bezeichnet, eingehende Verbindungsanforderungen für beabsichtigte Lesevorgänge, die an einen Verfügbarkeitsgruppenlistener gerichtet sind, an ein verfügbares lesbares sekundäres Replikat weiterzuleiten. Für schreibgeschütztes Routing gelten folgende Voraussetzungen:

  • Zur Unterstützung von schreibgeschütztem Routing muss für lesbare sekundäre Replikate eine URL für schreibgeschütztes Routing angegeben werden. Diese URL wird nur wirksam, wenn das lokale Replikat unter der sekundären Rolle ausgeführt wird. Die URL für schreibgeschütztes Routing muss nach Bedarf replikatweise angegeben werden. Jede URL für schreibgeschütztes Routing wird zum Weiterleiten von Verbindungsanforderungen für beabsichtigte Lesevorgänge an ein bestimmtes lesbares sekundäres Replikat verwendet. In der Regel wird jedem lesbaren sekundären Replikat eine URL für schreibgeschütztes Routing zugewiesen.

  • Jedes Verfügbarkeitsreplikat, das als primäres Replikat schreibgeschütztes Routing unterstützen soll, erfordert das primäre Replikat eine Liste für schreibgeschütztes Routing. Eine Liste für schreibgeschütztes Routing wird nur wirksam, wenn das lokale Replikat unter der primären Rolle ausgeführt wird. Diese Liste muss nach Bedarf replikatweise angegeben werden. Normalerweise enthält jede Liste für schreibgeschütztes Routing jede URL für schreibgeschütztes Routing, wobei die URL des lokalen Replikats am Ende der Liste steht.

    Hinweis
    Verbindungsanforderungen für beabsichtigte Lesevorgänge werden an das erste verfügbare lesbare sekundäre Replikat auf der Liste für schreibgeschütztes Routing des aktuellen primären Replikats weitergeleitet. Es erfolgt kein Lastenausgleich.

  Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Routing für eine Verfügbarkeitsgruppe (SQL Server).

Hinweis
Weitere Informationen zu Verfügbarkeitsgruppenlistenern und zum schreibgeschützten Routing finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

[Nach oben]

Einschränkungen

Folgende Vorgänge werden nicht vollständig unterstützt:

• Sobald ein lesbares sekundäres Replikat mit der Verfügbarkeitsgruppe verknüpft wird, kann das sekundäre Replikat beginnen, Verbindungen zu seinen sekundären Datenbanken zu akzeptieren. Wenn jedoch aktive Transaktionen auf einer primären Datenbank vorhanden sind, sind Zeilenversionen nicht sofort vollständig auf der entsprechenden sekundären Datenbank verfügbar. Für jegliche aktiven Transaktionen, die bei der Konfiguration des sekundären Replikats auf dem primären Replikat vorhanden waren, muss ein Commit oder ein Rollback durchgeführt werden. Bis dieser Prozess abgeschlossen ist, ist die Zuordnung der Transaktionsisolationsstufe auf der sekundären Datenbank unvollständig, und Abfragen werden vorübergehend blockiert.

  Hinweis
  Die Ausführung einer langen Transaktion wirkt sich auf die Anzahl der erhaltenen Versionszeilen aus.

• Die Änderungsnachverfolgung und Change Data Capture werden nicht für sekundäre Datenbanken unterstützt, die zu einem lesbaren sekundären Replikat gehören:

  • Die Änderungsnachverfolgung ist auf sekundären Datenbanken explizit deaktiviert.

  • Change Data Capture kann auf einer sekundären Datenbank aktiviert werden, dies wird aber nicht unterstützt.

• Da Lesevorgänge der Ebene von Momentaufnahmeisolations-Transaktionen zugeordnet werden, kann das Cleanup von inaktiven Datensätzen auf dem primären Replikat durch Transaktionen auf einem oder mehreren sekundären Replikaten blockiert werden. Mit der Bereinigungsaufgabe für inaktive Datensätze werden die inaktiven Datensätze auf dem primären Replikat automatisch bereinigt, wenn sie von sekundären Replikaten nicht mehr benötigt werden. Dies ist analog zur Ausführung von Transaktionen auf dem primären Replikat. Im äußersten Fall müssen Sie Lese-Abfragen mit langer Laufzeit auf der sekundären Datenbank abbrechen, die die Bereinigung der inaktiven Datensätze blockieren. Hinweis: Die Bereinigung des inaktiven Elements kann blockiert werden, wenn das sekundäre Replikat getrennt oder die Datenverschiebung auf der sekundären Datenbank angehalten wird. Mit diesem Status wird zudem die Protokollkürzung verhindert. Wenn dieser Status weiterhin auftritt, sollten Sie demnach diese sekundäre Datenbank aus der Verfügbarkeitsgruppe entfernen.

• Beim DBCC SHRINKFILE-Vorgang kann auf dem primären Replikat ein Fehler auftreten, wenn die Datei inaktive Datensätze enthält, die weiterhin auf einem sekundären Replikat benötigt werden.

Hinweis

Wenn Sie die dynamische Verwaltungssicht sys.dm_db_index_physical_stats auf einer Serverinstanz abfragen, die ein lesbares sekundäres Replikat hostet, kann ein Problem durch Blockierung von REDO auftreten. Das liegt daran, dass diese dynamische Verwaltungssicht eine IS-Sperre für die angegebene Benutzertabelle oder Sicht abruft, die Anforderungen durch einen REDO-Thread für eine X-Sperre für diese Benutzertabelle oder Sicht blockieren kann.

[Nach oben]

Überlegungen zur Leistung

In diesem Abschnitt werden mehrere Überlegungen zur Leistung für lesbare sekundäre Datenbanken erläutert.

In diesem Abschnitt:

• Datenlatenz

• Auswirkungen auf schreibgeschützte Arbeitsauslastungen

• Indizierung

• Statistiken für Datenbanken mit schreibgeschütztem Zugriff

Datenlatenz

Das Implementieren von schreibgeschütztem Zugriff in sekundäre Replikate ist hilfreich, sofern Ihre schreibgeschützten Arbeitsauslastungen eine gewisse Datenwartezeit tolerieren können. Führen Sie in Situationen mit inakzeptabler Datenlatenz ggf. schreibgeschützte Arbeitsauslastungen für das primäre Replikat aus.

Vom primären Replikat werden Protokolldatensätze der Änderungen in der primären Datenbank an die sekundären Replikate gesendet. Auf der jeweiligen sekundären Datenbank werden die Protokolldatensätze von einem dedizierten REDO-Thread angewendet. Auf einer schreibgeschützten sekundären Datenbank erscheint eine angegebene Datenänderung erst in den Abfrageergebnissen, wenn der Protokolldatensatz, der die Änderung enthält, auf die sekundäre Datenbank angewendet und für die Transaktion auf der primären Datenbank ein Commit ausgeführt wurde.

Dies weist auf eine gewisse Latenz zwischen den primären und sekundären Replikaten hin, wobei es sich in der Regel nur um wenige Sekunden handelt. In außergewöhnlichen Fällen jedoch, beispielsweise bei Netzwerkproblemen, die den Durchsatz reduzieren, kann die Wartezeit signifikant werden. Die Wartezeit nimmt bei E/A-Engpässen und bei angehaltener Datenverschiebung zu. Zur Überwachung einer angehaltenen Datenverschiebung können Sie das AlwaysOn-Dashboard oder die dynamische sys.dm_hadr_database_replica_states-Verwaltungssicht verwenden.

Auswirkungen auf schreibgeschützte Arbeitsauslastungen

Wenn Sie ein sekundäres Replikat für schreibgeschützten Zugriff konfigurieren, belegen die schreibgeschützten Arbeitsauslastungen auf den sekundären Datenbanken Systemressourcen, z. B. CPU und E/A aus REDO-Threads, insbesondere wenn die schreibgeschützten Arbeitsauslastungen äußerst E/A-intensiv sind.

Schreibgeschützte Arbeitsauslastungen auf den sekundären Replikaten können zudem Änderungen der Datendefinitionssprache (DDL) blockieren, die durch Protokolldatensätze übernommen werden. Obwohl die Lesevorgänge wegen der Zeilenversionsverwaltung über keine gemeinsamen Sperren verfügen, basieren diese Vorgänge auf Schemastabilitätssperren. Dadurch werden u. U. REDO-Vorgänge blockiert, die DDL-Änderungen anwenden.

Beachten Sie die bewährten Methoden zur Erstellung von Abfragen und üben Sie diese Methoden in den sekundären Datenbanken. Planen Sie beispielsweise Abfragen mit langer Laufzeit wie Datenaggregationen in Zeiträumen mit geringer Aktivität.

Hinweis
Falls ein REDO-Thread von Abfragen auf einem sekundären Replikat blockiert wird, wird das sqlserver.lock_redo_blocked XEvent ausgelöst.

Indizierung

Um schreibgeschützte Arbeitsauslastungen auf den lesbaren sekundären Replikaten zu optimieren, können Sie ggf. Indizes in den Tabellen der sekundären Datenbanken erstellen. Da Sie keine Schema- oder Datenänderungen auf den sekundären Datenbanken vornehmen können, erstellen Sie Indizes in den primären Datenbanken, und lassen Sie die Übertragung der Änderungen auf die sekundäre Datenbank mittels REDO-Prozess zu.

Zur Überwachung der Indexnutzungsaktivität auf einem sekundären Replikat fragen Sie die Spalten user_seeks, user_scans und user_lookups der dynamischen sys.dm_db_index_usage_stats-Verwaltungssicht ab.

Statistiken für Datenbanken mit schreibgeschütztem Zugriff

Statistiken zu Spalten von Tabellen und indizierten Sichten werden verwendet, um Abfragepläne zu optimieren. Bei Verfügbarkeitsgruppen werden Statistiken, die in den primären Datenbanken erstellt und verwaltet werden, automatisch in den sekundären Datenbanken beibehalten, wenn die Transaktionsprotokoll-Datensätze angewendet werden. Die schreibgeschützte Arbeitsauslastung auf den sekundären Datenbanken benötigt möglicherweise andere Statistiken als die, die auf den primären Datenbanken erstellt werden. Da sekundäre Datenbanken jedoch auf schreibgeschützten Zugriff beschränkt sind, können Statistiken nicht in den sekundären Datenbanken erstellt werden.

Zur Behebung dieses Problems erstellt und verwaltet das sekundäre Replikat temporäre Statistiken für sekundäre Datenbanken in tempdb. Das Suffix _readonly_database_statistic wird dem temporären Statistiknamen angefügt, um die temporären Statistiken von den dauerhaften Statistiken zu unterscheiden, die in der primären Datenbank beibehalten werden.

Nur SQL Server kann temporäre Statistiken erstellen und aktualisieren. Sie können jedoch temporäre Statistiken löschen und ihre Eigenschaften mit den gleichen Tools überwachen, die Sie für dauerhafte Statistiken verwenden:

• Löschen Sie temporären Statistiken mit der Anweisung DROP STATISTICS Transact-SQL.

• Überwachen Sie Statistiken mit den Katalogsichten sys.stats und sys.stats_columns. sys_stats beinhaltet eine Spalte, is_temporary. Damit wird angegeben, welche Statistiken dauerhaft und welche temporär sind.

Weitere Informationen zu SQL Server-Statistiken finden Sie unter Statistik.

In diesem Abschnitt:

• Veraltete dauerhafte Statistiken in sekundären Datenbanken

• Einschränkungen

Veraltete dauerhafte Statistiken in sekundären Datenbanken

SQL Server erkennt, wenn dauerhafte Statistiken in einer sekundären Datenbank veraltet sind. Änderungen an den dauerhaften Statistiken können aber nur durch Änderungen an der primären Datenbank vorgenommen werden. Zur Abfrageoptimierung erstellt SQL Server temporäre Statistiken auf der sekundären Datenbank und verwendet diese Statistiken statt der veralteten dauerhaften Statistiken.

Wenn die dauerhaften Statistiken auf der primären Datenbank aktualisiert werden, bestehen sie automatisch auf der sekundären Datenbank fort. Dann verwendet SQL Server die aktualisierten dauerhaften Statistiken, die aktueller als die temporären Statistiken sind.

Wenn die Verfügbarkeitsgruppe ein Failover ausführt, werden temporäre Statistiken auf allen sekundären Replikaten gelöscht.

Einschränkungen

• Da temporäre Statistiken in tempdb gespeichert werden, werden durch einen Neustart des SQL Server-Diensts alle temporären Statistiken entfernt.

• Das Suffix _readonly_database_statistic ist für von SQL Server generierte Statistiken reserviert. Sie können dieses Suffix nicht verwenden, wenn Sie Statistiken in einer primären Datenbank erstellen. Weitere Informationen finden Sie unter Statistik.

[Nach oben]

Aspekte der Kapazitätsplanung

• Für lesbare sekundäre Replikate ist aus zwei Gründen möglicherweise Speicherplatz in tempdb erforderlich:

  • In der Momentaufnahme-Isolationsstufe werden Zeilenversionen in tempdb kopiert.

  • Temporäre Statistiken für sekundäre Datenbanken werden in tempdb erstellt und verwaltet. Die temporären Statistiken können einen leichten Anstieg der Größe von tempdb verursachen. Weitere Informationen finden Sie unter Statistiken für Datenbanken mit schreibgeschütztem Zugriff später in diesem Abschnitt.

• Wenn Sie den Schreibschutz für mindestens ein sekundäres Replikat konfigurieren, wird von den primären Datenbanken 14 Bytes Mehraufwand für gelöschte, geänderte oder eingefügte Datenzeilen hinzugefügt, um Zeiger auf Zeilenversionen auf der sekundären Datenbank zu speichern. Dieser Mehraufwand von 14-Bytes geht auf die sekundären Datenbanken über. Durch den Mehraufwand von 14 Byte treten bei den Datenzeilen möglicherweise Seitenteilungen auf.

  Die Zeilenversionsdaten werden nicht von den primären Datenbanken generiert. Die sekundären Datenbanken generieren jedoch die Zeilenversionen. Die Zeilenversionsverwaltung erhöht jedoch den Datenspeicher in der primären und in der sekundären Datenbank.

  Das Hinzufügen der Zeilenversionsdaten hängt von der Momentaufnahmeisolation oder der Einstellung für die Read Committed-Momentaufnahmen-Isolationsstufen (RCSI) auf der primären Datenbank ab. In der folgenden Tabelle wird das Verhalten der Versionsverwaltung unter unterschiedlichen Einstellungen auf einer lesbaren sekundären Datenbank beschrieben.

  Lesbares sekundäres Replikat?	Ist Momentaufnahmeisolation oder RCSI-Ebene aktiviert?	Primäre Datenbank	Sekundäre Datenbank
  Nein	Nein	Keine Zeilenversionen oder 14 Byte Mehraufwand	Keine Zeilenversionen oder 14 Byte Mehraufwand
  Nein	Ja	Zeilenversionen und 14 Byte Mehraufwand	Keine Zeilenversionen, aber 14 Byte Mehraufwand
  Ja	Nein	Keine Zeilenversionen, aber 14 Byte Mehraufwand	Zeilenversionen und 14 Byte Mehraufwand
  Ja	Ja	Zeilenversionen und 14 Byte Mehraufwand	Zeilenversionen und 14 Byte Mehraufwand

[Nach oben]

Verwandte Aufgaben

• Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server)

• Konfigurieren des schreibgeschützten Routing für eine Verfügbarkeitsgruppe (SQL Server)

• Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server)

• Überwachen von Verfügbarkeitsgruppen (Transact-SQL)

• Anzeigen von Verfügbarkeitsreplikateigenschaften (SQL Server)

• Verwenden des Dialogfelds Neue Verfügbarkeitsgruppe (SQL Server Management Studio)

[Nach oben]

Verwandte Inhalte

• SQL Server AlwaysOn-Teamblog: Der offizielle SQL Server AlwaysOn-Teamblog

[Nach oben]

Siehe auch

Konzepte

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)

Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)

Statistik