Dela via

Migrera databaser från SQL Server med hjälp av Log Replay Service – Azure SQL Managed Instance

  • Artikel

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):

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 CHECKSUM du när du tar dina säkerhetskopior. SQL Managed Instance utför en integritetskontroll av säkerhetskopior utan CHECKSUM, 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:

  1. Skapa ett lagringskonto.
  2. 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:

  1. Gå till din hanterade instans i Azure-portalen och välj undernätet för att öppna sidan Undernät .

    Screenshot of the SQL managed instance Overview page of the Azure portal, with the subnet selected.

  2. På sidan Undernät väljer du namnet på undernätet för att öppna konfigurationssidan för undernätet.

    Screenshot of the SQL managed instance Subnet page of the Azure portal, with the subnet selected.

  3. 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.

    Screenshot of the SQL managed instance Subnet configuration page of the Azure portal.

  4. 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 .

  5. 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 .

    Screenshot of the Storage Account Networking page of the Azure portal, with Add existing virtual network selected.

  6. 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:

  1. Öppna Storage Explorer i Azure-portalen.

  2. Expandera Blobcontainrar.

  3. Högerklicka på blobcontainern och välj sedan Hämta signatur för delad åtkomst.

    Screenshot that shows selections for generating a SAS authentication token.

  4. Välj tidsramen för förfallodatum för token. Kontrollera att token är giltig under migreringen.

  5. 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.

  6. 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.

  7. Välj Skapa.

    Screenshot that shows selections for SAS token expiration, time zone, and permissions, along with the Create button.

SAS-autentiseringen genereras med den tids giltighet som du angav. Du behöver URI-versionen av token, enligt följande skärmbild:

Screenshot that shows an example of the URI version of a SAS token.

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:

Example URI for a generated SAS token for Log Replay Service.

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:

  1. Kopiera den första delen av token, från https:// upp till men inte med frågetecknet (?). Använd den som StorageContainerUri parameter i PowerShell eller Azure CLI när du startar LRS.

    Screenshot that shows where to copy the first part of the token.

  2. Kopiera den andra delen av token från efter frågetecknet (?) till slutet av strängen. Använd den som StorageContainerSasToken parameter i PowerShell eller Azure CLI när du startar LRS.

    Screenshot that shows where to copy the second part of the token.

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:

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 som sv=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 backup eller backups? Byt namn på containern eller mapparna som använder backup eller backups eftersom dessa är reserverade nyckelord.

Nästa steg