Freigeben über

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

Gilt für:Azure SQL-DatenbankAzure 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ügbarkeits-(HA)-Repliken können zum Load-Balancing von schreibgeschützten Workloads verwendet werden, die mehr Ressourcen benötigen als auf einer sekundären HA-Replik verfügbar sind.

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.

Das folgende Diagramm veranschaulicht das Feature für Premium- und Business Critical-Datenbanken und von SQL verwaltete Instanzen.

Diagramm, das schreibgeschützte Replikate zeigt.

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 eine Sitzung die Verbindung wiederherstellt, wird sie möglicherweise mit einem Replikat verbunden, das sich zu 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 mithilfe von SQL Server Management Studio (SSMS) herzustellen, wählen Sie "Optionen" aus:

Screenshot: Schaltfläche „SSMS-Optionen“

Wählen Sie zusätzliche Verbindungsparameter aus, und geben ApplicationIntent=ReadOnlySie es ein, und wählen Sie dann "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

Sie haben eine Vielzahl von Möglichkeiten, schreibgeschützte Replikate zu überwachen, darunter Dynamic Management Views (DMVs), erweiterte Ereignisse und Datenbank-Überwacher (Vorversion).

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.

Nachdem Sie das Tracing zunächst auf der primären Replik und dann auf der schreibgeschützten Replik gestartet haben, können Sie das Tracing auf der primären Replik stoppen.

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.

In seltenen Fällen greift eine Snapshot-Isolationstransaktion auf Objektmetadaten zu, die in einer anderen gleichzeitigen Transaktion geändert wurden, wobei möglicherweise Fehler 3961 angezeigt wird, Snapshot-Isolationstransaktion ist in der Datenbank 'Datenbankname' fehlgeschlagen, da das Objekt, auf das die Anweisung zugegriffen hat, von einer DDL-Anweisung in einer anderen gleichzeitigen Transaktion seit dem Beginn dieser Transaktion geändert wurde. Dies ist unzulässig, da die Metadaten nicht versioniert sind. Wenn eine gleichzeitige Aktualisierung der Metadaten mit der Snapshot-Isolation gemischt wird, kann dies 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 lange ausgeführte Abfrage für ein schreibgeschütztes Replikat direkt oder indirekt diese Art von Blockierung verursacht, kann sie automatisch beendet werden, um übermäßige Datenlatenz und potenzielle Auswirkungen auf die Datenbankverfügbarkeit zu vermeiden. Die Sitzung empfängt den Fehler 1219, Ihre Sitzung wurde aufgrund eines DDL-Vorgangs mit hoher Priorität getrennt, oder Fehler 3947, die Transaktion wurde abgebrochen, da es der sekundären Rechenvorgangseinheit nicht gelang, das Redo-Protokoll aufzuholen. Wiederholen Sie die Transaktion.

Da Transaktionen mit schreibgeschützten Replikaten immer die Isolationsebene der Momentaufnahmetransaktion verwenden, kann eine lang laufende Abfrage auf einem schreibgeschützten Replikat die Bereinigung des Ghost- oder persistenten Versionsspeichers (PVS) für das primäre Replikat blockieren, wenn sie kürzlich gelöschte Zeilen oder ältere Zeilenversionen liest. Eine Verzögerung bei der Ghost- oder PVS-Bereinigung kann sich auf Workloads für das primäre Replikat auswirken. Weitere Informationen zur Problembehandlung von PVS-Bereinigungsverzögerungen finden Sie unter Überwachen und Beheben von Problemen mit der beschleunigten Datenbankwiederherstellung.

Umgekehrt wird eine lang andauernde Abfrage für ein schreibgeschütztes Replikat, die kürzlich gelöschte Zeilen oder ältere Zeilenversionen liest und diese Zeilen oder Versionen möglicherweise nicht mehr auf dem primären Replikat (z. B. aufgrund eines Skalierungsvorgangs) verfügbar sind, mit Fehler 3948 beendet: Die Transaktion wurde aufgrund der Änderung der Konfiguration/Zustand des Verfügbarkeitsreplikats oder weil verwaiste Datensätze auf dem primären und sekundären Verfügbarkeitsreplikat gelöscht werden, die möglicherweise von Abfragen benötigt werden, die unter Snapshot-Isolation ausgeführt werden, beendet. Wiederholen Sie die Transaktion.

Hinweis

Wenn Beim Ausführen von Abfragen für ein schreibgeschütztes Replikat Fehler 3961, 1219, 3947 oder 3948 angezeigt wird, wiederholen Sie die Abfrage. Vermeiden Sie alternativ Vorgänge, die Objektmetadaten (Schemaänderungen, Indexwartung, Statistikaktualisierungen usw.) für das primäre Replikat ändern oder das primäre Replikat skalieren, während lange ausgeführte Abfragen auf sekundären Replikaten ausgeführt werden.

Tipp

In den Service-Tiers Premium und Business Critical können bei einer Verbindung mit einer schreibgeschützten Replik die Spalten redo_queue_size und redo_rate in der DMV sys.dm_database_replica_states zur Überwachung des Datensynchronisationsprozesses verwendet werden und dienen als Indikatoren für die Latenz bei der Datenübertragung auf der schreibgeschützten Replik.

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. Das PowerShell-Modul Azure Resource Manager (AzureRM) empfängt keine Fehlerbehebungen mehr. 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.

Die Verwaltung der horizontalen Leseskalierung in Azure PowerShell erfordert die Azure PowerShell-Version vom Dezember 2016 oder eine neuere Version. 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 Enabled den gewünschten Wert (Disabled oder -ReadScale) ü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 Sie die tempdb-Datenbank 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:

Verwandte Inhalte