Problembehandlung bei Link – Azure SQL Managed Instance

Gilt für:Azure SQL Managed Instance

In diesem Artikel erfahren Sie, wie Sie Probleme mit einem link zwischen SQL Server und Azure SQL Managed Instance überwachen und beheben.

Sie können den Status des Links mit Transact-SQL (T-SQL), Azure PowerShell oder dem Azure CLI überprüfen. Wenn Probleme auftreten, können Sie die Fehlercodes verwenden, um das Problem zu beheben.

Viele Probleme beim Erstellen der Verbindung können behoben werden, indem das Netzwerk zwischen den beiden Instanzen überprüft und die Umgebung für die Verbindung ordnungsgemäß vorbereitet wurde.

Anfängliche Aussaat

Beim Einrichten einer Verbindung zwischen SQL Server und Azure SQL Managed Instance gibt es eine anfängliche Seedingphase, bevor die Datenreplikation beginnt. Die Seedingphase zu Beginn ist der längste und teuerste Teil des Vorgangs. Sobald das anfängliche Seeding abgeschlossen ist, werden die Daten synchronisiert, und nur nachfolgende Datenänderungen werden repliziert. Die Zeit, die für das anfängliche Seeding benötigt wird, ist abhängig von der Größe der Daten, der Intensität der Workloads auf den primären Datenbanken und der Geschwindigkeit der Verbindung zwischen den Netzwerken der primären und der sekundären Replikate.

Wenn die Geschwindigkeit der Verbindung zwischen den beiden Instanzen langsamer als erforderlich ist, wirkt sich dies wahrscheinlich erheblich auf die Zeit für das Seeding aus. Sie können die angegebene Seedinggeschwindigkeit, die Gesamtgröße der Daten und die Verknüpfungsgeschwindigkeit verwenden, um zu schätzen, wie lange die anfängliche Seedingphase dauert, bevor die Datenreplikation beginnt. Bei einer einzelnen Datenbank mit 100 GB würde die anfängliche Startphase etwa 1,2 Stunden dauern, wenn der Link 84 GB pro Stunde pushen kann und keine anderen Datenbanken auf eine andere Verknüpfung gesetzt werden. Wenn über die Verbindung nur 10 GB pro Stunde übertragen werden können, dauert das Seeding einer 100-GB-Datenbank ungefähr 10 Stunden. Wenn mehrere Datenbanken über mehrere Verknüpfungen repliziert werden sollen, wird das Seeding parallel ausgeführt, und in Kombination mit einer langsamen Verbindungsgeschwindigkeit kann die anfängliche Seedingphase erheblich länger dauern, insbesondere, wenn das parallele Seeding von Daten aus allen Datenbanken die verfügbare Linkbandbreite überschreitet.

Die anfängliche Seedingphase ist nicht widerstandsfähig für Netzwerkunterbrechungen und Instanzwartungs- oder Failovervorgänge. Wenn die bidirektionale Verbindung zwischen SQL Server und SQL Managed Instance vorübergehend verloren geht oder wenn SQL Server oder SQL Managed Instance während der ersten Seeding-Phase neu gestartet oder fehlgeschlagen ist, wird das Seeding neu gestartet.

Von Bedeutung

Die anfängliche Phase des Seedings kann bei extrem niedrigen Geschwindigkeiten oder stark beanspruchten Verbindungen Tage dauern. In diesem Fall kann beim Erstellen der Verbindung eine Zeitüberschreitung auftreten. Das Erstellen der Verbindung wird nach 6 Tagen automatisch abgebrochen.

Überprüfen des Verknüpfungszustands

Wenn Probleme mit einem Link auftreten, können Sie SQL Server Management Studio (SSMS), Transact-SQL (T-SQL), Azure PowerShell oder die Azure CLI verwenden, um Informationen zum aktuellen Status des Links abzurufen.

Verwenden Sie T-SQL für schnelle Statusdetails des Verknüpfungszustands, und verwenden Sie dann Azure PowerShell oder die Azure CLI, um umfassende Informationen zum aktuellen Status des Links zu erhalten.

Die Linküberwachung ist ab SQL Server Management Studio (SSMS) 21.0 (Vorschau) verfügbar.

Führen Sie die folgenden Schritte aus, um den Linkstatus in SSMS zu überprüfen:

Stellen Sie eine Verbindung mit einem Replikat her, das den Link hosten soll.
Erweitern Sie in Objekt-ExplorerAlways On High Availability, und erweitern Sie dann Availability Groups.
Klicken Sie mit der rechten Maustaste auf den Namen des Links, und wählen Sie dann "Eigenschaften " aus, um das Fenster " Verknüpfungseigenschaften " zu öffnen:
Im Fenster " Verknüpfungseigenschaften " werden nützliche Informationen zum Link angezeigt, z. B. Replikatinformationen, Linkstatus und Ablaufdatum des Endpunktzertifikats:

Verwenden Sie T-SQL, um den Zustand der Verknüpfung während der Seedingphase oder nach Beginn der Datensynchronisierung zu bestimmen. Der sys.dm_hadr_physical_seeding_stats DMV kann verwendet werden, um den anfänglichen Seedingstatus nachzuverfolgen. Die estimate_time_complete_utc Spalte basiert auf der aktuellen transfer_rate_bytes_per_second und nicht komprimierten verbleibenden Datengröße (wenn is_compression_enabled = 0). Bei der Managed-Instance-Verknüpfung wird die Datenkomprimierung verwendet, sodass estimate_time_complete_utc voraussichtlich eine Überschätzung sein wird.

Verwenden Sie die folgende T-SQL-Abfrage, um den Status der Verknüpfung während der Seedingphase für die SQL Server oder SQL Managed Instance zu bestimmen, die die Datenbank im Seeding über den Link hostet:

SELECT
    ag.local_database_name AS 'Local database name',
    ar.current_state AS 'Current state',
    ar.is_source AS 'Is source',
    ag.internal_state_desc AS 'Internal state desc',
    ag.database_size_bytes / 1024 / 1024 AS 'Database size MB',
    ag.transferred_size_bytes / 1024 / 1024 AS 'Transferred MB',
    ag.transfer_rate_bytes_per_second / 1024 / 1024 AS 'Transfer rate MB/s',
    ag.total_disk_io_wait_time_ms / 1000 AS 'Total Disk IO wait (sec)',
    ag.total_network_wait_time_ms / 1000 AS 'Total Network wait (sec)',
    ag.is_compression_enabled AS 'Compression',
    ag.start_time_utc AS 'Start time UTC',
    ag.estimate_time_complete_utc as 'Estimated time complete UTC',
    ar.completion_time AS 'Completion time',
    ar.number_of_attempts AS 'Attempt No'
FROM sys.dm_hadr_physical_seeding_stats AS ag
    INNER JOIN sys.dm_hadr_automatic_seeding AS ar
    ON local_physical_seeding_id = operation_id

-- Estimated seeding completion time
SELECT DISTINCT CONVERT(VARCHAR(8), DATEADD(SECOND, DATEDIFF(SECOND, start_time_utc, estimate_time_complete_utc) ,0), 108) as 'Estimated complete time'
FROM sys.dm_hadr_physical_seeding_stats

Wenn die Abfrage keine Ergebnisse zurückgibt, wurde der Seedingprozess nicht gestartet oder ist bereits abgeschlossen.

Verwenden Sie die folgende T-SQL-Abfrage in der primären Instanz, um die Integrität des Links zu überprüfen, sobald die Synchronisierung beginnt:

DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   rs.synchronization_health_desc [Link sync health]
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 0 AND rs.role = 2 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

Die Abfrage gibt die folgenden möglichen Werte zurück:

kein Ergebnis: Die Abfrage wurde in der sekundären Instanz ausgeführt.
HEALTHY: Die Verknüpfung ist fehlerfrei, und Daten werden zwischen den Replikaten synchronisiert.
NOT_HEALTHY: Die Verbindung ist fehlerhaft, und Daten werden nicht zwischen den Replikaten synchronisiert.

Verwenden Sie Get-AzSqlInstanceLink, um Linkstatusinformationen mit PowerShell abzurufen.

Führen Sie den folgenden Beispielcode in Azure Cloud Shell aus, oder installieren Sie das Modul Az.SQL lokal.

$ManagedInstanceName = "<ManagedInstanceName>" # The name of your linked SQL Managed Instance
$DAGName = "<DAGName>" # distributed availability group name

# Find out the resource group name 
$ResourceGroupName = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName 

# Show link state details 
(Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroupName -InstanceName $ManagedInstanceName -Name $DAGName).Databases

Verwenden Sie az sql mi link show, um Linkstatusinformationen mit dem Azure CLI abzurufen.

# type "az" to use Azure CLI
managedInstanceName = "<ManagedInstanceName>" # The name of your linked SQL Managed Instance
dagName = "<DAGName>" # distributed availability group name
rgName = "<RGName>" # the resource group for the linked SQL Managed Instance  

# Print link state details 
az sql mi link show --resource-group $rgName --instance-name $managedInstanceName --name $dagName

Der Wert replicaState beschreibt den aktuellen Link. Wenn der Zustand auch Error enthält, ist während des im Zustand aufgeführten Vorgangs ein Fehler aufgetreten. Beispielsweise gibt LinkCreationError an, dass beim Erstellen der Verknüpfung ein Fehler aufgetreten ist.

Einige mögliche replicaState-Werte sind:

CreatingLink: erstes Seeding
LinkSynchronizing: Die Datenreplikation wird durchgeführt.
LinkFailoverInProgress: Failover wird ausgeführt

Eine vollständige Liste der Verbindungsstatuseigenschaften erhalten Sie mit dem REST-API-Befehl Verteilte Verfügbarkeitsgruppen – GET.

Geplante Failoverzeiten laufen ab

Wenn das sekundäre Replikat nicht mit den Änderungen des primären Replikats Schritt halten kann und hinterherhinkt, kann ein geplantes Failover zeitlich überschreiten und fehlgeschlagen einen Fehler erzeugen.

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

Überprüfen Sie den Replikationsabstand zwischen den beiden Instanzen.
Wenn die Replikationsverzögerung hoch ist, warten Sie, bis die sekundäre Replik die primäre Replik einholt. Möglicherweise müssen Sie zusätzliche Schritte zur Problembehandlung ausführen, wenn die Verzögerung weiterhin besteht, z. B. das Anhalten von Arbeitslasten für das primäre Replikat, die Verbesserung des Verbindungsnetzwerkdurchsatzes zwischen den beiden Instanzen oder das Erhöhen der Ressourcenkapazität für das sekundäre Replikat.
- Die einfachste Möglichkeit zum Beenden von Arbeitslasten in einem SQL Server primären Replikat ist das Ausschneiden von Anwendungsverbindungen mit der Instanz.
Nachdem das sekundäre Replikat das primäre Replikat erfasst hat, versuchen Sie es erneut mit dem geplanten Failover.

Fehler beim Initialisieren eines Links

Der folgende Fehler kann beim Initialisieren eines Links auftreten (Linkstatus: LinkInitError):

Fehler 41962: Vorgang abgebrochen, da der Link innerhalb von 5 Minuten nicht hergestellt wurde. Überprüfen Sie die Netzwerkkonnektivität, und versuchen Sie es erneut.
Error 41973: Link kann nicht hergestellt werden, da endpoint-Zertifikat von SQL Server nicht ordnungsgemäß in Azure SQL Managed Instance importiert wurde.
Fehler 41974: Link kann nicht hergestellt werden, da endpoint-Zertifikat von SQL Managed Instance nicht ordnungsgemäß in SQL Server importiert wurde.
Fehler 41976: Die Verfügbarkeitsgruppe reagiert nicht. Überprüfen Sie Namen und Konfigurationsparameter, und versuchen Sie es erneut.
Fehler 41986: Verknüpfung kann nicht hergestellt werden, da die Verbindung fehlgeschlagen ist oder das sekundäre Replikat nicht reagiert. Überprüfen Sie Namen, Konfigurationsparameter und Netzwerkkonnektivität, und versuchen Sie es dann erneut.
Fehler 47521: Verknüpfung kann nicht hergestellt werden, da der sekundäre Server die Anforderung nicht empfangen hat. Stellen Sie sicher, dass die Verfügbarkeitsgruppe und Datenbanken auf dem primären Server fehlerfrei sind, und versuchen Sie es erneut.

Fehler beim Erstellen eines Links

Die folgenden Fehler können beim Erstellen eines Links auftreten (Linkstatus: LinkCreationError):

Fehler 41977: Die Zieldatenbank reagiert nicht. Überprüfen Sie die Linkparameter, und versuchen Sie es erneut.
Vorzeitiges Abschneiden des Protokolls: Wenn das Transaktionsprotokoll vor dem Ende des anfänglichen Seedings abgeschnitten wird, wird wahrscheinlich einen der folgenden Fehler angezeigt:
- Fehler 1408: Fehler bei der Replikation in der Remotedatenbank und kann aufgrund fehlender Protokolldateiüberlappungen zwischen primärem und sekundärem Replikat nicht wiederhergestellt werden. Löschen Sie den vorhandenen Link, und erstellen Sie einen neuen Link, um die Replikation neu zu starten.
- Fehler 1412: Replikation zur Remotedatenbank ist fehlgeschlagen und kann aufgrund einer Protokolldateigrößen-Nichtübereinstimmung mit dem primären Replikat nicht wiederhergestellt werden. Löschen Sie den vorhandenen Link, und erstellen Sie einen neuen Link, um die Replikation neu zu starten.

Fehler 1412

Wenn Sie zuerst einen Link erstellen, wird im ersten Teil des Prozesses eine vollständige Sicherung der Datenbank vom primären Replikat zum sekundären Replikat erstellt. Nachdem das Seeding der vollständigen Sicherung abgeschlossen ist, beginnt der Link, Daten zu replizieren, indem differenzielle Daten vom primären Replikat auf das sekundäre Replikat angewendet werden. Dieser Vorgang wird unbegrenzt fortgesetzt, bis ein Failoverbefehl ausgegeben wird oder der Link entfernt wird.

Wenn beim anfänglichen Seeding der vollständigen Sicherung eine Transaktionsprotokollsicherung für das primäre Replikat erfolgt, wird das Transaktionsprotokoll abgeschnitten. Die Verknüpfungserstellung schlägt mit Fehler 1412 fehl, da die daten im Transaktionsprotokoll, die für das anfängliche Seeding erforderlich sind, nicht mehr verfügbar sind. Wenn Fehler 1412 im Fehlerprotokoll des SQL Servers auf Azure SQL Managed Instance angezeigt wird, müssen Sie den Link löschen und neu erstellen.

Um dieses Problem vorab zu vermeiden, unterbrechen Sie Transaktionsprotokollsicherungen während der ersten Seedingphase.

Wenn Transaktionsprotokollsicherungen während der anfänglichen Seedingphase erforderlich sind, insbesondere für sehr große Datenbanken, können Sie auswählen, dass protokollabkürzungen manuell verhindert oder der Prozess mit einem T-SQL-Skript automatisiert wird, um Protokollsicherungen in kritischen Phasen automatisch anzuhalten und wenn dies sicher ist.

Manuelle Verhinderung des Abschneidens von Protokollen

Die Schritte in diesem Abschnitt veranschaulichen das Öffnen einer Transaktion mit einer Dummy-Tabelle, um das Abschneiden von Protokollen während der ersten Seedingphase zu verhindern. Dieser Vorgang erfordert eine manuelle Überwachung des Fortschritts beim Seeding und sorgfältiges Timing, um sicherzustellen, dass die Protokollverkürzung verhindert wird, bis das Seeding abgeschlossen ist.

Seeding-Fortschritt überwachen. Sie können die folgende T-SQL-Abfrage verwenden, um den Fortschritt des anfänglichen Seedings zu überwachen:
```
SELECT * FROM sys.dm_exec_requests WHERE database_id = @dbId AND command = 'VDI_CLIENT_WORKER'
```
Wenn das Seeding sich der 90% Marke nähert, geben Sie in einer Dummy-Tabelle einen BEGIN TRAN Befehl aus, ohne ein Commit durchzuführen. Lassen Sie die Transaktion offen, um das Trunkieren der Protokolle zu verhindern.
Überwachen Sie den Speicherplatz des Transaktionsprotokolls sorgfältig, um sicherzustellen, dass sie die Speicherkapazität nicht überschreitet, während die Transaktion geöffnet ist.
Sobald das Seeding 100% erreicht hat, führen Sie die Transaktion mit COMMIT TRAN.

Führen Sie z. B. jedes Mal, bevor das anfängliche Seeding 90%erreicht, den folgenden Befehl aus, um eine Dummytabelle zu erstellen, um Fehler 1412 zu vermeiden:

-- Create table
CREATE TABLE Prevent1412
(
    Id        INT,
    CreatedAt DATETIME
);

Führen Sie dann, wenn das Seeding fast abgeschlossen ist, den folgenden Befehl aus, um die Log-Trunkierung zu verhindern:

BEGIN TRAN;

INSERT INTO Prevent1412 (Id, CreatedAt)
VALUES (1, GETDATE());

Vorsicht

Nachdem die Transaktion begonnen hat, wird das Transaktionsprotokoll nicht mehr verkleinert. Überwachen Sie daher sorgfältig den Speicherplatz des Transaktionsprotokolls, damit es die Speicherplatzkapazität nicht überschreitet, während die Transaktion aktiv ist.

Nach Abschluss des Seedings können Sie die Transaktion abschließen, um das Protokoll zu kürzen.

COMMIT TRAN;

Nach Abschluss der Migration können Sie die Tabelle 'Dummy' löschen.

DROP TABLE Prevent1412;

Automatisieren von automatischen Pausierungen bei Protokollsicherungen

Alternativ können Sie den Prozess automatisieren, um Protokollsicherungen in kritischen Phasen automatisch anzuhalten, wenn es mit einem T-SQL-Skript sicher ist.

Das folgende Skript kann ausgeführt werden, bevor die Migration beginnt:

-- Get last backup date
SELECT TOP 1 @lastBackupTime = b.backup_finish_date
FROM master.sys.sysdatabases d 
LEFT OUTER JOIN msdb..backupSET b
ON b.database_name = d.name
AND b.type = 'L'
WHERE d.name = @dbName
ORDER BY backup_finish_date DESC
SELECT @diffInMins = DATEDIFF(minute, @lastBackupTime, CURRENT_TIMESTAMP);

-- Get database id and group database id
SELECT @agDbId = group_database_id, @dbId = database_id FROM sys.databases WHERE name = @dbName

-- If there is no group database id, no need for checks
IF (@agDbId IS NOT NULL)
BEGIN
              -- Get last seeding start time and check if backup (VDI client) is actually running
              SELECT TOP 1 @seedingStartTime = start_time, @state = current_state, @agDbId = ag_db_id FROM sys.dm_hadr_automatic_seeding ORDER BY start_time DESC

              IF (@state = 'PENDING' OR @state = 'CHECK_IF_SEEDING_NEEDED' OR @state = 'LIMIT_CONCURRENT_BACKUPS')
                             SET @seedingStarting = 1
              ELSE
                             SET @seedingStarting = 0
              
              SELECT @backupWorkers = COUNT(*) FROM sys.dm_exec_requests WHERE database_id = @dbId AND command = 'VDI_CLIENT_WORKER'

              -- Check if seeding is done by looking at remote replica state and health
              SELECT TOP 1 @db_state = synchronization_state_desc, @db_health = synchronization_health_desc FROM sys.dm_hadr_database_replica_states WHERE database_id = @dbId AND is_local = 0

              IF (@db_state = N'SYNCHRONIZING' AND @db_health = N'HEALTHY')
              SET @seedingDone = 1
              ELSE
              SET @seedingDone = 0
END

-- If X minutes has passed since last log backup, do it, we don't want to wait anymore
IF (@alreadyFailed = 1 or @diffInMins > {set_minutes})
BEGIN
              {do_log_backup}
              SET @alreadyFailed = 1
              CONTINUE;
END

-- If seeding has started and finished take log backups
IF ((@agDbId IS NOT NULL) AND (@seedingStartTime IS NOT NULL) AND (@startTime < @seedingStartTime) AND (@seedingDone = 1))
BEGIN
              {do_log_backup}
              SET @alreadyFailed = 1
              CONTINUE;
END

-- If database is not in ag or
-- If seeding has not started or
-- If seeding is ongoing 
-- Take log backups
IF ((@agDbId IS NULL) OR (@seedingStartTime IS NULL) OR (@startTime > @seedingStartTime) OR (@seedingStarting = 1) or (@backupWorkers > 0))
BEGIN
              {do_log_backup}
              CONTINUE;
END

Inkonsistenter Zustand nach erzwungenem Failover

Nach einem erzwungenen Failover kann ein Split Brain-Szenario auftreten, bei dem sich beide Replikate in der primären Rolle befinden und die Verbindung in einem inkonsistenten Zustand bleibt. Dies kann passieren, wenn Sie während einer Katastrophe auf das sekundäre Replikat umschalten und das primäre Replikat wieder online geht.

Vergewissern Sie sich zunächst, dass Sie es sich um ein Split Brain-Szenario handelt. Dazu können Sie SQL Server Management Studio (SSMS) oder Transact-SQL (T-SQL) verwenden.

Stellen Sie eine Verbindung zu SQL Server und SQL Managed Instance in SSMS her, und erweitern Sie dann im Objekt-Explorer unter dem Knoten der VerfügbarkeitsgruppeVerfügbarkeitsreplikate in Always On High Availability. Wenn zwei verschiedene Replikate als (Primary) aufgeführt werden, handelt es sich um ein Split Brain-Szenario.

Alternativ können Sie das folgende T-SQL-Skript auf both SQL Server ausführen und SQL Managed Instance, um die Rolle der Replikate zu überprüfen:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGName>'
SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states rs 
   ON ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

Wenn für beide Instanzen PRIMARY in der Spalte Verbindungsrolle steht, handelt es sich um ein Split Brain-Szenario.

Um den Split Brain-Zustand aufzuheben, führen Sie zuerst eine Sicherung des Replikats durch, das ursprünglich über die primäre Rolle verfügte. Wenn der ursprüngliche Primärserver ein SQL Server gewesen ist, nehmen Sie ein Tail-Protokollsicherung vor. Wenn die ursprüngliche primäre Instanz eine SQL Managed Instance war, nehmen Sie eine copy-only vollständige Sicherung. Nachdem die Sicherung abgeschlossen ist, setzen Sie die verteilte Verfügbarkeitsgruppe auf die sekundäre Rolle für das Replikat fest, das ursprünglich die primäre Rolle innehatte, nun aber die neue sekundäre Rolle übernehmen wird.

Angenommen, Sie haben ein Failover Ihrer SQL Server-Arbeitslast zu einer Azure SQL Managed Instance erzwungen, und Sie beabsichtigen, Ihre Arbeitslast weiterhin auf der SQL Managed Instance auszuführen, dann nehmen Sie eine Sicherung für das Tail-Protokoll auf dem SQL Server und legen die Verteilte Verfügbarkeitsgruppe in die sekundäre Rolle für den SQL Server fest, wie im folgenden Beispiel:

--Execute on SQL Server 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] 
SET (ROLE = SECONDARY) 
GO

Führen Sie als Nächstes ein geplantes manuelles Failover von SQL Managed Instance zu SQL Server aus, indem Sie den Link verwenden, z. B. das folgende Beispiel:

--Execute on SQL Managed Instance 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER 
GO

Abgelaufenes Zertifikat

Es ist möglich, dass das Zertifikat, das für den Link verwendet wird, abläuft. Wenn das Zertifikat abläuft, schlägt der Link fehl. Um dieses Problem zu beheben, erneuern Sie das Zertifikat.

Bekannte Probleme nach der Migration zu SQL Managed Instance

Berücksichtigen Sie die folgenden bekannten Probleme nach der Migration zu Azure SQL Managed Instance:

Wiederherstellen von Vorgangsfehlern nach der Migration zu SQL Managed Instance

Wenn Sie eine Datenbank in einer Azure SQL Managed Instance von SQL Server 2019 und höheren Versionen mit aktivierter accelerated database recovery migrieren, aber der beständige Versionsspeicher (PVS) auf einen anderen Speicherort als die PRIMARY-Dateigruppe konfiguriert ist, können Fehler bei Wiederherstellungsoperationen in der verwalteten SQL-Zielinstanz auftreten.

Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie den persistent-Versionsspeicher (PVS) auf PRIMARY für die SQL Server Quelldatenbank festlegen, bevor Sie sie zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne die PVS auf PRIMARY festzulegen, können Sie diese Einstellung in der Quelldatenbank auf dem SQL Server vornehmen und die Datenbank dann erneut zur SQL Managed Instance migrieren.

Die beschleunigte Datenbankwiederherstellung kann nach der Migration zu SQL Managed Instance nicht verwendet werden.

Ab SQL Server 2019 können Sie, wenn Sie eine Datenbank zu Azure SQL Managed Instance migrieren und die Quelldatenbank Accelerated database recovery deaktiviert ist, keine beschleunigte Datenbankwiederherstellung für die verwaltete SQL-Zielinstanz verwenden.

Um dieses Problem zu umgehen, vergewissern Sie sich, dass Sie die beschleunigte Datenbankwiederherstellung aktivieren für die SQL Server Quelldatenbank, bevor Sie sie zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne eine beschleunigte Datenbankwiederherstellung zu aktivieren, können Sie sie für die Quelldatenbank SQL Server aktivieren und dann die Datenbank erneut zu sql managed instance migrieren.

SQL Server 2017 und frühere Versionen unterstützen keine beschleunigte Datenbankwiederherstellung, daher gilt dieses Problem nicht für Datenbanken, die aus diesen Versionen von SQL Server migriert wurden.

Der Dienstbroker kann nach der Migration zu SQL Managed Instance nicht verwendet werden.

Wenn Sie eine Datenbank zu Azure SQL Managed Instance migrieren und ServiceBroker in der Quelldatenbank deaktiviert ist, können Sie den Dienstbroker nicht für die verwaltete SQL-Zielinstanz verwenden.

Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie service broker für die Quelldatenbank SQL Server aktivieren, bevor Sie sie zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne den Service Broker zu aktivieren, können Sie sie für die Quelldatenbank SQL Server aktivieren und dann die Datenbank erneut zu SQL Managed Instance migrieren.

Netzwerkkonnektivität testen

Bidirektionale Netzwerkkonnektivität zwischen SQL Server und SQL Managed Instance ist erforderlich, damit die Verbindung funktioniert. Nachdem Sie Ports auf der SQL Server-Seite geöffnet und eine NSG-Regel auf der SQL Managed Instance-Seite konfiguriert haben, testen Sie die Konnektivität entweder mithilfe von SQL Server Management Studio (SSMS) oder Transact-SQL.

Testen Sie das Netzwerk, indem Sie einen temporären SQL-Agent-Auftrag für SQL Server und SQL Managed Instance erstellen, um die Verbindung zwischen den beiden Instanzen zu überprüfen. Wenn Sie die Netzwerküberprüfung in SSMS verwenden, wird der Auftrag automatisch für Sie erstellt und nach Abschluss des Tests gelöscht. Sie müssen den SQL-Agent-Auftrag manuell löschen, wenn Sie Ihr Netzwerk mithilfe von T-SQL testen.

Anmerkung

Das Ausführen von PowerShell-Skripts durch den SQL Server-Agent für SQL Server für Linux wird derzeit nicht unterstützt, sodass es derzeit nicht möglich ist, Test-NetConnection aus dem SQL Server-Agent Auftrag auf SQL Server für Linux auszuführen.

Um den SQL-Agent zum Testen der Netzwerkkonnektivität zu verwenden, benötigen Sie die folgenden Anforderungen:

Der Benutzer, der den Test durchführt, muss über Permissionen verfügen, um einen Auftrag zu erstellen (entweder als sysadmin oder gehört zur SQLAgentOperator-Rolle für msdb) für SQL Server und SQL Managed Instance.
Der SQL Server-Agent-Dienst muss auf dem SQL Server ausgeführt werden. Da der Agent standardmäßig auf SQL Managed Instance aktiviert ist, ist keine zusätzliche Aktion erforderlich.

Beachte Folgendes:

Um falsch negative Ergebnisse zu vermeiden, müssen alle Firewalls entlang des Netzwerkpfads Internet Control Message Protocol (ICMP)-Datenverkehr zulassen.
Um falsch positive Ergebnisse zu vermeiden, müssen alle Firewalls entlang des Netzwerkpfads Datenverkehr im proprietären SQL Server UCS-Protokoll zulassen. Das Blockieren des Protokolls kann zu einem erfolgreichen Verbindungstest führen, aber der Link kann nicht erstellt werden.
Erweiterte Firewall-Setups mit Schutzschienen auf Paketebene müssen ordnungsgemäß konfiguriert werden, um den Datenverkehr zwischen SQL Server und SQL Managed Instance ordnungsgemäß zuzulassen.

SSMS
T-SQL

Führen Sie die folgenden Schritte aus, um die Netzwerkkonnektivität zwischen SQL Server und SQL Managed Instance in SSMS zu testen:

Stellen Sie eine Verbindung mit der Instanz her, die als primäres Replikat in SSMS dient.
Erweitern Sie in Objekt-Explorer Datenbanken, und klicken Sie mit der rechten Maustaste auf die Datenbank, die Sie mit der sekundären Datenbank verknüpfen möchten. Wählen Sie Tasks>Azure SQL Managed Instance link>Test Connection aus, um den Assistenten Network Checker zu öffnen:
Wählen Sie Weiter auf der Seite Einführung des Assistenten für die Netzwerküberprüfung aus.
Wenn alle Anforderungen auf der Seite Voraussetzungen erfüllt sind, wählen Sie Weiter aus. Sorgen Sie andernfalls dafür, dass allen nicht erfüllten Voraussetzungen entsprochen wird, und wählen Sie dann Überprüfung erneut ausführen aus.
Wählen Sie auf der Seite AnmeldenAnmelden aus, um eine Verbindung mit einer anderen Instanz herzustellen, die als sekundäres Replikat dient. Wählen Sie Weiter aus.
Überprüfen Sie die Details auf der Seite "Netzwerkoptionen angeben" und geben Sie ggf. eine IP-Adresse an. Wählen Sie Weiter aus.
Überprüfen Sie auf der Seite Ergebnisse die Aktionen, die der Assistent ausführt, und wählen Sie dann Fertig stellen aus, um die Verbindung zwischen den beiden Replikaten zu testen.
Überprüfen Sie die Seite Ergebnisse, um die Konnektivität zwischen den beiden Replikaten zu überprüfen, und wählen Sie dann Schließen aus, um den Vorgang zu beenden.

Um T-SQL zum Testen der Konnektivität zu verwenden, müssen Sie die Verbindung in beide Richtungen überprüfen. Testen Sie zunächst die Verbindung von SQL Server zu SQL Managed Instance, und testen Sie dann die Verbindung von SQL Managed Instance zu SQL Server.

Testen der Verbindung von SQL Server zu SQL Managed Instance

Verwenden Sie SQL Server-Agent für SQL Server, um Verbindungstests von SQL Server bis SQL Managed Instance auszuführen.

Stellen Sie eine Verbindung mit SQL Managed Instance her, und führen Sie das folgende Skript aus, um parameter zu generieren, die Sie später benötigen:

SELECT 'DECLARE @serverName NVARCHAR(512) = N''' + value + ''''
FROM sys.dm_hadr_fabric_config_parameters
WHERE parameter_name = 'DnsRecordName'

UNION

SELECT 'DECLARE @node NVARCHAR(512) = N''' + NodeName + '.' + Cluster + ''''
FROM (
    SELECT SUBSTRING(replica_address, 0, CHARINDEX('\', replica_address)) AS NodeName,
        RIGHT(service_name, CHARINDEX('/', REVERSE(service_name)) - 1) AppName,
        JoinCol = 1
    FROM sys.dm_hadr_fabric_partitions fp
    INNER JOIN sys.dm_hadr_fabric_replicas fr
        ON fp.partition_id = fr.partition_id
    INNER JOIN sys.dm_hadr_fabric_nodes fn
        ON fr.node_name = fn.node_name
    WHERE service_name LIKE '%ManagedServer%'
        AND replica_role = 2
) t1
LEFT JOIN (
    SELECT value AS Cluster,
        JoinCol = 1
    FROM sys.dm_hadr_fabric_config_parameters
    WHERE parameter_name = 'ClusterName'
    ) t2
    ON (t1.JoinCol = t2.JoinCol)
INNER JOIN (
    SELECT [value] AS AppName
    FROM sys.dm_hadr_fabric_config_parameters
    WHERE section_name = 'SQL'
        AND parameter_name = 'InstanceName'
    ) t3
    ON (t1.AppName = t3.AppName)

UNION

SELECT 'DECLARE @port NVARCHAR(512) = N''' + value + ''''
FROM sys.dm_hadr_fabric_config_parameters
WHERE parameter_name = 'HadrPort';

Die Ergebnisse sollten wie im folgenden Beispiel aussehen:

 DECLARE @node NVARCHAR(512) = N'DB123.tr123456.west-us.worker.database.windows.net'
 DECLARE @port NVARCHAR(512) = N'11002'
 DECLARE @serverName NVARCHAR(512) = N'contoso-instance.12345678.database.windows.net'

Speichern Sie die Ergebnisse, um sie in den nächsten Schritten zu verwenden. Da sich diese Parameter nach einem Failover ändern können, sollten Sie sie bei Bedarf erneut generieren.

Stellen Sie eine Verbindung mit Ihrer SQL Server Instanz her.

Öffnen Sie ein neues Abfragefenster, und fügen Sie das folgende Skript ein:

--START
-- Parameters section
DECLARE @node NVARCHAR(512) = N''
DECLARE @port NVARCHAR(512) = N''
DECLARE @serverName NVARCHAR(512) = N''

--Script section
IF EXISTS (
        SELECT job_id
        FROM msdb.dbo.sysjobs_view
        WHERE name = N'TestMILinkConnection'
        )
    EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
        @delete_unused_schedule = 1

DECLARE @jobId BINARY (16),
    @cmd NVARCHAR(MAX)

EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
    @enabled = 1,
    @job_id = @jobId OUTPUT

SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'Test Port 5022',
    @step_id = 1,
    @cmdexec_success_code = 0,
    @on_success_action = 3,
    @on_fail_action = 3,
    @subsystem = N'PowerShell',
    @command = @cmd,
    @database_name = N'master'

SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'Test HADR Port',
    @step_id = 2,
    @cmdexec_success_code = 0,
    @subsystem = N'PowerShell',
    @command = @cmd,
    @database_name = N'master'

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)'
GO

EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
GO

--Check status every 5 seconds
DECLARE @RunStatus INT

SET @RunStatus = 10

WHILE (@RunStatus >= 4)
BEGIN
    SELECT DISTINCT @RunStatus = run_status
    FROM [msdb].[dbo].[sysjobhistory] JH
    INNER JOIN [msdb].[dbo].[sysjobs] J
        ON JH.job_id = J.job_id
    WHERE J.name = N'TestMILinkConnection'
        AND step_id = 0

    WAITFOR DELAY '00:00:05';
END

--Get logs once job completes
SELECT [step_name],
    SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
    SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
    [run_status],
    [run_duration],
    [message]
FROM [msdb].[dbo].[sysjobhistory] JH
INNER JOIN [msdb].[dbo].[sysjobs] J
    ON JH.job_id = J.job_id
WHERE J.name = N'TestMILinkConnection'
    AND step_id <> 0
    --END

Ersetzen Sie die Parameter @node, @portund @serverName durch die Werte, die Sie aus dem ersten Schritt abgerufen haben.
Führen Sie das Skript aus, und überprüfen Sie die Ergebnisse. Ergebnisse wie das folgende Beispiel sollten angezeigt werden:
Überprüfen Sie die Ergebnisse:
- Das Ergebnis jedes Tests bei TcpTestSucceeded sollte TcpTestSucceeded : Truesein.
- Die RemoteAddresses sollten zum IP-Bereich für das SQL Managed Instance Subnetz gehören.
Wenn die Antwort nicht erfolgreich ist, überprüfen Sie die folgenden Netzwerkeinstellungen:
- Es gibt Regeln sowohl in der Netzwerkfirewall und der Firewall des SQL Server Host-Betriebssystems (Windows/Linux), die den Datenverkehr zum gesamten Subnetz-IP-Bereich von SQL Managed Instance erlauben.
- Es gibt eine NSG-Regel, die die Kommunikation über Port 5022 für das virtuelle Netzwerk ermöglicht, das SQL Managed Instance hostet.

Testen der Verbindung von SQL Managed Instance zu SQL Server

Um zu überprüfen, ob SQL Managed Instance SQL Server erreichen kann, erstellen Sie zuerst einen Testendpunkt. Anschließend verwenden Sie den SQL Server-Agent, um ein PowerShell-Skript mit dem Befehl tnc auszuführen, das den SQL Server über Port 5022 von der verwalteten SQL-Instanz aus pingt.

Zum Erstellen eines Testendpunkts stellen Sie eine Verbindung mit SQL Server her, und führen Sie das folgende T-SQL-Skript aus:

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

Um zu überprüfen, ob der SQL Server Endpunkt Verbindungen an Port 5022 empfängt, führen Sie den folgenden PowerShell-Befehl auf dem Hostbetriebssystem Ihrer SQL Server Instanz aus:

tnc localhost -port 5022

Bei einem erfolgreichen Test wird TcpTestSucceeded : True angezeigt. Anschließend können Sie einen SQL Server-Agent Job in der SQL-verwalteten Instanz erstellen, um den SQL Server Testendpunkt auf Port 5022 aus der SQL-verwalteten Instanz zu testen.

Erstellen Sie als Nächstes einen SQL Server-Agent Auftrag in der sql-verwalteten Instanz namens NetHelper, indem Sie das folgende T-SQL-Skript in der sql-verwalteten Instanz ausführen. Ersetzen Sie Folgendes:

<SQL_SERVER_IP_ADDRESS> mit der IP-Adresse des SQL Servers, auf die von einer verwalteten SQL-Instanz aus zugegriffen werden kann.

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

Tipp

Wenn Sie die IP-Adresse Ihres SQL Server für die Verbindungssonde von der verwalteten SQL-Instanz ändern müssen, löschen Sie den NetHelper-Auftrag, indem Sie EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' ausführen, und erstellen Sie den NetHelper-Auftrag mithilfe des vorherigen Skripts neu.

Erstellen Sie dann eine gespeicherte Prozedur ExecuteNetHelper, mit deren Hilfe Sie den Auftrag ausführen und Ergebnisse vom Netzwerktest erhalten können. Führen Sie das folgende T-SQL-Skript auf der verwalteten SQL-Instanz aus:

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

Führen Sie die folgende Abfrage für die verwaltete SQL-Instanz aus, um die gespeicherte Prozedur auszuführen, die den NetHelper-Agent-Auftrag ausführt, und zeigen Sie das resultierende Protokoll an:

-- Run on managed instance
EXEC ExecuteNetHelper;

Wenn die Verbindung erfolgreich war, wird im Protokoll Trueangezeigt. Wenn die Verbindung nicht erfolgreich war, wird im Protokoll Falseangezeigt.

Screenshot: die erwartete Ausgabe des Auftrags des NetHelper-SQL-Agents

Wenn die Verbindung nicht erfolgreich war, überprüfen Sie die folgenden Elemente:

Die Firewall auf dem Host SQL Server Instanz ermöglicht eingehende und ausgehende Kommunikation an Port 5022.
Eine NSG-Regel für das virtuelle Netzwerk, das SQL Managed Instance hostet, ermöglicht die Kommunikation an Port 5022.
Wenn sich Ihre SQL Server Instanz auf einer Azure VM befindet, ermöglicht eine NSG-Regel die Kommunikation über Port 5022 im virtuellen Netzwerk, in dem der virtuelle Computer gehostet wird.
SQL Server wird ausgeführt.
Es gibt Testendpunkt für SQL Server.

Führen Sie nach dem Beheben von Problemen die NetHelper-Netzwerksonde erneut aus, indem Sie EXEC ExecuteNetHelper auf verwalteter Instanz ausführen.

Nachdem der Netzwerktest erfolgreich war, legen Sie den Testendpunkt und das Zertifikat auf SQL Server mit den folgenden T-SQL-Befehlen ab:

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO