Freigeben über

Link zu bewährten Methoden für Managed Instance – Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL Managed Instance

In diesem Artikel werden bewährte Methoden zur Verwendung des Links Managed Instance beschrieben, um Daten zwischen Azure SQL Managed Instance und Ihren überall gehosteten SQL Server-Instanzen zu replizieren, was nahezu echtzeitbasierte Datenreplikation zwischen den verknüpften Replikaten bietet.

Regelmäßiges Erstellen von Protokollsicherungen

Wenn SQL Server Ihre erste primäre Instanz ist, ist es wichtig, die erste Protokollsicherung auf SQL Server nach Abschluss des anfänglichen Seedings zu übernehmen, wenn sich die Datenbank nicht mehr im Zustand Wiederherstellen… in Azure SQL Managed Instance befindet. Führen Sie anschließend regelmäßig SQL Server-Transaktionsprotokollsicherungen durch, um eine gesunde Größe der Transaktionsprotokolldatei aufrechtzuerhalten, während SQL Server in der primären Rolle ist.

Das Linkfeature repliziert Daten mithilfe des Konzepts der verteilten Verfügbarkeitsgruppen, das auf dem Technologiestapel der Always On-Verfügbarkeitsgruppen basiert. Die Datenreplikation mit verteilten Verfügbarkeitsgruppen basiert auf der Replikation von Transaktionsprotokolldatensätzen. Auf der primären SQL Server-Instanz können keine Transaktionsprotokolldatensätze aus der Datenbank gekürzt werden, solange sie nicht in die Datenbank des sekundären Replikats repliziert wurden. Wird die Replikation der Transaktionsprotokolldatensätze aufgrund von Netzwerkverbindungsproblemen langsam ausgeführt oder blockiert, wird die Protokolldatei auf der primären Instanz immer größer. Wie schnell dies geschieht, hängt von der Workloadintensität und der Netzwerkgeschwindigkeit ab. Bei längeren Netzwerkverbindungsausfällen und einer hohen Arbeitsauslastung auf der primären Instanz kann die Protokolldatei den gesamten verfügbaren Speicherplatz beanspruchen.

Durch das Ausführen regulärer Transaktionsprotokollsicherungen wird das Transaktionsprotokoll abgeschnitten und das Risiko minimiert, dass aufgrund des Protokolldateiwachstums der primären SQL Server-Instanz nicht mehr Speicherplatz vorhanden ist. Es ist keine zusätzliche Aktion erforderlich, wenn SQL-verwaltete Instanz die primäre ist, da Protokollsicherungen bereits automatisch ausgeführt werden. Regelmäßige Protokollsicherungen auf Ihrem primären SQL Server erhöhen die Resilienz Ihrer Datenbank gegenüber ungeplanten Protokollvergrößerungen. Planen Sie z. B. tägliche Protokollsicherungen mithilfe eines Auftrags des SQL Server-Agents.

Für die Sicherung der Protokolldatei können Sie, wie im folgenden Beispiel gezeigt, ein Transact-SQL-Skript (T-SQL) verwenden. Ersetzen Sie die Platzhalter im Beispielskript durch den Namen Ihrer Datenbank, den Namen und Pfad der Sicherungsdatei und die Beschreibung.

Verwenden Sie zur Sicherung Ihres Transaktionsprotokolls das folgende T-SQL-Beispielskript für SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Verwenden Sie den folgenden T-SQL-Befehl, um den von Ihrer Datenbank in SQL Server verwendeten Protokollspeicherplatz zu überprüfen:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

Die Abfrageausgabe ähnelt der folgenden Ausgabe für die Beispieldatenbank tpcc:

Screenshot: Ergebnisse des Befehls zeigen die Größe der Protokolldatei und des verwendeten Speicherplatzes

In diesem Beispiel nutzt die Datenbank 76 % des verfügbaren Protokollspeicherplatzes bei einer absoluten Größe der Protokolldatei von ungefähr 27 GB (27.971 MB). Die Schwellenwerte für Aktionen variieren je nach Workload. Im vorherigen Beispiel sind die Größe des Transaktionsprotokolls und der Prozentsatz der Protokollnutzung in der Regel ein Hinweis darauf, dass Sie eine Transaktionsprotokollsicherung durchführen sollten, um die Protokolldatei zu kürzen und etwas Speicherplatz freizugeben, oder dass Sie Protokollsicherungen häufiger ausführen sollten. Es könnte auch ein Hinweis darauf sein, dass die Kürzung des Transaktionsprotokolls durch offene Transaktionen blockiert wird. Weitere Informationen zur Problembehandlung beim Transaktionsprotokoll in SQL Server finden Sie unter Problembehandlung bei vollen Transaktionsprotokollen (SQL Server-Fehler 9002). Weitere Informationen zur Problembehandlung für ein Transaktionsprotokoll in Azure SQL Managed Instance finden Sie unter Problembehandlung von Transaktionsprotokollfehlern mit Azure SQL Managed Instance.

Hinweis

Bei der Teilnahme an einem Link werden automatisierte vollständige und Transaktionsprotokollsicherungen aus SQL Managed Instance entnommen, unabhängig davon, ob es sich um das primäre Replikat handelt. Differenzielle Sicherungen werden nicht übernommen, was zu längeren Wiederherstellungszeiten führen kann.

Leistungskapazität zwischen Replikaten abgleichen

Wenn Sie das Verknüpfungsfeature verwenden, ist es wichtig, die Leistungskapazität zwischen SQL Server und SQL Managed Instance abzugleichen, um Leistungsprobleme zu vermeiden, wenn das sekundäre Replikat nicht mit der Replikation des primären Replikats oder nach dem Failover schritthalten kann. Die Leistungskapazität umfasst CPU-Kerne (oder vCores in Azure), Arbeitsspeicher und E/A-Durchsatz.

Sie können die Leistung der Replikation mit der Größe der Wiederholen-Warteschlange für das sekundäre Replikat überprüfen. Die Größe der Wiederholen-Warteschlange gibt die Anzahl der Protokolldatensätze an, die warten, um das sekundäre Replikat neu zu erstellen. Eine konsistent hohe Wiederholen-Warteschlangengröße gibt an, dass das sekundäre Replikat nicht mit dem primären Replikat schritthalten kann. Sie können die Größe der Wiederholen-Warteschlange wie folgt überprüfen:

Wenn die Größe der Wiederholen-Warteschlange konsistent hoch ist, sollten Sie die Ressourcen für das sekundäre Replikat erhöhen.

Zertifikat rotieren

Es ist möglich, dass das Zertifikat, das Sie zum Sichern des Endpunkts für die Datenbankspiegelung verwenden, ablaufen kann, was zu einer Leistungsminderung der Verlinkung führen kann. Um dieses Problem zu verhindern, erneuern Sie das Zertifikat, bevor es abläuft.

Verwenden Sie den folgenden Transact-SQL-Befehl (T-SQL), um das Ablaufdatum des aktuellen Zertifikats zu überprüfen:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Wenn Ihr Zertifikat bald abläuft oder bereits abgelaufen ist, können Sie ein neues Zertifikat erstellen und dann den vorhandenen Endpunkt ändern, um das aktuelle Zertifikat zu ersetzen.

Sobald der Endpunkt für die Verwendung des neuen Zertifikats konfiguriert ist, können Sie das abgelaufene Zertifikat entfernen.

Hinzufügen von Ablaufverfolgungsflags beim Starten

Sie können zwei Ablaufverfolgungs-Flags (-T1800 und-T9567) als Startparameter in SQL Server hinzufügen, um die Leistung der Datenreplikation über das Linkfeature zu optimieren. Weitere Informationen finden Sie unter Aktivieren von Ablaufverfolgungsflags beim Starten.

Zugehöriger Inhalt

So verwenden Sie den Link:

Weitere Informationen zum Link finden Sie unter:

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter: