Schreibgeschützte Workload auf ein sekundäres Replikat einer Always On-Verfügbarkeitsgruppe auslagern

Gilt für:SQL Server

Die Funktionen aktiver sekundärer Replikate in Always On-Verfügbarkeitsgruppen umfassen die Unterstützung des schreibgeschützten Zugriffs 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. Ein lesbares sekundäres Replikat ermöglicht schreibgeschützten Zugriff auf alle zugehörigen sekundären Datenbanken. 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:

• Lagert Ihre sekundären schreibgeschützten Workloads von Ihrem primären Replikat aus, wodurch dessen Ressourcen für Ihre geschäftskritischen Workloads geschont werden. Wenn Sie geschäftskritische Lese-Workloads oder Workloads haben, die keine Latenz tolerieren können, sollten Sie diese auf dem primären Replikat ausführen.

• 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 Workloads für plattenbasierte Tabellen verwenden die Zeilenversionierung, um Blockierungskonflikte auf den sekundären Datenbanken zu vermeiden. 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

  Der Datenbankadministrator kann optional beliebige der Verfügbarkeitsreplikate so konfigurieren, dass schreibgeschützte Verbindungen ausgeschlossen werden, wenn diese in der primären Rolle ausgeführt 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 richten, und in der Verbindungszeichenfolge des Clients muss die Anwendungsabsicht als „schreibgeschützt“ angegeben sein. Das heißt, es muss sich dabei um Verbindungsanforderungen mit Leseabsicht handeln.

• Schreibgeschütztes 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 schreibgeschütztes Routing unterstützen soll, wenn es das primäre Replikat ist, erfordert eine Routingliste für schreibgeschützten Zugriff. 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 des Lastenausgleichs für schreibgeschützte Replikate.

  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 Extremfall müssen Sie auf der sekundären Datenbank eine lange laufende Leseabfrage abbrechen, die die Ghost-Bereinigung blockiert. Hinweis: Die Ghost-Bereinigung kann blockiert werden, wenn die Verbindung zum sekundären Replikat unterbrochen wird oder wenn die Datenbewegung für die sekundäre 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 sich für schreibgeschützte Workloads direkt mit den schreibgeschützten sekundären Replikaten verbinden.

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

• Indizieren

• Statistiken für Datenbanken mit schreibgeschütztem Zugriff

Datenlatenz

Die Implementierung von schreibgeschütztem Zugriff auf sekundäre Replikate ist sinnvoll, wenn Ihre schreibgeschützten Workloads eine gewisse Latenz bei den Daten tolerieren können. In Situationen, in denen Latenz inakzeptabel ist, sollten Sie erwägen, schreibgeschützte Workloads auf dem primären Replikat auszuführen.

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 Always On-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 Workloads

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.

Außerdem können schreibgeschützte Workloads auf den sekundären Replikaten DDL-Änderungen blockieren, die über 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. Wenn Sie also zum Beispiel eine datenträgerbasierte oder speicheroptimierte Tabelle auf dem Primärreplikat löschen. 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. Das Löschen einer nativ kompilierten gespeicherten Prozedur kann dazu führen, dass ein REDO-Thread blockiert wird, wenn die nativ kompilierte 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 Workloads auf den lesbaren sekundären Replikaten zu optimieren, sollten Sie erwägen, Indizes für die Tabellen in den sekundären Datenbanken zu 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. Die schreibgeschützte Arbeitslast auf den sekundären Datenbanken benötigt jedoch 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 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 persistente Statistiken auf sekundären Datenbanken

• Einschränkungen

Veraltete persistente Statistiken auf 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 den Lesezugriff für ein oder mehrere sekundäre Replikate konfigurieren, fügen die primären Datenbanken bei datenträgerbasierten Tabellen gelöschten, geänderten oder eingefügten Datenzeilen 14 Bytes zusätzlichen Overhead hinzu, um Zeiger auf Zeilenversionen auf den sekundären Datenbanken zu speichern. 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