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

Viktig

• Innan du migrerar databaser till tjänstnivån Affärskritisk bör du överväga dessa begränsningar, som inte gäller för tjänstnivån Allmänt syfte.
• 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.

Innan du börjar bör du överväga kraven i det här avsnittet för både SQL Server-instansen och Azure. Granska noggrant avsnitten om begränsningar och bästa metoder för att säkerställa en lyckad migrering.

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 CHECKSUM aktiverat för säkerhetskopieringar rekommenderar vi starkt att du förhindrar oavsiktlig migrering av en skadad databas och för snabbare återställningsåtgärder.

Blått

Kontrollera att du uppfyller följande krav för Azure:

• PowerShell Az.SQL modulversion 4.0.0 eller senare (installerad eller nås via Azure Cloud Shell).
• Azure CLI version 2.42.0 eller senare (installerad).
• En tillhandahållen Azure Blob Storage-container.
• En säkerhetstoken för delad åtkomst (SAS) med Read och List behörigheter som genererats för Blob Storage-containern eller en hanterad identitet som kan komma åt containern. Om du beviljar fler behörigheter än Read och List misslyckas LRS.
• 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):

• SQL Managed Instance-deltagare roll
• En roll med följande behörighet: Microsoft.Sql/managedInstances/databases/*

Metodtips

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.
• Aktivera säkerhetskopieringskomprimering för att hjälpa nätverksöverföringshastigheten.
• 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 en underhållsperiod så att systemuppdateringar schemaläggs en viss dag och tid utanför migreringsfönstret för att förhindra fördröjning eller avbrott i migreringen.
• 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 att förhindra oavsiktlig migrering av en skadad databas och för en snabbare databasåterställning aktiverar du CHECKSUM när du tar dina säkerhetskopior. Även om SQL Managed Instance utför en grundläggande integritetskontroll av säkerhetskopior utan CHECKSUM, är det inte säkert att alla former av skada fångas. Säkerhetskopieringar med CHECKSUM är det enda sättet att se till att säkerhetskopieringen som återställs till SQL Managed Instance inte är skadad. Den grundläggande integritetskontrollen av säkerhetskopior utan CHECKSUM ökar återställningstiden för en databas.
• När du migrerar till tjänstnivån Affärskritisk bör du räkna med en långvarig fördröjning i databastillgängligheten efter övergång, medan databaser seedas till sekundära repliker. För särskilt stora databaser med minimala driftavbrottskrav kan du först migrera till tjänstnivån Generell användning och sedan uppgradera till tjänstnivån Affärskritisk eller använda länken Hanterad instans för att migrera dina data.
• Att ladda upp tusentals databasfiler för återställning kan leda till långa migreringstider och till och med fel. Konsolidera databaser till färre filer för att påskynda migreringsprocessen och se till att den lyckas.
• För att minimera övergångstiden och minska risken för fel, se till att den senaste säkerhetskopieringen är så liten som möjligt.

Konfigurera ett underhållsfönster

Systemuppdateringar för SQL Managed Instance har företräde framför pågående databasmigreringar.

Migreringen påverkas på olika sätt baserat på tjänstnivån:

• På tjänstnivån Generell användning 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.
• På tjänstnivån Affärskritisk avbryts alla väntande LRS-migreringar och startas om automatiskt när uppdateringen har tillämpats. Det här systembeteendet kan förlänga migreringstiden, särskilt för stora databaser.

För att uppnå en förutsägbar tid för databasmigreringar bör du överväga att konfigurera en underhållsfönster för att schemalägga systemuppdateringar för en viss dag och tid och köra och slutföra migreringsjobb utanför den avsedda tidsramen för underhållsperioden. För en migrering som startar på måndag konfigurerar du till exempel fönstret för anpassat underhåll på söndag så att det tar mest tid att slutföra migreringen.

Det krävs inte att du konfigurerar en underhållsperiod, men rekommenderas starkt för stora databaser.

Obs

Ett underhållsfönster styr förutsägbarheten för planerade uppdateringar, men det garanterar inte att oplanerade felövergångar eller säkerhetsuppdateringar inte sker. En oplanerad redundansväxling eller en säkerhetskorrigering (som har företräde framför alla andra uppdateringar) kan fortfarande avbryta migreringen.

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 Storage finns bakom en brandvägg kan följande meddelande visas 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.

   

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

   

3. Under undernätsdelegeringvä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 från listrutan för tjänster under Tjänstslutpunkter.

   

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.

   

6. Välj lämplig prenumeration, virtuellt nätverk och hanterat instansundernät från de nedrullningsbara menyerna 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.

SAS-token

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 Exploreri Azure-portalen.

2. Expandera blob-containrar.

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

   

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.

   Viktig

   Tidszonen för token och din hanterade instans kanske inte matchar. 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 giltigheten FROM--värdet långt innan migreringsfönstret startar, och TO värde långt efter att du förväntar dig att migreringen ska slutföras.

6. Välj endast Läsa och Lista behörigheter.

   Viktig

   Välj inte andra behörigheter. Om du gör det startar inte LRS. Det här säkerhetskravet är avsiktligt.

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

Obs

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 behörigheter: Läs och Lista 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 den StorageContainerURI parameter 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:// fram till men inte inklusive frågetecknet (?). Använd den som StorageContainerUri parameter i PowerShell eller Azure CLI när du startar LRS.

   

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.

   

Obs

Ta inte med frågetecknet (?) när du kopierar någon del av token.

hanterad identitet

Om du vill använda en hanterad identitet tilldelar du antingen en systemhanterad eller användarhanterad identitet för att få åtkomst till Azure Blob Storage-containern.

Gör det genom att följa dessa steg:

1. I Azure-portalengår du till det Blob Storage-konto som du tänker auktorisera åtkomst till hanterad instans till.
2. Välj åtkomstkontroll (IAM).
3. Välj Lägg tilloch välj sedan Lägg till rolltilldelning.
4. Sök efter och välj den befintliga rollen Storage Blob Data Reader. Anpassade roller stöds så länge de åtminstone har läs- och listbehörigheter.
5. Välj hanterad identitet.
6. Använd alternativet Välj medlemmar för att identifiera din prenumeration.
7. I listrutan Hanterad identitet väljer du SQL Managed Instanceoch väljer sedan den hanterade instans som du tänker migrera till.
8. Välj Välj för att spara inställningarna och auktorisera åtkomst.
9. Slutför processen genom att välja Granska + tilldela.

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.

SAS-token

Om du använder en SAS-token för att autentisera till ditt lagringskonto ersätter du <sastoken> 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' 

hanterad identitet

Om du använder en hanterad identitet för att autentisera till ditt lagringskonto uppdaterar du CREATE CREDENTIAL med lagringskontots URL och kör följande exempelfråga på din instans:

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'MANAGED IDENTITY' 

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 att du förhindrar migrering av en skadad databas och för snabbare återställningstider.

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.

Obs

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 SQL Server BACKUP TO URL. 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 gör en fullständig databasbackup 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

Exemplet nedan visar hur en differentialsäkerhetskopiering av en databas görs 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 autokompletteringslä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 arbetslaster där uppdatering av data inte är nödvändigt.

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 övergången 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.

Obs

När du migrerar flera databaser måste varje databas finnas i en egen mapp. LRS måste 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. Kapslade mappar i databasmappar stöds inte.

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 systemövergång.

Återställ databasen från lagringskontot med hjälp av antingen SAS-token eller en hanterad identitet.

Viktig

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

SAS-token

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"

hanterad identitet

I följande PowerShell-exempel startas LRS i automatiskt kompletteringsläge med hjälp av en hanterad identitet:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Starta LRS i kontinuerligt läge

Se till att du har laddat upp din första säkerhetskopieringskedja till ditt Azure Blob Storage-konto.

Viktig

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 övergången. När den manuella övergången har initierats kan inga ytterligare differentiella filer läggas till eller återställas.

SAS-token

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"

hanterad identitet

I följande PowerShell-exempel startas LRS i kontinuerligt läge med hjälp av en hanterad identitet:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

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 -AsJob växeln. 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 dokumentationen PowerShell Start-Job.

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 information om återställning av hanterad databas – Hämta för ett exempel på utdata.

Om du vill övervaka pågående migreringsframstatus via PowerShell använder du följande kommando:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Om du vill övervaka pågående migreringsframstatus via Azure CLI använder du följande kommando:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Om du vill spåra ytterligare information om en misslyckad begäran använder du PowerShell-kommandot Get-AzSqlInstanceOperation eller använder Azure CLI-kommandot az sql mi op show.

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 loggens säkerhetskopiering har återställts på din hanterade instans, inleder du den manuella övergången för att slutföra migreringen. Efter att övergången ä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"

Begränsningar

Tänk på följande begränsningar när du migrerar med LRS:

• Du kan inte använda databaser som återställs via LRS förrän migreringsprocessen är klar.
• Under migreringsprocessen kan databaser som migreras inte användas för skrivskyddad åtkomst på SQL Managed Instance.
• När migreringen är klar är migreringsprocessen slutgiltig och kan inte återupptas med ytterligare differentiella säkerhetskopior.
• Endast databas .bak, .logoch .diff filer stöds av LRS. Dacpac- och bacpac-filer stöds inte.
• Du måste konfigurera en underhållsperiod för att schemalägga systemuppdateringar vid en viss dag och tidpunkt. Planera att köra och slutföra migreringar utanför det schemalagda underhållsfönstret.
• Databassäkerhetskopior som görs utan CHECKSUM:
  • kan möjligen migrera skadade databaser.
  • tar längre tid att återställa än databassäkerhetskopior med CHECKSUM aktiverat.
• Den SAS-token (signatur för delad åtkomst) som LRS använder måste genereras för hela Azure Blob Storage-containern och måste endast ha Read och List behörigheter. Om du till exempel beviljar Read, Listoch Write behörigheter kan LRS inte starta på grund av den extra Write behörigheten.
• Användning av SAS-token som skapats med behörigheter som anges genom att definiera en lagrad åtkomstprincip stöds inte. Följ anvisningarna i den här artikeln om du vill ange läs- och listbehörigheter manuellt för SAS-token.
• Du måste placera säkerhetskopieringsfiler för olika databaser i separata mappar på Blob Storage-kontot i en platt filstruktur. Kapsling av mappar i databasmappar stöds inte.
• Om du använder automatiskt kompletteringsläge måste hela säkerhetskopieringskedjan vara tillgänglig i förväg på Blob Storage-kontot. Det går inte att lägga till nya säkerhetskopieringsfiler i automatiskt kompletteringsläge. Använd kontinuerligt läge om du behöver lägga till nya säkerhetskopierade filer medan migreringen pågår.
• Du måste starta LRS separat för varje databas som pekar på den fullständiga URI-sökvägen som innehåller en enskild databasmapp.
• Säkerhetskopieringens URI-sökväg, containernamn eller mappnamn får inte innehålla backup eller backups eftersom dessa är reserverade nyckelord.
• När du startar flera Log Replay-återställningar parallellt, med samma lagringscontainer som mål, kontrollerar du att samma giltiga SAS-token tillhandahålls för varje återställningsåtgärd.
• LRS kan stödja upp till 100 samtidiga återställningsprocesser per enskild hanterad instans.
• Ett enda LRS-jobb kan köras i högst 30 dagar, varefter det avbryts automatiskt.
• Även om det är möjligt att använda ett Azure Storage-konto bakom en brandvägg krävs extra konfiguration, och lagringskontot och den hanterade instansen måste antingen finnas i samma region eller i två parkopplade regioner. Granska konfigurera brandvägg för att lära dig mer.
• Det maximala antalet databaser som du kan återställa parallellt är 200 per enskild prenumeration. I vissa fall är det möjligt att öka den här gränsen genom att skapa ett supportärende.
• Att ladda upp tusentals databasfiler för återställning kan leda till långa migreringstider och till och med fel. Konsolidera databaser till färre filer för att påskynda migreringsprocessen och se till att den lyckas.
• Det finns två scenarier, i början och slutet av migreringsprocessen, där en migrering avbryts om en failover inträffar, och migreringsjobbet måste startas om manuellt från början då databasen droppas från SQL Managed Instance.
  • Om en redundansväxling inträffar när den första fullständiga databassäkerhetskopian håller på att återställas till SQL Managed Instance och migreringsjobbet just har startats, måste migreringsjobbet manuellt startas om från början.
  • Om en failover inträffar efter att migrationsövergången har initierats måste migreringsjobbet startas om manuellt från början. Se till att den senaste säkerhetskopieringsfilen är så liten som möjligt för att minimera omställningstid och minska risken för felläge under omställningsprocessen.

Obs

Om du behöver att en databas ska vara skrivskyddad under migreringen, med en mycket längre tidsram för att genomföra migreringen och med minimal stilleståndstid, bör du överväga att använda funktionen för hanterad instans länk som en rekommenderad migreringslösning.

Begränsningar vid migrering till tjänstnivån Affärskritisk

När du migrerar till en SQL Managed Instance på tjänstnivån Affärskritisk bör du överväga följande begränsningar:

• När man migrerar stora databaser kan det uppstå betydande driftstopp eftersom databaserna är otillgängliga efter omkoppling medan de dirigeras till sekundära repliker av tjänstnivån Affärskritisk. Lösningar visas i avsnittet längre övergång.
• Migreringen startas om automatiskt från början om migreringen avbryts av en oplanerad redundansväxling, systemuppdatering eller säkerhetskorrigering, vilket gör det svårt att planera en förutsägbar migrering utan överraskningar i sista minuten.

Viktig

Dessa begränsningar gäller endast vid migrering till tjänstnivån Affärskritisk och inte till tjänstnivån Generell användning.

Längre övergång på tjänstnivån Affärskritisk

Om du migrerar till en SQL-hanterad instans på tjänstnivån Affärskritisk, bör du beakta fördröjningen i processen att göra databaserna tillgängliga online på den primära repliken under tiden de synkroniseras till de sekundära replikerna. Detta gäller särskilt för större databaser.

Det tar längre tid att migrera till en SQL-hanterad instans på tjänstnivån Affärskritisk än på tjänstnivån Generell användning. När övergången till Azure har slutförts är databaserna inte tillgängliga förrän de har kopierats från den primära repliken till de tre sekundära replikerna, vilket kan ta lång tid beroende på storleken på databasen. Ju större databasen är, desto längre tid tar det att kopiera till de sekundära replikerna, upp till potentiellt flera timmar.

Om det är viktigt att databaser är tillgängliga så snart övergången är slutförd bör du överväga följande lösningar:

• Migrera först till tjänstnivån Generell användning och uppgradera sedan till tjänstnivån Affärskritisk. Uppgradering av servicenivån är en åtgärd som sker online och håller dina databaser online tills en kort failover är det sista steget i uppgraderingsprocessen.
• Använd länken Hanterad instans för en onlinemigrering till en affärskritisk-instans utan att behöva vänta på att databaser ska vara tillgängliga efter snabbningen.

Felsöka LRS-problem

När du har startat LRS använder du någon av följande övervakningscmdletar för att se status för den pågående åtgärden:

• För PowerShell: get-azsqlinstancedatabaselogreplay
• För Azure CLI: az_sql_midb_log_replay_show

Så här granskar du information om en misslyckad åtgärd:

• För PowerShell: Get-AzSqlInstanceOperation
• För Azure CLI: az sql mi op show

Om LRS inte startar efter ett tag och du får ett felmeddelande ska du kontrollera de vanligaste orsakerna:

• 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.
• Gäller behörigheterna för SAS-token Läs och Lista endast? Om du beviljar fler behörigheter än Read och List misslyckas LRS.
• 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

• Läs mer om migrera till Azure SQL Managed Instance med hjälp av länkfunktionen.
• Läs mer om migrering från SQL Server till Azure SQL Managed Instance.
• Läs mer om de skillnaderna mellan SQL Server och SQL Managed Instance.
• Läs mer om bästa metoder för att kostnads- och storleksbedöma arbetsbelastningar som migrerats till Azure .