Dela via

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

Applies to:Azure SQL Managed Instance

Den här artikeln beskriver hur du migrerar SQL Server databaser till Azure SQL Managed Instance med hjälp av Log Replay Service (LRS). LRS är en kostnadsfri molntjänst för Azure SQL Managed Instance migreringar som bygger på SQL Server loggleveransteknik. Lär dig hela processen från förutsättningar till övergång, inklusive bästa praxis för en lyckad databasmigrering.

Obs

Nu är det möjligt att migrera din SQL Server-instans som aktiveras av Azure Arc för att Azure SQL Managed Instance direkt via Azure-portalen. Mer information finns i Migrera till Azure SQL Managed Instance.

Följande källor stöds:

  • SQL Server på virtuella maskiner
  • 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 din SQL Server-instans 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.
  • Din SQL Server databas 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 versioner 2008 till 2016 ska du göra en säkerhetskopia lokalt och manualt ladda upp den 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.
  • Alla versioner av Windows Server stöds baserat på support för SQL Server version.
  • För SQL Server 2019 och senare ska accelererad databasåterställning aktiveras, med det beständiga versionsarkivet inställt på PRIMARY. Mer information finns i Known-problem efter migrering till SQL Managed Instance i den här artikeln.
  • Om du vill använda Service Broker på en databas som migrerats till Azure SQL Managed Instance måste Service Broker vara aktiverat på källdatabasen före migreringen. Mer information finns i Known-problem efter migrering till SQL Managed Instance i den här artikeln.

Azure

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 tilldelad Azure Blob Storage-behållare.
  • En säkerhetstoken för delad åtkomst (SAS) med Read och List behörigheter som genererats för den 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 Azure åtkomstkontrollroller (RBAC):

Metodtips

När du använder LRS bör du överväga följande metodtips:

  • 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 på säkerhetskopior utan CHECKSUM, garanteras inte att alla former av skada fångas. Att göra säkerhetskopior med CHECKSUM är det enda sättet att se till att säkerhetskopian 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 stilleståndstider bör du först migrera till tjänstnivån Generell användning och sedan uppgradera till tjänstnivån Business Critical eller använda länken Managed Instance 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 ha 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 det 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 samma Azure Blob Storage container måste du placera säkerhetskopierade filer 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 lagring 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 din Azure lagring ligger 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 SQL-hanterade instans i Azure-portalen och välj undernätet för att öppna sidan Subnets.

    Skärmbild av hanterad SQL-instansens översiktssidan för Azure-portalen, med subnätet valt.

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

    Skärmdump av sidan för undernät för SQL-hanterad instans i Azure-portalen, med undernätet valt.

  3. Under Subnet-delegering väljer du Microsoft.Sql/managedInstances från listrutan delegera subnet till en tjänst. Vänta ungefär en timme på att behörigheterna ska visas och välj sedan Service-slutpunkter, välj Microsoft.Storage från listrutan Tjänster.

    Skärmbild av konfigurationssidan för SQL-hanterad instans undernät på Azure-portalen.

  4. Gå sedan till ditt lagringskonto i Azure-portalen, välj Nätverk under Säkerhet + nätverk och välj sedan fliken Firewalls 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.

    Skärmbild av sidan Lagringskontonätverk på Azure-portalen med Lägg till befintligt virtuellt nätverk valt.

  6. Välj lämplig prenumeration, virtuellt nätverk och hanterat instansundernät i listrutans menyer 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 Blob Storage SAS-autentiseringstoken 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. Gå till Storage Center i Azure-portalen och välj ditt lagringskonto.

  2. Under Säkerhet + nätverk väljer du Signatur för delad åtkomst för att öppna fönstret Signatur för delad åtkomst .

  3. I fönstret Signatur för delad åtkomst konfigurerar du inställningarna för att generera en SAS-token för LRS. Använd följande riktlinjer för att konfigurera inställningarna:

    1. Tillåtna tjänster: Blob och Fil.

    2. Tillåtna resurstyper: Tjänst.

    3. Behörigheter: Endast läsning och lista .

      Viktig

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

    4. Behörigheter för blobversioner: Valfritt

    5. Tillåtna blobindexbehörigheter: Kan inaktiveras.

    6. 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 Från-värdet långt innan migreringsfönstret startar och värdet Till långt efter att du förväntar dig att migreringen ska slutföras.

    7. Välj Generera SAS och reťazec pripojenia för att generera token:

    Skärmbild som visar val för förfallodatum för SAS-token, tidszon och behörigheter, tillsammans med knappen Skapa.

    SAS-autentiseringen genereras med den tids giltighet som du angav.

  4. Kopiera värdet som anges i Blobtjänstens SAS URL-fält, vilket är URI-versionen av token som du behöver för att starta LRS.

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:

Skärmbild av exempel-URI för en genererad SAS-token för Log Replay Service.

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 parametern StorageContainerUri 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 parametern StorageContainerSasToken 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.

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 till ditt lagringskonto ersätter du <sastoken> med din SAS-token och kör följande fråga på din instans:

CREATE CREDENTIAL [https://<mystorageaccountname>.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å din SQL Server-instans 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:

Obs

Om du vill migrera flera databaser med 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 den interna SQL Server BACKUP TILL URL alternativ. Om du kan använda BACKUP TO URL behö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änd Azure Blob Storage med SQL Server.

När du har skapat autentiseringsuppgifterna för att autentisera din SQL Server-instans 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 säkerhetskopierar 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 genomsöker tjänsten kontinuerligt mappen Azure Blob Storage och återställer alla nya säkerhetskopieringsfiler som läggs till medan migreringen pågår. 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.

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

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

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 -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 kommandot Azure CLI 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 ditt program och SQL Server arbetsbelastning har stoppats för att förhindra att nya säkerhetskopieringsfiler genereras. Kontrollera att den senaste säkerhetskopieringen från din SQL Server-instans 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.
  • Sas-token (signatur för delad åtkomst) som LRS använder måste genereras för hela Azure Blob Storage containern och måste ha behörigheterna Read och List. 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äkerhetskopierade filer 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 kan inte innehålla backup eller Backup 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 stöder migrering av totalt antal databaser till en enda instans upp till resursgränserna på tjänstnivån. Du kan till exempel återställa upp till 100 totala databaser på tjänstnivån Generell användning och upp till 500 databaser totalt på tjänstnivån Nästa generations generell användning .
  • LRS stöder 100 samtidiga databasåterställningar till en enda instans och 150 samtidiga databasåterställningar för alla instanser i en enda prenumeration. Du kan till exempel återställa 100 databaser parallellt med två instanser i samma prenumeration samtidigt, eller 50 databaser i tre samtidiga batchar parallellt med fyra separata instanser i samma prenumeration.
  • 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 150 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 migreringen avbryts om en failover inträffar, och migreringsjobbet måste startas om manuellt från början eftersom databasen tas bort 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 redan har startats, måste migreringsjobbet startas om manuellt 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.
  • Om accelerated database recovery har inaktiverats på källan SQL Server 2019 och senare instanser, kan du inte längre aktivera den efter migrering till Azure SQL Managed Instance. Om det beständiga versionsarkivet (PVS) inte är inställt på PRIMARY, kan du dessutom uppleva problem med återställningsåtgärder på den hanterade SQL-instansen.
  • Om Service Broker är inaktiverad på käll-SQL Server-instansen kan du inte använda Service Broker på den sql-hanterade målinstansen efter migreringen.

Obs

Om du kräver att en databas ska vara skrivskyddad under migreringen, med en mycket längre tidsram för att utföra migreringen och med minimal stilleståndstid, bör du överväga att använda funktionen Översikt för Managed Instance-länken som en rekommenderad migreringslösning.

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

När du migrerar till en SQL Managed Instance i tjänstnivån Business Critical bör du överväga följande begränsningar:

  • När du migrerar stora databaser kan det uppstå betydande stilleståndstid eftersom databaser inte är tillgängliga efter övergången, medan databaser överförs till sekundära repliker på servicenivå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 i tjänstnivån Affärskritisk

Om du migrerar till en SQL Managed Instance i tjänstnivån Business Critical tar du hänsyn till fördröjningen när databaserna ska aktiveras på den primära repliken medan de skickas 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 Managed Instance i tjänstnivån Business Critical ä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 initierats från den primära kopian till de tre sekundära kopiorna, vilket beroende på databasens storlek kan ta lång tid. 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 Managed Instance för en online-migrering till en Business Critical instans utan att behöva vänta på att databaserna ska bli tillgängliga efter överlämningen.

Kända problem efter migrering till SQL Managed Instance

Överväg följande kända problem efter migrering till Azure SQL Managed Instance:

Återställningsfel efter migrering till SQL Managed Instance

Om du migrerar en databas till Azure SQL Managed Instance från SQL Server 2019 och senare versioner med accelerated database recovery aktiverad, men om det är konfigurerat med det beständiga versionslagret (PVS) inställt på något annat än PRIMARY filgrupp, kan du uppleva misslyckade återställningsoperationer på den hanterade SQL-målinstansen.

Du kan undvika det här problemet genom att ange persistent version store (PVS) till PRIMARY på källdatabasen SQL Server innan du migrerar den till SQL Managed Instance. Om du redan har migrerat databasen utan att ställa in PVS på PRIMARY kan du ange den på källdatabasen SQL Server och sedan migrera databasen till SQL Managed Instance igen.

Det går inte att använda accelererad databasåterställning efter migrering till SQL Managed Instance

Om du migrerar en databas till Azure SQL Managed Instance från och med SQL Server 2019 och källdatabasen har accelererad databasåterställning inaktiverad, kan du inte använda accelererad databasåterställning på den sql-hanterade målinstansen.

Du kan undvika det här problemet genom att enable accelerated database recovery på källdatabasen SQL Server innan du migrerar den till SQL Managed Instance. Om du redan har migrerat databasen utan att aktivera accelererad databasåterställning kan du aktivera den på källdatabasen SQL Server och sedan migrera databasen till en hanterad SQL-instans igen.

SQL Server 2017 och tidigare versioner stöder inte accelererad databasåterställning, så det här problemet gäller inte databaser som migrerats från dessa versioner av SQL Server.

Det går inte att använda Service Broker efter migrering till SQL Managed Instance

Om du migrerar en databas till Azure SQL Managed Instance och Service Broker är inaktiverad på källdatabasen kan du inte använda Service Broker på den sql-hanterade målinstansen.

Du kan undvika det här problemet genom att aktivera Service Broker på källdatabasen SQL Server innan du migrerar den till SQL Managed Instance. Om du redan har migrerat databasen utan att aktivera Service Broker kan du aktivera den på källdatabasen SQL Server och sedan migrera databasen till SQL Managed Instance igen.

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:

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 din SQL Server-instans? 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.

Relaterat innehåll

  • Last updated on