Migrera databaser från SQL Server med hjälp av Log Replay Service – Azure SQL Managed Instance
Gäller för:
Azure SQL Managed Instance
Den här artikeln beskriver hur du migrerar databaser till Azure SQL Managed Instance med hjälp av Log Replay Service (LRS). LRS är en kostnadsfri molntjänst som är tillgänglig för Azure SQL Managed Instance, baserat på SQL Server-loggöverföringsteknik.
Följande källor stöds:
- SQL Server på virtuella datorer
- Amazon EC2 (Elastic Compute Cloud)
- Amazon RDS (Relationsdatabastjänst) för SQL Server
- Google Compute Engine
- Cloud SQL för SQL Server – GCP (Google Cloud Platform)
Förutsättningar
Innan du börjar bör du överväga följande krav för både SQL Server-instansen och Azure.
SQL Server
Kontrollera att du uppfyller följande krav för SQL Server:
- SQL Server-versionerna 2008 till 2022.
- Sql Server-databasen använder den fullständiga återställningsmodellen (obligatorisk).
- En fullständig säkerhetskopia av databaser (en eller flera filer).
- En differentiell säkerhetskopia (en eller flera filer).
- En loggsäkerhetskopia (inte delad för en transaktionsloggfil).
- För SQL Server-versionerna 2008 till 2016 ska du göra en säkerhetskopia lokalt och ladda upp den manuellt till ditt Azure Blob Storage-konto.
- För SQL Server 2016 och senare kan du ta din säkerhetskopia direkt till ditt Azure Blob Storage-konto.
Även om det inte krävs att ha CHECKSUM aktiverat för säkerhetskopieringar rekommenderar vi det starkt för snabbare återställningsåtgärder.
Azure
Kontrollera att du uppfyller följande krav för Azure:
- PowerShell Az.SQL modulversion 4.0.0 eller senare (installeras eller nås via Azure Cloud Shell).
- Azure CLI version 2.42.0 eller senare (installerad).
- En etablerad Azure Blob Storage-container.
- En säkerhetstoken för delad åtkomst (SAS) med läs- och listbehörigheter som genererats för Blob Storage-containern eller en hanterad identitet som kan komma åt containern.
- Placera säkerhetskopieringsfiler för en enskild databas i en separat mapp i ett lagringskonto med hjälp av en flatfilstruktur (obligatorisk). Kapsling av mappar i databasmappar stöds inte.
Azure RBAC-behörigheter
För att köra LRS via de angivna klienterna krävs någon av följande rollbaserade RBAC-roller (Rollbaserad åtkomstkontroll i Azure):
- Rollen SQL Managed Instance-deltagare
- En roll med följande behörighet:
Microsoft.Sql/managedInstances/databases/*
Bästa praxis
När du använder LRS bör du överväga följande metodtips:
- Kör Data Migration Assistant för att verifiera att dina databaser är redo att migreras till SQL Managed Instance.
- Dela upp fullständiga och differentiella säkerhetskopior i flera filer i stället för att använda en enda fil.
- Förbättra nätverkets överföringshastigheter genom att aktivera komprimering av säkerhetskopiering.
- Använd Cloud Shell för att köra PowerShell- eller CLI-skript, eftersom det alltid uppdateras för att använda de senaste cmdletarna.
- Konfigurera ett underhållsperiod för att tillåta schemaläggning av systemuppdateringar vid en viss dag och tidpunkt. Den här konfigurationen hjälper till att uppnå en mer förutsägbar tid för databasmigreringar, eftersom systemuppgraderingar kan avbryta pågående migreringar.
- Planera att slutföra ett enda LRS-migreringsjobb inom högst 30 dagar. När den här tidsramen upphör avbryts LRS-jobbet automatiskt.
- För en snabbare databasåterställning aktiverar
CHECKSUMdu när du tar dina säkerhetskopior. SQL Managed Instance utför en integritetskontroll av säkerhetskopior utanCHECKSUM, vilket ökar återställningstiden.
Systemuppdateringar för SQL Managed Instance har företräde framför pågående databasmigreringar. Under en systemuppdatering på en instans pausas alla väntande LRS-migreringar och återupptas först efter att uppdateringen har tillämpats. Det här systembeteendet kan förlänga migreringstiden, särskilt för stora databaser.
Om du vill uppnå en förutsägbar tid för databasmigreringar kan du överväga att konfigurera ett underhållsperiod för att schemalägga systemuppdateringar för en viss dag och tid och köra och slutföra migreringsjobb utanför den avsedda underhållsperiodens tidsram.
Viktigt!
- Du kan inte använda databaser som återställs via LRS förrän migreringsprocessen är klar.
- LRS stöder inte skrivskyddad åtkomst till databaser under migreringen.
- När migreringen är klar är migreringsprocessen slutgiltig och kan inte återupptas med ytterligare differentiella säkerhetskopior.
Migrera flera databaser
Om du migrerar flera databaser med hjälp av samma Azure Blob Storage-container måste du placera säkerhetskopieringsfiler för olika databaser i separata mappar i containern. Alla säkerhetskopierade filer för en enskild databas måste placeras i en flatfilstruktur i en databasmapp och mapparna kan inte kapslas. Kapsling av mappar i databasmappar stöds inte.
Här är ett exempel på en mappstruktur i en Azure Blob Storage-container, en struktur som krävs för att migrera flera databaser med hjälp av LRS.
-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>
-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>
-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>
Skapa ett lagringskonto
Du använder ett Azure Blob Storage-konto som mellanlagring för säkerhetskopieringsfiler mellan din SQL Server-instans och din SQL Managed Instance-distribution. Så här skapar du ett nytt lagringskonto och en blobcontainer i lagringskontot:
- Skapa ett lagringskonto.
- Skapa en blobcontainer i lagringskontot.
Konfigurera Azure Storage bakom en brandvägg
Användning av Azure Blob Storage som skyddas bakom en brandvägg stöds, men kräver ytterligare konfiguration. Om du vill aktivera läs-/skrivåtkomst till Azure Storage med Azure Firewall aktiverat måste du lägga till undernätet för den SQL-hanterade instansen i brandväggsreglerna för det virtuella nätverket för lagringskontot med hjälp av MI-undernätsdelegering och lagringstjänstens slutpunkt. Lagringskontot och den hanterade instansen måste finnas i samma region eller i två parkopplade regioner.
Om azure-lagringen finns bakom en brandvägg kan du se följande meddelande i felloggen för SQL-hanterad instans:
Audit: Storage access denied user fault. Creating an email notification:
Detta genererar ett e-postmeddelande som meddelar dig att granskning för den SQL-hanterade instansen inte kan skriva granskningsloggar till lagringskontot. Om du ser det här felet eller får det här e-postmeddelandet följer du stegen i det här avsnittet för att konfigurera brandväggen.
Följ dessa steg för att konfigurera brandväggen:
Gå till din hanterade instans i Azure-portalen och välj undernätet för att öppna sidan Undernät .
På sidan Undernät väljer du namnet på undernätet för att öppna konfigurationssidan för undernätet.
Under Delegering av undernät väljer du Microsoft.Sql/managedInstances från listrutan Delegera undernät till en tjänst . Vänta ungefär en timme på att behörigheterna ska spridas och välj sedan Microsoft.Storage i listrutan Tjänster under Tjänstslutpunkter.
Gå sedan till ditt lagringskonto i Azure-portalen, välj Nätverk under Säkerhet + nätverk och välj sedan fliken Brandväggar och virtuella nätverk .
På fliken Brandväggar och virtuella nätverk för ditt lagringskonto väljer du +Lägg till befintligt virtuellt nätverk för att öppna sidan Lägg till nätverk .
Välj lämplig prenumeration, virtuellt nätverk och hanterat instansundernät i listrutorna och välj sedan Lägg till för att lägga till det virtuella nätverket för den SQL-hanterade instansen till lagringskontot.
Autentisera till ditt Blob Storage-konto
Använd antingen en SAS-token eller en hanterad identitet för att komma åt ditt Azure Blob Storage-konto.
Varning
Du kan inte använda både en SAS-token och en hanterad identitet parallellt på samma lagringskonto. Du kan använda antingen en SAS-token eller en hanterad identitet, men inte båda.
Generera en SAS-autentiseringstoken för Blob Storage för LRS
Få åtkomst till ditt Azure Blob Storage-konto med hjälp av en SAS-token.
Du kan använda ett Azure Blob Storage-konto som mellanlagring för säkerhetskopieringsfiler mellan din SQL Server-instans och din SQL Managed Instance-distribution. Generera en SAS-autentiseringstoken för LRS med endast läs- och listbehörigheter. Token gör det möjligt för LRS att komma åt ditt Blob Storage-konto och använder säkerhetskopieringsfilerna för att återställa dem till din hanterade instans.
Följ dessa steg för att generera token:
Öppna Storage Explorer i Azure-portalen.
Expandera Blobcontainrar.
Högerklicka på blobcontainern och välj sedan Hämta signatur för delad åtkomst.
Välj tidsramen för förfallodatum för token. Kontrollera att token är giltig under migreringen.
Välj tidszonen för token: UTC eller din lokala tid.
Viktigt!
Tidszonen för token och den hanterade instansen kan vara matchningsfel. Se till att SAS-token har rätt tids giltighet, med hänsyn till tidszoner. Om du vill ta hänsyn till tidszonsskillnader anger du värdet för giltigheten FROM långt innan migreringsfönstret startar och TO-värdet långt efter att du förväntar dig att migreringen ska slutföras.
Välj endast läs - och listbehörigheter .
Viktigt!
Välj inte några andra behörigheter. Om du gör det kommer inte LRS att starta. Detta säkerhetskrav är avsiktligt.
Välj Skapa.
SAS-autentiseringen genereras med den tids giltighet som du angav. Du behöver URI-versionen av token, enligt följande skärmbild:
Kommentar
Användning av SAS-token som skapats med behörigheter som har angetts genom att definiera en lagrad åtkomstprincip stöds inte just nu. Följ anvisningarna i den här proceduren för att manuellt ange läs - och listbehörigheter för SAS-token.
Kopiera parametrar från SAS-token
Få åtkomst till ditt Azure Blob Storage-konto med hjälp av antingen en SAS-token eller en hanterad identitet.
Innan du använder SAS-token för att starta LRS måste du förstå dess struktur. URI:n för den genererade SAS-token består av två delar, avgränsade med ett frågetecken (?), som visas i det här exemplet:
Den första delen, som börjar med https:// tills frågetecknet (?), används för parametern StorageContainerURI som matas som indata till LRS. Den ger LRS-information om mappen där databassäkerhetskopiorna lagras.
Den andra delen, från efter frågetecknet (?) till slutet av strängen, är parametern StorageContainerSasToken . Den här delen är den faktiska signerade autentiseringstoken, som är giltig under den angivna tiden. Den här delen behöver inte nödvändigtvis börja med sp= , som du ser i exemplet. Ditt scenario kan skilja sig åt.
Kopiera parametrarna på följande sätt:
Kopiera den första delen av token, från
https://upp till men inte med frågetecknet (?). Använd den somStorageContainerUriparameter i PowerShell eller Azure CLI när du startar LRS.
Kopiera den andra delen av token från efter frågetecknet (
?) till slutet av strängen. Använd den somStorageContainerSasTokenparameter i PowerShell eller Azure CLI när du startar LRS.
Kommentar
Ta inte med frågetecknet (?) när du kopierar någon av delarna av token.
Verifiera lagringsåtkomsten för den hanterade instansen
Kontrollera att din hanterade instans kan komma åt ditt Blob Storage-konto.
Ladda först upp en databassäkerhetskopia, till exempel full_0_0.bak, till din Azure Blob Storage-container.
Anslut sedan till den hanterade instansen och kör en exempeltestfråga för att avgöra om den hanterade instansen kan komma åt säkerhetskopian i containern.
Om du använder en SAS-token för att autentisera <sastoken> till ditt lagringskonto ersätter du med din SAS-token och kör följande fråga på din instans:
CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = '<sastoken>'
RESTORE HEADERONLY
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak'
Ladda upp säkerhetskopior till ditt Blob Storage-konto
När din blobcontainer är klar och du har bekräftat att den hanterade instansen kan komma åt containern kan du börja ladda upp dina säkerhetskopior till ditt Blob Storage-konto. Du kan antingen:
- Kopiera dina säkerhetskopior till ditt Blob Storage-konto.
- Ta säkerhetskopior från SQL Server direkt till ditt Blob Storage-konto med hjälp av kommandot BACKUP TO URL om din miljö tillåter det (från och med SQL Server-versionerna 2012 SP1 CU2 och SQL Server 2014).
Kopiera befintliga säkerhetskopior till ditt Blob Storage-konto
Om du har en tidigare version av SQL Server, eller om din miljö inte stöder säkerhetskopiering direkt till en URL, tar du dina säkerhetskopior på SQL Server-instansen som vanligt och kopierar dem sedan till ditt Blob Storage-konto.
Gör säkerhetskopior på en SQL Server-instans
Ange databaser som du vill migrera till den fullständiga återställningsmodellen för att tillåta loggsäkerhetskopior.
-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO
Använd följande exempel på T-SQL-skript för att manuellt göra fullständiga, differentiella och loggsäkerhetskopior av databasen till lokal lagring. CHECKSUM krävs inte, men vi rekommenderar det.
Följande exempel tar en fullständig databassäkerhetskopia till den lokala disken:
-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
I följande exempel görs en differentiell säkerhetskopiering till den lokala disken:
-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
Följande exempel tar en säkerhetskopiering av transaktionsloggen till den lokala disken:
-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO
Kopiera säkerhetskopior till ditt Blob Storage-konto
När dina säkerhetskopior är klara och du vill börja migrera databaser till en hanterad instans med hjälp av LRS kan du använda följande metoder för att kopiera befintliga säkerhetskopior till ditt Blob Storage-konto:
- Ladda ned och installera AzCopy.
- Ladda ned och installera Azure Storage Explorer.
- Använd Storage Explorer i Azure-portalen.
Kommentar
Om du vill migrera flera databaser med hjälp av samma Azure Blob Storage-container placerar du alla säkerhetskopierade filer för en enskild databas i en separat mapp i containern. Använd flatfilstruktur för varje databasmapp. Kapsling av mappar i databasmappar stöds inte.
Ta säkerhetskopior direkt till ditt Blob Storage-konto
Om du har en version av SQL Server som stöds (från och med SQL Server 2012 SP1 CU2 och SQL Server 2014), och dina företags- och nätverksprinciper tillåter det, kan du ta säkerhetskopior från SQL Server direkt till ditt Blob Storage-konto med hjälp av det interna alternativet FÖR SÄKERHETSKOPIERing till URL för SQL Server. Om du kan använda BACKUP TO URLbehöver du inte ta säkerhetskopior till lokal lagring och ladda upp dem till ditt Blob Storage-konto.
När du tar interna säkerhetskopior direkt till ditt Blob Storage-konto måste du autentisera till lagringskontot.
Använd följande kommando för att skapa en autentiseringsuppgift som importerar SAS-token till din SQL Server-instans:
CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = '<SAS_TOKEN>';
Detaljerade anvisningar om hur du arbetar med SAS-token finns i självstudien Använda Azure Blob Storage med SQL Server.
När du har skapat autentiseringsuppgifterna för att autentisera SQL Server-instansen med Blob Storage kan du använda kommandot BACKUP TO URL för att ta säkerhetskopior direkt till lagringskontot. CHECKSUM rekommenderas, men krävs inte.
Följande exempel tar en fullständig databassäkerhetskopia till en URL:
-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
I följande exempel görs en differentiell databassäkerhetskopia till en URL:
-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
Följande exempel tar en säkerhetskopia av transaktionsloggen till en URL:
-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
Logga in på Azure och välj en prenumeration
Använd följande PowerShell-cmdlet för att logga in på Azure:
Login-AzAccount
Välj den prenumeration där din hanterade instans finns med hjälp av följande PowerShell-cmdlet:
Select-AzSubscription -SubscriptionId <subscription ID>
Starta migreringen
Starta migreringen genom att starta LRS. Du kan starta tjänsten i antingen automatiskt kompletteringsläge eller kontinuerligt läge.
När du använder automatiskt kompletteringsläge slutförs migreringen automatiskt när den sista av de angivna säkerhetskopieringsfilerna har återställts. Det här alternativet kräver att hela säkerhetskopieringskedjan är tillgänglig i förväg och laddas upp till ditt Blob Storage-konto. Det tillåter inte att nya säkerhetskopieringsfiler läggs till medan migreringen pågår. Det här alternativet kräver kommandot start för att ange filnamnet för den senaste säkerhetskopieringsfilen. Vi rekommenderar det här läget för passiva arbetsbelastningar som inte behöver komma ifatt data.
När du använder kontinuerligt läge söker tjänsten kontinuerligt igenom Azure Blob Storage-mappen och återställer alla nya säkerhetskopieringsfiler som läggs till under migreringen. Migreringen slutförs först efter att den manuella snabbåtgärden har begärts. Du måste använda migrering i kontinuerligt läge när du inte har hela säkerhetskopieringskedjan i förväg och när du planerar att lägga till nya säkerhetskopieringsfiler när migreringen pågår. Vi rekommenderar det här läget för aktiva arbetsbelastningar för vilka datahämtning krävs.
Planera att slutföra ett enda LRS-migreringsjobb inom högst 30 dagar. När den här tiden går ut avbryts LRS-jobbet automatiskt.
Kommentar
När du migrerar flera databaser måste LRS startas separat för varje databas och peka på den fullständiga URI-sökvägen för Azure Blob Storage-containern och den enskilda databasmappen.
Starta LRS i automatiskt kompletteringsläge
Kontrollera att hela säkerhetskopieringskedjan har laddats upp till ditt Azure Blob Storage-konto. Det här alternativet tillåter inte att nya säkerhetskopieringsfiler läggs till medan migreringen pågår.
Om du vill starta LRS i automatiskt kompletteringsläge använder du PowerShell- eller Azure CLI-kommandon. Ange namnet på den senaste säkerhetskopieringsfilen med hjälp av parametern -LastBackupName . När återställningen av den senast angivna säkerhetskopieringsfilen har slutförts initierar tjänsten automatiskt en snabb återställning.
Återställ databasen från lagringskontot med hjälp av antingen SAS-token eller en hanterad identitet.
Viktigt!
- Kontrollera att hela säkerhetskopieringskedjan har laddats upp till ditt Azure Blob Storage-konto innan du påbörjar migreringen i automatiskt kompletteringsläge. Det här läget tillåter inte att nya säkerhetskopieringsfiler läggs till medan migreringen pågår.
- Kontrollera att du har angett den senaste säkerhetskopieringsfilen korrekt och att du inte har laddat upp fler filer efter den. Om systemet identifierar fler säkerhetskopierade filer utöver den senaste angivna säkerhetskopieringsfilen misslyckas migreringen.
I följande PowerShell-exempel startas LRS i automatiskt kompletteringsläge med hjälp av en SAS-token:
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" `
-StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
-AutoCompleteRestore `
-LastBackupName "last_backup.bak"
Följande Azure CLI-exempel startar LRS i automatiskt kompletteringsläge med hjälp av en SAS-token:
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
Starta LRS i kontinuerligt läge
Se till att du har laddat upp din första säkerhetskopieringskedja till ditt Azure Blob Storage-konto.
Viktigt!
När du har startat LRS i kontinuerligt läge kan du lägga till nya logg- och differentiella säkerhetskopior till ditt lagringskonto fram till den manuella snabbningen. När den manuella snabbväxlingen har initierats kan inga ytterligare differentiella filer läggas till eller återställas.
Följande PowerShell-exempel startar LRS i kontinuerligt läge med hjälp av en SAS-token:
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
Följande Azure CLI-exempel startar LRS i kontinuerligt läge:
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
Skripta migreringsjobbet
PowerShell- och Azure CLI-klienter som startar LRS i kontinuerligt läge är synkrona. I det här läget väntar PowerShell och Azure CLI på att API-svaret ska rapportera om lyckade eller misslyckade åtgärder innan de startar jobbet.
Under den här väntan returnerar kommandot inte kontrollen till kommandotolken. Om du skriptar migreringsmiljön och du behöver LRS-startkommandot för att ge tillbaka kontrollen omedelbart för att fortsätta med resten av skriptet kan du köra PowerShell som ett bakgrundsjobb med växeln -AsJob . Till exempel:
$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob
När du startar ett bakgrundsjobb returneras ett jobbobjekt omedelbart, även om jobbet tar längre tid att slutföra. Du kan fortsätta att arbeta i sessionen utan avbrott medan jobbet körs. Mer information om hur du kör PowerShell som ett bakgrundsjobb finns i PowerShell Start-Job-dokumentationen.
Om du vill starta ett Azure CLI-kommando i Linux som en bakgrundsprocess använder du et-et (&) i slutet av LRS-startkommandot:
az sql midb log-replay start <required parameters> &
Övervaka migreringsstatus
Az.SQL 4.0.0 och senare innehåller en detaljerad förloppsrapport. Granska återställningsinformation för hanterad databas – Hämta för ett exempelutdata.
Om du vill övervaka migreringsstatus via PowerShell använder du följande kommando:
Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Om du vill övervaka migreringsstatusen via Azure CLI använder du följande kommando:
az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb
Stoppa migreringen (valfritt)
Om du behöver stoppa migreringen använder du PowerShell eller Azure CLI. Om du stoppar migreringen tas återställningsdatabasen bort på den hanterade instansen, så det går inte att återuppta migreringen.
Om du vill stoppa migreringsprocessen via PowerShell använder du följande kommando:
Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Om du vill stoppa migreringsprocessen via Azure CLI använder du följande kommando:
az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb
Slutför migreringen (kontinuerligt läge)
Om du startar LRS i kontinuerligt läge kontrollerar du att programmet och SQL Server-arbetsbelastningen har stoppats för att förhindra att nya säkerhetskopieringsfiler genereras. Kontrollera att den senaste säkerhetskopieringen från SQL Server-instansen har laddats upp till ditt Azure Blob Storage-konto. Övervaka återställningsförloppet för den hanterade instansen och se till att den senaste säkerhetskopieringen av loggen har återställts.
När den senaste säkerhetskopieringen av loggen har återställts på den hanterade instansen initierar du den manuella snabbningen för att slutföra migreringen. När snabbåtgärden är klar blir databasen tillgänglig för läs- och skrivåtkomst på den hanterade instansen.
Om du vill slutföra migreringsprocessen i kontinuerligt LRS-läge via PowerShell använder du följande kommando:
Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"
Om du vill slutföra migreringsprocessen i kontinuerligt LRS-läge via Azure CLI använder du följande kommando:
az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"
Felsöka LRS-problem
När du har startat LRS använder du någon av följande övervaknings-cmdletar för att se status för åtgärden:
- För PowerShell:
get-azsqlinstancedatabaselogreplay - För Azure CLI:
az_sql_midb_log_replay_show
Om LRS inte kan starta efter en tid och du får ett fel kontrollerar du de vanligaste problemen:
- Har en befintlig databas på den hanterade instansen samma namn som den som du försöker migrera från SQL Server-instansen? Lös den här konflikten genom att byta namn på en av databaserna.
- Beviljas behörigheterna för SAS-token skrivskyddad och lista?
- Kopierade du SAS-token för LRS efter frågetecknet (
?), med innehåll som ser ut somsv=2020-02-10...? - Är SAS-tokens giltighetstid lämplig för tidsfönstret för att starta och slutföra migreringen? Det kan finnas felmatchningar på grund av de olika tidszoner som används för din SQL Managed Instance-distribution och SAS-token. Prova att återskapa SAS-token och utöka tokens giltighet för tidsfönstret före och efter det aktuella datumet.
- När du startar flera Log Replay-återställningar parallellt med samma lagringscontainer kontrollerar du att samma giltiga SAS-token tillhandahålls för varje återställningsåtgärd.
- Stavas databasnamnet, resursgruppens namn och namnet på den hanterade instansen korrekt?
- Om du startade LRS i automatiskt kompletteringsläge, var ett giltigt filnamn för den senaste säkerhetskopieringsfilen angiven?
- Innehåller säkerhetskopierings-URI-sökvägen nyckelord
backupellerbackups? Byt namn på containern eller mapparna som använderbackupellerbackupseftersom dessa är reserverade nyckelord.
Nästa steg
- Läs mer om att migrera till Azure SQL Managed Instance med hjälp av länkfunktionen.
- Läs mer om att migrera från SQL Server till Azure SQL Managed Instance.
- Läs mer om skillnaderna mellan SQL Server och SQL Managed Instance.
- Läs mer om metodtips för kostnads- och storleksarbetsbelastningar som migrerats till Azure.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för