Auslagern von schreibgeschützten Arbeitsauslastungen auf ein sekundäres Replikat einer Always On-Verfügbarkeitsgruppe

Gilt für:SQL Server

Die Funktionen für aktive sekundäre Replikate in Always On-Verfügbarkeitsgruppen umfassen Unterstützung für den schreibgeschützten Zugriff auf ein oder mehrere sekundäre Replikate (lesbare sekundäre Replikate). Ein lesbares sekundäres Replikat kann sich entweder im Verfügbarkeitsmodus mit synchronem Commit oder im Verfügbarkeitsmodus mit asynchronem Commit befinden. Lesbare sekundäre Replikate lassen den schreibgeschützten Zugriff auf alle eigenen sekundären Datenbanken zu. Lesbare sekundäre Datenbanken sind jedoch nicht als schreibgeschützt 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 nahezu in Echtzeit vor. Dies gilt auch für dauerhafte speicheroptimierte Tabellen. 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.

Always On-Verfügbarkeitsgruppen unterstützen auch die Umleitung von Verbindungsanforderungen mit Leseabsicht an ein lesbares sekundäres Replikat (schreibgeschütztes Routing). Weitere 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).

Vorteile

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

• Entlastet das primäre Replikat von sekundären schreibgeschützten Arbeitsauslastungen, wodurch dessen Ressourcen für unternehmenswichtige Arbeitsauslastungen zur Verfügung stehen. Unternehmenswichtige Lesearbeitsauslastungen oder Arbeitsauslastungen, die keine Latenzen tolerieren, sollten auf dem primären Replikat ausgeführt werden.

• Verbessert den Return on Investment für die Systeme, die lesbare sekundäre Replikate hosten.

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

• Automatische temporäre Statistiken für lesbare sekundäre Datenbanken optimieren schreibgeschützte Abfragen für datenträgerbasierte Tabellen. Bei speicheroptimierten Tabellen werden die fehlenden Statistiken automatisch erstellt. Veraltete Statistiken werden jedoch nicht automatisch aktualisiert. Sie müssen die Statistiken auf dem primären Replikat manuell aktualisieren. Weitere Informationen finden Sie unter Statistiken für Datenbanken mit schreibgeschütztem Zugriffweiter unten in diesem Thema.

• Schreibgeschützte Arbeitsauslastungen für datenträgerbasierte Tabellen verwenden die Zeilenversionsverwaltung, um Blockierungskonflikte für sekundäre Datenbanken aufzuheben. Alle Abfragen für sekundäre Datenbanken werden automatisch der Momentaufnahme-Transaktionsisolationsstufe zugeordnet, selbst wenn explizit andere Transaktionsisolationsstufen festgelegt wurden. Zudem werden alle Sperrhinweise ignoriert. Dies schließt Leser-/Schreiberkonflikte aus.

• Schreibgeschützte Workloads für dauerhafte speicheroptimierte Tabellen greifen auf die Daten in genau derselben Weise zu wie in der primären Datenbank, und zwar mithilfe nativ kompilierter gespeicherter Prozeduren oder der SQL-Interoperabilität mit denselben Einschränkungen bei den Transaktionsisolationsstufen (siehe Isolationsstufen in der Datenbank-Engine). Workloads für die Berichterstellung oder schreibgeschützte Abfragen, die auf dem primären Replikat ausgeführt werden, können auch auf dem sekundären Replikat ausgeführt werden, ohne dass Änderungen erforderlich sind. Analog dazu können auf einem sekundären Replikat ausgeführte Arbeitsauslastungen für die Berichterstellung oder schreibgeschützte Abfragen unverändert auf dem primären Replikat ausgeführt werden. Ähnlich wie bei datenträgerbasierten Tabellen werden alle Abfragen, die für die sekundären Datenbanken ausgeführt werden, automatisch der Transaktionsisolationsstufe Snapshot zugeordnet, selbst wenn explizit andere Transaktionsisolationsstufen festgelegt sind.

• DML-Vorgänge sind für Tabellenvariablen datenträgerbasierter und speicheroptimierter Tabellentypen auf dem sekundären Replikat zulässig.

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).

  Warnung

  Nur Replikate desselben Hauptbuilds von SQL Server sind lesbar. Weitere Informationen finden Sie unter Grundlagen des Rolling Upgrade.

• Verfügbarkeitsgruppenlistener

  Um schreibgeschütztes Routing zu unterstützen, muss eine Verfügbarkeitsgruppe einen Verfügbarkeitsgruppenlistenerbesitzen. Der schreibgeschützte Client muss seine Verbindungsanforderungen an diesen Listener senden, und in der Verbindungszeichenfolge des Clients muss die Anwendungsabsicht als „schreibgeschützt“ angegeben sein. Es muss sich also um Verbindungsanforderungen mit Leseabsicht handeln.

• Nur-Lesen-Routing

  Schreibgeschütztes Routing bezeichnet die Fähigkeit von SQL Server, eingehende Verbindungsanforderungen mit Leseabsicht, 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 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 bei Bedarf für jedes Replikat einzeln 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 mit Leseabsicht können per Lastenausgleich auf Replikate verteilt werden. Weitere Informationen finden Sie unter Konfigurieren von Lastenausgleich über schreibgeschützte Replikate hinweg.

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

Beschränkungen und Einschränkungen

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

• Sobald für ein lesbares Replikat der Lesezugriff aktiviert ist, können Verbindungsanforderungen für die sekundären Datenbanken angenommen werden. Wenn in einer primären Datenbank jedoch aktive Transaktionen vorhanden sind, sind die Zeilenversionen in der entsprechenden sekundären Datenbank nicht vollständig 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.

  Warnung

  Die Ausführung von Transaktionen mit langer Ausführungszeit wirkt sich darauf aus, wie viele Zeilen mit Versionsangabe für datenträgerbasierte und speicheroptimierte Tabellen beibehalten werden.

• Obwohl für speicheroptimierte Tabellen immer Zeilenversionen generiert werden, werden bei einer sekundären Datenbank mit speicheroptimierten Tabellen Abfragen blockiert, bis alle aktiven Transaktionen abgeschlossen sind, die sich im primären Replikat befanden, während der Lesezugriff für das sekundäre Replikat aktiviert wurde. Dadurch wird sichergestellt, dass sowohl datenträgerbasierte als auch speicheroptimierte Tabellen gleichzeitig für die Berichtserstellung und für schreibgeschützte Abfragen zur Verfügung stehen.

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

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

  • Change Data Capture kann nicht nur für die Datenbank eines sekundären Replikats aktiviert werden. Change Data Capture kann für die primäre Replikatdatenbank aktiviert werden, und die Änderungen können mithilfe der Funktionen für die sekundäre Replikatdatenbank aus den CDC-Tabellen gelesen werden.

• Da Lesevorgänge der Transaktionsisolationsstufe Snapshot zugeordnet werden, kann die Bereinigung von Ghost-Datensätzen auf dem primären Replikat durch Transaktionen auf einem oder mehreren sekundären Replikaten blockiert werden. Die Bereinigungsaufgabe für Ghost-Datensätze bereinigt die Ghost-Datensätze für datenträgerbasierte Tabellen auf dem primären Replikat automatisch, sobald sie von keinem sekundären Replikat mehr benötigt werden. Dies ist analog zur Ausführung von Transaktionen auf dem primären Replikat. Im äußersten Fall müssen Sie Leseabfragen mit langer Laufzeit in 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 in der sekundären Datenbank angehalten wird. Ghost-Datensätze belegen physischen Speicherplatz in einer Datendatei, was zu Problemen bei der Wiederverwendung des Speicherplatzes führen kann. Weitere Informationen finden Sie unter Ghost Cleanup. 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. Bei speicheroptimierten Tabellen besteht kein Problem mit der Bereinigung von Geisterdatensätzen, da die Zeilenversionen im Arbeitsspeicher gehalten werden und unabhängig von den Zeilenversionen auf dem primären Replikat sind.

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

• Ab SQL Server 2014 (12.x) können lesbare sekundäre Replikate selbst dann online verfügbar bleiben, wenn das primäre Replikat aufgrund einer Benutzeraktion oder eines Fehlers offline ist, z. B. weil die Synchronisierung aufgrund eines Benutzerbefehls oder eines Fehlers angehalten wurde oder der Status eines Replikats aufgelöst wurde, da der WSFC offline ist. Allerdings ist in diesem Fall kein schreibgeschütztes Routing möglich, da der Verfügbarkeitsgruppenlistener ebenfalls offline ist. Clients müssen bei schreibgeschützten Arbeitsauslastungen direkt eine Verbindung mit den schreibgeschützten sekundären Replikaten herstellen.

Ü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 Workloads

• Indizieren

• Statistiken für Datenbanken mit schreibgeschütztem Zugriff

Datenlatenz

Das Implementieren von schreibgeschütztem Zugriff auf sekundäre Replikate ist hilfreich, sofern Ihre schreibgeschützten Arbeitsauslastungen eine gewisse Datenlatenz 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. In der jeweiligen sekundären Datenbank werden die Protokolldatensätze von einem dedizierten REDO-Thread angewendet. In einer sekundären Datenbank mit Lesezugriff erscheint eine bestimmte Datenänderung erst dann in den Abfrageergebnissen, wenn der Protokolldatensatz, der diese Änderung enthält, in die sekundäre Datenbank übernommen wurde und die Transaktion in der primären Datenbank festgeschrieben 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, beispielsweise bei Netzwerkproblemen, die den Durchsatz reduzieren, kann die Latenz jedoch signifikant werden. Die Latenz nimmt sowohl bei E/A-Engpässen als auch dann zu, wenn die Datenübertragung ausgesetzt wird. Zur Überwachung einer angehaltenen Datenverschiebung können Sie das AlwaysOn-Dashboard oder die dynamische Verwaltungssicht sys.dm_hadr_database_replica_states verwenden.

Datenlatenz bei Datenbanken mit speicheroptimierten Tabellen

In SQL Server 2014 (12.x) gab es besondere Aspekte im Zusammenhang mit der Datenlatenz auf aktiven sekundären Replikaten – siehe SQL Server 2014 (12.x) Aktive sekundäre Replikate: Lesbare sekundäre Replikate. Ab SQL Server 2016 (13.x) gelten keine Besonderheiten mehr bezüglich der Datenlatenz für speicheroptimierte Tabellen. Die erwartete Datenlatenz für speicheroptimierte Tabellen ist mit der Latenz für datenträgerbasierte Tabellen vergleichbar.

Auswirkungen auf schreibgeschützte Arbeitsauslastungen

Wenn Sie ein sekundäres Replikat für den schreibgeschützten Zugriff konfigurieren, beanspruchen Ihre schreibgeschützten Workloads auf den sekundären Datenbanken Systemressourcen wie CPU und E/A (bei datenträgerbasierten Tabellen) der Redo-Threads, insbesondere wenn die schreibgeschützten Workloads auf datenträgerbasierten Tabellen stark E/A-intensiv sind. Der Zugriff auf speicheroptimierte Tabellen hat keine Auswirkungen auf die E/A-Leistung, weil alle Zeilen im Arbeitsspeicher enthalten sind.

Schreibgeschützte Arbeitsauslastungen auf den sekundären Replikaten können zudem Änderungen der Datendefinitionssprache (DDL) blockieren, die durch Protokolldatensätze angewendet werden.

• Obwohl die Lesevorgänge wegen der Zeilenversionsverwaltung über keine gemeinsamen Sperren verfügen, basieren diese Vorgänge auf Schemastabilitätssperren (Sch-S). Dadurch werden u. U. REDO-Vorgänge blockiert, die DDL-Änderungen anwenden. DDL-Vorgänge umfassen ALTER- und DROP-Operationen für Tabellen und Sichten, nicht jedoch DROP- oder ALTER-Operationen für gespeicherte Prozeduren. Angenommen, Sie löschen eine datenträgerbasierte oder speicheroptimierte Tabelle auf dem primären Replikat. Wenn der REDO-Thread den Protokolldatensatz verarbeitet, um die Tabelle zu löschen, muss er eine SCH_M-Sperre für die Tabelle erwerben und kann durch eine laufende Abfrage blockiert werden, die auf die Tabelle zugreift. Auf dem primärem Replikat ist das Verhalten identisch, mit der Ausnahme, dass die Tabelle im Rahmen einer Benutzersitzung und nicht in einem REDO-Thread gelöscht wird.

• Es gibt weitere Gründe für das Blockieren speicheroptimierter Tabellen. Durch das Löschen einer systemeigenen gespeicherten Prozedur kann ein REDO-Thread blockiert werden, wenn die systemeigene gespeicherte Prozedur gleichzeitig auf dem sekundären Replikat ausgeführt wird. Auf dem primärem Replikat ist das Verhalten identisch, mit der Ausnahme, dass die gespeicherte Prozedur im Rahmen einer Benutzersitzung und nicht in einem REDO-Thread gelöscht wird.

Beachten Sie die bewährten Methoden zum Erstellen von Abfragen, und wenden Sie diese Methoden auf die sekundären Datenbanken an. Planen Sie beispielsweise Abfragen mit langer Laufzeit wie Datenaggregationen in Zeiträumen mit geringer Aktivität.

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 Indexverwendung auf einem sekundären Replikat fragen Sie die Spalten user_seeks, user_scansund user_lookups der dynamischen Verwaltungssicht sys.dm_db_index_usage_stats 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. Für die schreibgeschützte Arbeitsauslastung in den sekundären Datenbanken sind jedoch möglicherweise andere Statistiken als die erforderlich, die in den primären Datenbanken erstellt werden. Da sekundäre Datenbanken jedoch auf schreibgeschützten Zugriff beschränkt sind, können für die sekundären Datenbanken keine Statistiken 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 an den Namen temporärer Statistiken angefügt, um die temporären Statistiken von den dauerhaften Statistiken zu unterscheiden, die von 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äre Statistiken mithilfe der DROP STATISTICS Transact-SQL-Anweisung.

• Ü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.

Automatische Updates von Statistiken werden für speicheroptimierte Tabellen auf dem primären oder sekundären Replikat nicht unterstützt. Sie müssen die Abfrageleistung und Pläne auf dem sekundären Replikat überwachen und die Statistiken auf dem primären Replikat ggf. manuell aktualisieren. Allerdings werden die fehlenden Statistiken auf dem primären und sekundären Replikat automatisch erstellt.

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 für datenträgerbasierte Tabellen in der sekundären Datenbank und verwendet diese Statistiken anstelle der veralteten dauerhaften Statistiken.

Wenn die dauerhaften Statistiken in der primären Datenbank aktualisiert werden, werden sie automatisch in der sekundären Datenbank dauerhaft gespeichert. 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.

Beschränkungen und Einschränkungen

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

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

Zugreifen auf speicheroptimierte Tabellen auf einem sekundären Replikat

Mit speicheroptimierten Tabellen können für primäre und sekundäre Replikate dieselben Transaktionsisolationsstufen verwendet werden. Es wird empfohlen, die Isolationsstufe auf Sitzungsebene auf READ COMMITTED und die Option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT auf Datenbankebene auf ON festzulegen. Beispiel:

ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON  
GO  
SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
GO  
SELECT SUM(UnitPrice*OrderQty)   
FROM Sales.SalesOrderDetail_inmem  
GO  
  

Aspekte der Kapazitätsplanung

• Bei datenträgerbasierten Tabellen können lesbare sekundäre Replikate aus zwei Gründen Speicherplatz in tempdb beanspruchen:

  • In der Momentaufnahme-Isolationsstufe werden Zeilenversionen in tempdbkopiert.

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

• Wenn Sie für eines oder mehrere sekundäre Replikate Lesezugriff konfigurieren, wird von den primären Datenbanken für gelöschte, geänderte oder eingefügte Datenzeilen beim Speichern von Zeigern auf Zeilenversionen in den sekundären Datenbanken für datenträgerbasierte Tabellen ein Mehraufwand von 14 Bytes verursacht. Dieser Mehraufwand von 14 Bytes geht auf die sekundären Datenbanken über. Da der Mehraufwand von 14 Bytes auf die Datenzeilen übertragen wird, können Seitenteilungen auftreten.

  Die Zeilenversionsdaten werden nicht von den primären Datenbanken generiert. Stattdessen werden die Zeilenversionen von den sekundären Datenbanken generiert. Durch die Zeilenversionsverwaltung nimmt jedoch die Datenspeicherung in der primären und in der sekundären Datenbank zu.

  Das Hinzufügen der Zeilenversionsdaten hängt von der Momentaufnahmeisolation oder der Einstellung der READ_COMMITTED_SNAPSHOT-Isolationsstufe (RCSI) in der primären Datenbank ab. In der folgenden Tabelle wird das Verhalten der Versionsverwaltung in einer lesbaren sekundären Datenbank mit unterschiedlichen Einstellungen für datenträgerbasierte Tabellen beschrieben.

  Lesbares sekundäres Replikat?	Ist Momentaufnahmeisolation oder RCSI-Stufe 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

Verwandte Aufgaben

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

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

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

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

• Eigenschaften von Verfügbarkeitsreplikaten anzeigen (SQL Server)

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

Verwandte Inhalte

• SQL Server Always On Team Blog: The official SQL Server Always On Team Blog (SQL Server Always On-Teamblog: Der offizielle SQL Server Always On-Teamblog)

Siehe auch

Übersicht über Always On-Verfügbarkeitsgruppen (SQL Server)
Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)
Verfügbarkeitsgruppenlistener, Clientverbindungen und Anwendungsfailover (SQL Server)
Statistik