Freigeben über

Verwenden von schreibgeschützten Replikaten zum Lesen schreibgeschützter Abfrageworkloads

  • Artikel

Gilt für: Azure SQL-Datenbank Azure SQL Managed Instance

Als Teil der Hochverfügbarkeitsarchitektur wird jede Datenbank oder jeder Pool für elastische Datenbanken der Dienstebenen „Premium“ und „Unternehmenskritisch“ automatisch mit einem primären Replikat mit Lese-/Schreibzugriff und mindestens einem sekundären schreibgeschützten Replikat bereitgestellt. Die sekundären Replikate werden mit derselben Computegröße wie das primäre Replikat bereitgestellt. Die horizontale Leseskalierung ermöglicht es Ihnen, schreibgeschützte Workloads mithilfe der Computekapazität eines der schreibgeschützten Replikate auszulagern, anstatt sie auf dem Replikat mit Lese-/Schreibzugriff auszuführen. Auf diese Weise können einige schreibgeschützte Workloads von den Lese-/Schreibworkloads isoliert werden, ohne ihre Leistung zu beeinträchtigen. Die Funktion ist für Anwendungen vorgesehen, die logisch getrennte, schreibgeschützte Workloads (z. B. zur Analyse) enthalten. In den Diensttarifen Premium und Unternehmenskritisch können Anwendungen Leistungsvorteile erzielen, die diese zusätzliche Kapazität ohne zusätzliche Kosten nutzen.

Die horizontale Leseskalierung ist auch auf der Dienstebene „Hyperscale“ verfügbar, wenn mindestens ein sekundäres Replikat hinzugefügt wird. Sekundäre benannte Hyperscale-Replikate bieten unabhängige Skalierung, Zugriffsisolation, Workloadisolation, Unterstützung für verschiedene Szenarien mit horizontaler Leseskalierung und weitere Vorteile. Mehrere sekundäre Hochverfügbarkeitsreplikate können für einen Lastenausgleich schreibgeschützter Workloads verwendet werden, für die mehr Ressourcen erforderlich sind, als auf einem sekundären Hochverfügbarkeitsreplikat zur Verfügung stehen.

Die Hochverfügbarkeitsarchitektur der Dienstebenen „Basic“, „Standard“ und „Universell“ enthält keine Replikate. Die horizontale Leseskalierung ist auf diesen Dienstebenen nicht verfügbar. Wenn Sie jedoch Azure SQL-Datenbank verwenden, können Georeplikate in diesen Dienstebenen ähnliche Funktionalität bieten. Bei Verwendung von Azure SQL Managed Instance und Failovergruppen bietet der schreibgeschützte Listener für Failovergruppen jeweils ähnliche Funktionalität.

Im folgenden Diagramm wird die Funktion für Datenbanken und verwaltete Instanzen in den Tarifen „Premium“ und „Unternehmenskritisch“ veranschaulicht.

Diagramm: Schreibgeschützte Replikate

Die horizontale Leseskalierung ist bei Datenbanken in den Tarifen Premium, Unternehmenskritisch und Hyperscale standardmäßig aktiviert.

Hinweis

Die horizontale Leseskalierung ist auf der Dienstebene „Unternehmenskritisch“ von SQL Managed Instance und für Hyperscale-Datenbanken mit mindestens einem sekundären Replikat immer aktiviert.

Wenn Ihre SQL-Verbindungszeichenfolge mit ApplicationIntent=ReadOnly konfiguriert wurde, wird die Anwendung zu einem schreibgeschützten Replikat dieser Datenbank oder verwalteten Instanz umgeleitet. Informationen zur Verwendung der ApplicationIntent-Eigenschaft finden Sie unter Angeben der Anwendungsabsicht.

Nur für Azure SQL-Datenbank gilt Folgendes: Wenn Sie sicherstellen möchten, dass die Anwendung unabhängig von der Einstellung ApplicationIntent in der SQL-Verbindungszeichenfolge eine Verbindung mit dem primären Replikat herstellt, müssen Sie die horizontale Leseskalierung beim Erstellen der Datenbank oder beim Ändern ihrer Konfiguration explizit deaktivieren. Wenn Sie Ihre Datenbank z. B. vom Tarif „Standard“ oder „Universell“ auf den Tarif „Premium“ oder „Unternehmenskritisch“ upgraden und sicherstellen möchten, dass weiterhin alle Verbindungen zum primären Replikat führen, deaktivieren Sie die horizontale Leseskalierung. Weitere Informationen zum Deaktivieren dieser Funktion finden Sie unter Aktivieren und Deaktivieren der horizontalen Leseskalierung.

Hinweis

Abfragespeicher und SQL Profiler werden in schreibgeschützten Replikaten nicht unterstützt.

Datenkonsistenz

Am primären Replikat vorgenommene Datenänderungen werden je nach Replikattyp synchron oder asynchron für schreibgeschützte Replikate beibehalten. Für alle Replikattypen sind Lesevorgänge von schreibgeschützten Replikaten in Bezug auf das primäre Replikat jedoch immer asynchron. Innerhalb einer Sitzung, die mit einem schreibgeschützten Replikat verbunden ist, sind Lesevorgänge immer transaktionskonsistent. Da die Wartezeit für die Datenweitergabe variabel ist, können verschiedene Replikate Daten zu geringfügig unterschiedlichen Zeitpunkten im Vergleich zum primären Replikat und zueinander zurückgeben. Wenn ein schreibgeschütztes Replikat nicht mehr verfügbar ist und die Sitzung erneut verbunden wird, kann sie sich mit einem Replikat verbinden, das sich an einem anderen Zeitpunkt befindet als das ursprüngliche Replikat. Ebenso gilt Folgendes: Wenn eine Anwendung Daten in einer Sitzung mit Lese-/Schreibzugriff für das primäre Replikat ändert und sie sofort in einer schreibgeschützten Sitzung für ein schreibgeschütztes Replikat liest, sind die letzten Änderungen möglicherweise nicht sofort sichtbar.

Die typische Latenz bei der Datenweitergabe zwischen dem primären Replikat und schreibgeschützten Replikaten liegt im Bereich von einigen Dutzend Millisekunden bis zu einstelligen Sekunden. Es gibt jedoch für die Datenweitergabelatenz keine feste Obergrenze. Bedingungen wie eine hohe Ressourcenauslastung im Replikat können die Latenz erheblich erhöhen. Anwendungen, die sitzungsübergreifende Datenkonsistenz erfordern oder bei denen committete Daten sofort lesbar sein müssen, müssen das primäre Replikat verwenden.

Hinweis

Die Latenz der Datenweitergabe umfasst die Zeit, die (ggf.) zum Senden von Protokolldatensätzen an ein sekundäres Replikat und deren Beibehalten erforderlich ist. Sie umfasst auch die Zeit, die zum Wiederholen (Anwenden) dieser Protokolldatensätze auf Datenseiten erforderlich ist. Um die Datenkonsistenz sicherzustellen, werden Änderungen erst sichtbar, wenn der Transaktionscommit-Protokolldatensatz angewendet wird. Wenn die Workload größere Transaktionen verwendet, erhöht sich die effektive Datenweitergabelatenz.

Informationen zum Überwachen der Datenweitergabelatenz finden Sie unter Überwachung und Problembehandlung bei schreibgeschützten Replikaten.

Herstellen einer Verbindung mit einem schreibgeschützten Replikat

Wenn Sie die horizontale Leseskalierung für eine Datenbank aktivieren, bestimmt die Option ApplicationIntent in der vom Client bereitgestellten Verbindungszeichenfolge, ob eine Verbindung an das Replikat mit Schreibzugriff oder an ein schreibgeschütztes Replikat weitergeleitet wird. Wenn ApplicationIntent den Wert ReadWrite aufweist (Standardwert), wird die Verbindung an das Replikat mit Lese-/Schreibzugriff weitergeleitet. Dies ist identisch mit dem Verhalten, wenn ApplicationIntent nicht in der Verbindungszeichenfolge enthalten ist. Wenn der ApplicationIntent-Wert ReadOnly lautet, wird die Verbindung an ein schreibgeschütztes Replikat weitergeleitet.

Ein Beispiel: Die folgende Verbindungszeichenfolge verbindet den Client mit einem schreibgeschützten Replikat (ersetzen Sie die Elemente in spitzen Klammern durch die richtigen Werte für Ihre Umgebung, und löschen Sie die Klammern):

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;

Um eine Verbindung mit einem schreibgeschützten Replikat mit SQL Server Management Studio (SSMS) herzustellen, wählen Sie Optionen aus.

Screenshot: Schaltfläche „SSMS-Optionen“

Wählen Sie Zusätzliche Verbindungsparameter aus, geben ApplicationIntent=ReadOnly ein und wählen anschließend Verbinden aus.

Screenshot: „Zusätzliche Verbindungsparameter“ in SSMS

Jede der folgenden Verbindungszeichenfolgen verbindet den Client mit einem Replikat mit Lese-/Schreibzugriff (ersetzen Sie die Elemente in spitzen Klammern durch die richtigen Werte für Ihre Umgebung, und löschen Sie die Klammern):

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;

Sicherstellen einer Verbindung mit einem schreibgeschützten Replikat

Sie können durch Ausführen der folgenden Abfrage im Kontext Ihrer Datenbank überprüfen, ob Sie mit einem schreibgeschützten Replikat verbunden sind. Bei einer Verbindung mit einem schreibgeschützten Replikat wird READ_ONLY zurückgegeben.

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');

Hinweis

Auf den Dienstebenen Premium und Unternehmenskritisch ist jeweils nur eines der schreibgeschützten Replikate verfügbar. Bei Hyperskalierung werden mehrere schreibgeschützte Replikate unterstützt.

Überwachung und Problembehandlung bei schreibgeschützten Replikaten

Wenn eine Verbindung mit einem schreibgeschützten Replikat besteht, spiegeln dynamische Verwaltungssichten (Dynamic Management Views, DMVs) den Status des Replikats wider und können zu Überwachungs- und Problembehandlungszwecken abgefragt werden. Die Datenbank-Engine stellt mehrere Sichten bereit, über die eine Vielzahl von Überwachungsdaten verfügbar gemacht werden kann.

Die folgenden Sichten werden häufig für die Überwachung und Problembehandlung von Replikaten verwendet:

Name Zweck
sys.dm_db_resource_stats Bietet Metriken zur Ressourcennutzung für die letzte Stunde, einschließlich CPU-, Daten-E/A- und Protokollschreibauslastung bezogen auf Dienstziellimits.
sys.dm_os_wait_stats Stellt Statistiken zu aggregierten Wartevorgängen für die Datenbank-Engine-Instanz bereit.
sys.dm_database_replica_states Bietet Statistiken zum Replikatintegritätsstatus und zur Synchronisierung. Die Größe der Wiederholungswarteschlange und die Wiederholungsrate dienen als Hinweise auf die Datenweitergabelatenz im schreibgeschützten Replikat.
sys.dm_os_performance_counters Bietet Leistungsindikatoren für die Datenbank-Engine.
sys.dm_exec_query_stats Bietet Ausführungsstatistiken pro Abfrage, z. B. Anzahl von Ausführungen, verwendete CPU-Zeit usw.
sys.dm_exec_query_plan() Bietet zwischengespeicherte Abfragepläne.
sys.dm_exec_sql_text() Stellt Abfragetext für einen zwischengespeicherten Abfrageplan bereit.
sys.dm_exec_query_profiles Stellt den Abfragefortschritt einer ausgeführten Abfrage in Echtzeit bereit.
sys.dm_exec_query_plan_stats() Stellt den letzten bekannten tatsächlichen Ausführungsplan einschließlich Laufzeitstatistiken für eine Abfrage bereit.
sys.dm_io_virtual_file_stats() Bietet Statistiken zu IOPS, Durchsatz und Latenz der Speicherung für alle Datenbankdateien.

Hinweis

Die DMVs sys.resource_stats und sys.elastic_pool_resource_stats in der logischen master-Datenbank geben Daten zur Ressourcenverwendung des primären Replikats zurück.

Überwachen von schreibgeschützten Replikaten mit erweiterten Ereignissen

Eine Sitzung für erweiterte Ereignisse kann nicht über eine Verbindung mit einem schreibgeschützten Replikat erstellt werden. In Azure SQL-Datenbank und Azure SQL Managed Instance werden die Definitionen von datenbankweit gültigen erweiterten Sitzungen, die auf dem primären Replikat erstellt und geändert werden, in schreibgeschützte Replikate repliziert, darunter Georeplikate, und Ereignisse werden in schreibgeschützten Replikaten repliziert.

In Azure SQL Database kann eine erweiterte Ereignissitzung, die auf einer Sitzungsdefinition aus dem primären Replikat basiert, unabhängig von der Sitzung auf dem primären Replikat gestartet und beendet werden.

In Azure SQL Managed Instance müssen Sie, um eine Ablaufverfolgung auf einer schreibgeschützten Replik zu starten, zuerst die Ablaufverfolgung auf der primären Replik starten, bevor Sie die Ablaufverfolgung auf der schreibgeschützten Replik starten können. Wenn Sie die Ablaufverfolgung nicht zuerst auf dem primären Replikat starten, erhalten Sie den folgenden Fehler, wenn Sie versuchen, die Ablaufverfolgung auf dem schreibgeschützten Replikat zu starten:

Msg 3906, Level 16, Status 2, Zeile 1 Fehler beim Aktualisieren der Datenbank „Master“, da die Datenbank schreibgeschützt ist.

Nach dem ersten Starten der Ablaufverfolgung für das primäre Replikat und dann im schreibgeschützten Replikat können Sie die Ablaufverfolgung für das primäre Replikat beenden.

Führen Sie die folgenden Schritte aus, um eine Ereignissitzung in einem schreibgeschützten Replikat abzulegen:

  1. Verbinden Sie einen SSMS Objekt-Explorer oder ein Abfragefenster mit dem schreibgeschützten Replikat.
  2. Beenden Sie die Sitzung im schreibgeschützten Replikat, indem Sie entweder Sitzung beenden im Kontextmenü der Sitzung in Objekt-Explorer auswählen oder ALTER EVENT SESSION [session-name-here] ON DATABASE STATE = STOP; in einem Abfragefenster ausführen.
  3. Verbinden Sie den Objekt-Explorer oder ein Abfragefenster mit dem schreibgeschützten Replikat.
  4. Legen Sie die Sitzung im primären Replikat ab, indem Sie entweder Löschen im Kontextmenü der Sitzung auswählen oder indem Sie DROP EVENT SESSION [session-name-here] ON DATABASE; ausführen.

Transaktionsisolationsebene auf schreibgeschützten Replikaten

Transaktionen auf schreibgeschützten Replikaten verwenden immer die Momentaufnahme-Transaktionsisolationsstufe, unabhängig von der Transaktionsisolationsebene der Sitzung und unabhängig von Abfragehinweisen. Die Momentaufnahmeisolation verwendet Zeilenversionsverwaltung, um Blockierungsszenarien zu vermeiden, in denen Reader Writer blockieren.

Wenn eine Transaktion mit Momentaufnahmeisolation auf Objektmetadaten zugreift, die in einer anderen gleichzeitig stattfindenden Transaktion geändert wurden, kann in seltenen Fällen der Fehler 3961 auftreten: „Fehler bei der Momentaufnahme-Isolationstransaktion in der %.*ls-Datenbank, weil das von der Anweisung zugegriffene Objekt durch eine DDL-Anweisung in einer anderen gleichzeitigen Transaktion seit dem Beginn dieser Transaktion geändert wurde. Der Vorgang ist nicht zulässig, weil für die Metadaten keine Versionsverwaltung durchgeführt wird. Das gleichzeitige Update von Metadaten kann in Kombination mit der Momentaufnahmeisolation zu Inkonsistenzen führen.“

Abfragen mit langer Ausführungszeit für schreibgeschützte Replikate

Abfragen, die für schreibgeschützte Replikate ausgeführt werden, müssen auf die Metadaten für die in der Abfrage referenzierten Objekte (Tabellen, Indizes, Statistiken usw.) zugreifen. Wenn Objektmetadaten im primären Replikat geändert werden, während eine Abfrage eine Sperre für das entsprechende Objekt im schreibgeschützten Replikat enthält, kann die Abfrage in seltenen Fällen den Prozess blockieren, der Änderungen vom primären Replikat auf das schreibgeschützte Replikat anwendet. Wenn eine solche Abfrage über einen längeren Zeitraum ausgeführt wird, führt dies dazu, dass das schreibgeschützte Replikat mit dem primären Replikat nicht mehr synchronisiert ist. Bei Replikaten, die potenzielle Failoverziele sind (sekundäre Replikate auf den Dienstebenen „Premium“ und „Unternehmenskritisch“, Hyperscale-Hochverfügbarkeitsreplikate und alle Georeplikate), würde dies im Falle eines Failovers auch die Datenbankwiederherstellung verzögern, was zu längeren Ausfallzeiten als erwartet führen würde.

Wenn eine Abfrage mit langer Ausführungszeit für ein schreibgeschützten Replikat diese Art von Blockierung direkt oder indirekt verursacht, wird sie möglicherweise automatisch beendet, um übermäßige Datenlatenz und potenzielle Auswirkungen auf die Datenbankverfügbarkeit zu vermeiden. Die Sitzung erhält den Fehler 1219, „Die Sitzung wurde aufgrund eines DDL-Vorgangs hoher Priorität getrennt“ oder den Fehler 3947, „Die Transaktion wurde abgebrochen, da die sekundäre Compute-Instanz die Wiederholung nicht aufholen konnte. Wiederholen Sie die Transaktion.“

Hinweis

Wenn beim Ausführen von Abfragen für ein schreibgeschütztes Replikat einer der Fehler 3961, 1219 oder 3947 angezeigt wird, wiederholen Sie die Abfrage. Vermeiden Sie alternativ Vorgänge, bei denen Objektmetadaten (Schemaänderungen, Indexwartung, Statistikupdates usw.) im primären Replikat geändert werden, während Abfragen mit langer Ausführungszeit für sekundäre Replikate ausgeführt werden.

Tipp

Wenn eine Verbindung mit einem schreibgeschützten Replikat besteht, können auf den Dienstebenen „Premium“ und „Unternehmenskritisch“ die Spalten redo_queue_size und redo_rate in der DMV sys.dm_database_replica_states zum Überwachen der Datensynchronisierung verwendet werden und dadurch als Indikatoren für die Datenweitergabelatenz beim schreibgeschützten Replikat herangezogen werden.

Aktivieren und Deaktivieren der Leseskalierung für SQL-Datenbank

Für SQL Managed Instance wird die horizontale Leseskalierung auf der Dienstebene „Unternehmenskritisch“ automatisch aktiviert. Sie ist hier auf der Dienstebene „Universell“ nicht verfügbar. Die horizontale Leseskalierung kann nicht deaktiviert und erneut aktiviert werden.

Für SQL-Datenbank ist die horizontale Leseskalierung auf den Dienstebenen „Premium“, „Unternehmenskritisch“ und „Hyperscale“ standardmäßig aktiviert. Für die Dienstebenen „Basic“, „Standard“ oder „Universell“ kann die horizontale Leseskalierung nicht aktiviert werden. Für Hyperscale-Datenbanken, die ohne sekundäre Replikate konfiguriert sind, wird die horizontale Leseskalierung automatisch deaktiviert.

Bei einzelnen Datenbanken und Pooldatenbanken in Azure SQL Datenbank können Sie die horizontale Leseskalierung auf den Dienstebenen „Premium“ oder „Unternehmenskritisch“ mit dem Azure-Portal und mit Azure PowerShell deaktivieren und erneut aktivieren. Diese Optionen sind für SQL Managed Instance nicht verfügbar, da die horizontale Leseskalierung hier nicht deaktiviert werden kann.

Hinweis

Für Singletons und Pools für elastische Datenbanken wird die Möglichkeit, die horizontale Leseskalierung zu deaktivieren, aus Gründen der Abwärtskompatibilität bereitgestellt. Für verwaltete Instanzen der Dienstebene Unternehmenskritisch kann die horizontale Leseskalierung nicht deaktiviert werden.

Azure-Portal

Für Azure SQL-Datenbank können Sie die Einstellung für die horizontale Leseskalierung im Datenbankbereich Compute + Speicher verwalten (unter Einstellungen). Das Azure-Portal kann nicht zum Aktivieren oder Deaktivieren der horizontalen Leseskalierung für Azure SQL Managed Instance verwendet werden.

PowerShell

Wichtig

Das Azure Resource Manager-Modul von PowerShell wird weiterhin unterstützt, aber alle zukünftigen Entwicklungen erfolgen für das Az.Sql-Modul. Für das Azure Resource Manager-Modul werden mindestens bis Dezember 2020 weiterhin Fehlerbehebungen veröffentlicht. Die Argumente für die Befehle im Az-Modul und den Azure Resource Manager-Modulen sind im Wesentlichen identisch. Weitere Informationen zur Kompatibilität finden Sie in der Einführung in das neue Azure PowerShell Az-Modul.

Für die Verwaltung der horizontalen Leseskalierung in Azure PowerShell ist das Azure PowerShell-Release von Dezember 2016 oder eine neuere Version erforderlich. Das neueste PowerShell-Release finden Sie unter Azure PowerShell.

In Azure SQL-Datenbank aktivieren oder deaktivieren Sie die horizontale Leseskalierung in Azure PowerShell, indem Sie das Cmdlet Set-AzSqlDatabase aufrufen und für den Parameter -ReadScale den gewünschten Wert (Enabled oder Disabled) übergeben. Bei SQL Managed Instance ist keine Möglichkeit zum Deaktivieren der horizontalen Leseskalierung verfügbar.

So deaktivieren Sie die horizontale Leseskalierung für eine vorhandene Datenbank (ersetzen Sie die Elemente in spitzen Klammern durch die richtigen Werte für Ihre Umgebung, und löschen Sie die Klammern)

Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Disabled

So deaktivieren Sie die horizontale Leseskalierung für eine neue Datenbank (ersetzen Sie die Elemente in spitzen Klammern durch die richtigen Werte für Ihre Umgebung, und löschen Sie die Klammern)

New-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Disabled -Edition Premium

So aktivieren Sie die horizontale Leseskalierung für eine vorhandene Datenbank erneut (ersetzen Sie die Elemente in spitzen Klammern durch die richtigen Werte für Ihre Umgebung, und löschen Sie die Klammern)

Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Enabled

REST-API

Verwenden Sie zum Erstellen einer Datenbank mit deaktivierter horizontaler Leseskalierung oder zum Ändern der Einstellung für eine vorhandene Datenbank die folgende Methode. Legen Sie dabei die readScale-Eigenschaft wie in der folgenden Beispielanforderung gezeigt auf Enabled oder Disabled fest.

Method: PUT
URL: https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{GroupName}/providers/Microsoft.Sql/servers/{ServerName}/databases/{DatabaseName}?api-version= 2014-04-01-preview
Body: {
   "properties": {
      "readScale":"Disabled"
   }
}

Weitere Informationen finden Sie unter Databanken – Erstellen oder Aktualisieren.

Verwenden der Datenbank tempdb auf einem schreibgeschützten Replikat

Die Datenbank tempdb auf dem primären Replikat wird nicht in den schreibgeschützten Replikaten repliziert. Jedes Replikat verfügt über eine eigene Datenbank tempdb, die beim Erstellen des Replikats erstellt wird. Dadurch wird sichergestellt, dass tempdb aktualisiert und während der Abfrageausführung geändert werden kann. Wenn Ihre schreibgeschützte Workload von der Verwendung von tempdb-Objekten abhängig ist, sollten Sie diese Objekte als Teil derselben Workload erstellen, während eine Verbindung mit einem schreibgeschützten Replikat besteht.

Verwenden der horizontalen Leseskalierung mit georeplizierten Datenbanken

Georeplizierte sekundäre Datenbanken weisen dieselbe Hochverfügbarkeitsarchitektur wie primäre Datenbanken auf. Wenn Sie eine Verbindung mit der georeplizierten sekundären Datenbank mit aktivierter horizontaler Leseskalierung herstellen, werden Ihre Sitzungen mit ApplicationIntent=ReadOnly ebenso an eines der Replikate mit Hochverfügbarkeit weitergeleitet wie an die primäre Datenbank mit Schreibzugriff. Die Sitzungen ohne ApplicationIntent=ReadOnly werden an das primäre Replikat der georeplizierten sekundären Datenbank weitergeleitet, das ebenfalls schreibgeschützt ist.

Auf diese Weise können durch die Erstellung eines Georeplikats mehrere zusätzliche schreibgeschützte Replikate für eine primäre Datenbank mit Lese-/Schreibzugriff bereitgestellt werden. Jedes zusätzliche Georeplikat stellt einen weiteren Satz schreibgeschützter Replikate bereit. Georeplikate können in jeder Azure-Region erstellt werden, einschließlich der Region der primären Datenbank.

Hinweis

Es gibt kein automatisches Roundrobin oder ein anderes Lastenausgleichsrouting zwischen den Replikaten einer georeplizierten sekundären Datenbank, mit Ausnahme eines Hyperscale-Georeplikats mit mehr als einem Hochverfügbarkeitsreplikat. In diesem Fall werden Sitzungen mit schreibgeschützter Absicht auf alle Hochverfügbarkeitsreplikate eines Georeplikats verteilt.

Featureunterstützung für schreibgeschützte Replikate

Im Folgenden finden Sie eine Liste von Verhaltensweisen einiger Features für schreibgeschützte Replikate:

  • Die Überwachung von schreibgeschützten Replikaten wird automatisch aktiviert. Weitere Informationen zur Hierarchie der Speicherordner, zu Namenskonventionen und zum Protokollformat finden Sie unter Überwachungsprotokollformate in Azure SQL-Datenbank.
  • Query Performance Insight basiert auf Daten aus dem Abfragespeicher, der derzeit keine Aktivitäten auf dem schreibgeschützten Replikat nachverfolgt. Von Query Performance Insight werden keine Abfragen gezeigt, die auf dem schreibgeschützten Replikat ausgeführt werden.
  • Die automatische Optimierung basiert auf dem Abfragespeicher, wie im Dokument Automatische Optimierung ausführlich angegeben. Die automatische Optimierung funktioniert nur für Workloads, die auf dem primären Replikat ausgeführt werden.

Nächste Schritte