Teilen über

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

  • Artikel

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 oder asynchronem Commit befinden. 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 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.

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.

Always On-Verfügbarkeitsgruppen unterstützt auch das Umleiten von Verbindungsanforderungen für beabsichtigte Lesevorgänge 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 die Rendite von Systemen, 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:

  • Durch automatische temporäre Statistiken für lesbare sekundäre Datenbanken werden schreibgeschützte Abfragen in datenträgerbasierten Tabellen optimiert. 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 Arbeitsauslastungen für dauerhafte speicheroptimierte Tabellen greifen unter Verwendung von systemeigenen gespeicherten Prozeduren oder SQL-Interoperabilität, für die hinsichtlich der Transaktionsisolationsstufen dieselben Einschränkungen gelten (siehe Isolationsstufen in der Datenbank-Engine), auf genau dieselbe Weise auf Daten wie in der primären Datenbank zu. Auf dem primären Replikat ausgeführte Arbeitsauslastungen für die Berichterstellung oder schreibgeschützte Abfragen können unverändert auf dem sekundären Replikat ausgeführt werden. 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 für sekundäre Datenbanken automatisch der Momentaufnahme-Transaktionsisolationsstufe zugeordnet, selbst wenn explizit andere Transaktionsisolationsstufen festgelegt wurden.

  • 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 zu parallelen Upgrades.

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

  • Schreibgeschütztes Routing

    Alsschreibgeschü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 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

      Für Verbindungsanforderungen beabsichtigter Lesevorgänge kann replikateübergreifend ein Lastenausgleich ausgeführt 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).

Hinweis

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

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 der Arbeitsauslastung für die Berichterstellung und den schreibgeschützten Abfragen sowohl datenträgerbasierte als auch speicheroptimierte Tabellen gleichzeitig zur Verfügung stehen.

  • 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 nur für eine sekundäre Replikatdatenbank 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 Momentaufnahme-Transaktionsisolationsstufe 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 für datenträgerbasierte Tabellen 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 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. Inaktive Datensätze verwenden physischen Speicher in einer Datendatei, was zu Problemen bei der Wiederverwendung von Speicher führen kann. Weitere Informationen hierzu finden Sie unter Cleanup inaktiver Datensätze. 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 dem Cleanup inaktiver Datensätze, da die Zeilenversionen im Arbeitsspeicher beibehalten 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.

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 REDO-Blockierungsproblem auftreten. Dies kommt daher, dass diese dynamische Verwaltungssicht eine IS-Sperre für die angegebene Benutzertabelle oder Sicht erhält, die Anforderungen von einem REDO-Thread für eine X-Sperre dieser Benutzertabelle oder Sicht blockieren kann.

Überlegungen zur Leistung

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

In diesem Abschnitt:

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 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 in 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, beispielsweise bei Netzwerkproblemen, die den Durchsatz reduzieren, kann die Latenz jedoch signifikant werden. Die Latenz 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 Verwaltungssicht sys.dm_hadr_database_replica_states verwenden.

Datenlatenz bei Datenbanken mit speicheroptimierten Tabellen

In SQL Server 2014 (12.x) galten besondere Überlegungen zur Datenlatenz für aktive sekundäre Replikate. Informationen dazu finden Sie unter SQL Server 2014 (12.x) Aktive sekundäre Replikate: Lesbare sekundäre Replikate (Always On-Verfügbarkeitsgruppen). 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 schreibgeschützten Zugriff konfigurieren, belegen die schreibgeschützten Arbeitsauslastungen in den sekundären Datenbanken Systemressourcen, z. B. CPU und E/A-Vorgänge (für datenträgerbasierte Tabellen) aus REDO-Threads, insbesondere wenn die schreibgeschützten Arbeitsauslastungen für datenträgerbasierte Tabellen äußerst 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/DROP-Tabellen und -Sichten, aber keine DROP- oder ALTER-Anweisungen gespeicherter Prozeduren. Angenommen, Sie löschen eine datenträgerbasierte oder speicheroptimierte Tabelle auf dem primären Replikat. Wenn der Protokolldatensatz von einem REDO-Thread verarbeitet wird, um die Tabelle zu löschen, muss er eine SCH_M-Sperre für die Tabelle abrufen und kann durch eine laufende Abfrage, die auf die Tabelle zugreift, blockiert werden. 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.

Hinweis

Wird ein REDO-Thread von Abfragen auf dem sekundären Replikat blockiert, wird das XEvent sqlserver.lock_redo_blocked 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 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 mit der Transact-SQL-Anweisung DROP STATISTICS.

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

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.

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 Verwalten von Statistiken für Tabellen in SQL Data Warehouse.

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 Datenbankebenenoption auf MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 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

Related Tasks

Verwandte Inhalte

Weitere Informationen

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