Databases migreren van SQL Server met behulp van logboekherhalingsservice - Azure SQL Managed Instance

van toepassing op:Azure SQL Managed Instance

In dit artikel wordt uitgelegd hoe u databases migreert naar Azure SQL Managed Instance met behulp van LRS-(Log Replay Service). LRS is een gratis cloudservice die beschikbaar is voor Azure SQL Managed Instance, op basis van sql Server-technologie voor logboekverzending.

De volgende bronnen worden ondersteund:

• SQL Server op virtuele machines
• Amazon EC2 (Elastic Compute Cloud)
• Amazon RDS (Relational Database Service) voor SQL Server
• Google Compute Engine
• Cloud SQL voor SQL Server - GCP (Google Cloud Platform)

Voorwaarden

Belangrijk

• Voordat u databases migreert naar de servicelaag Bedrijfskritiek servicelaag, moet u rekening houden met deze beperkingen, die niet van toepassing zijn op de servicelaag Algemeen gebruik.
• U kunt geen databases gebruiken die worden hersteld via LRS totdat het migratieproces is voltooid.
• LRS biedt geen ondersteuning voor alleen-lezentoegang tot databases tijdens de migratie.
• Nadat de migratie is voltooid, is het migratieproces definitief en kan het niet worden hervat met extra differentiële back-ups.

Voordat u begint, moet u rekening houden met de vereisten in deze sectie voor zowel uw SQL Server-exemplaar als Azure. Controleer zorgvuldig de secties beperkingen en aanbevolen procedures om een geslaagde migratie te garanderen.

SQL Server

Zorg ervoor dat u voldoet aan de volgende vereisten voor SQL Server:

• SQL Server-versies 2008 tot en met 2022.
• Uw SQL Server-database maakt gebruik van het volledige herstelmodel (verplicht).
• Een volledige back-up van databases (een of meerdere bestanden).
• Een differentiële back-up (een of meerdere bestanden).
• Een logboekback-up (niet gesplitst voor een transactielogboekbestand).
• Voor SQL Server-versies 2008 tot en met 2016 maakt u lokaal een back-up en deze handmatig uploaden naar uw Azure Blob Storage-account.
• Voor SQL Server 2016 en hoger kunt u uw back-up rechtstreeks naar uw Azure Blob Storage-account.
• Hoewel CHECKSUM ingeschakeld voor back-ups niet vereist is, wordt het ten zeerste aanbevolen om onbedoeld te voorkomen dat een beschadigde database wordt gemigreerd en voor snellere herstelbewerkingen.

Azuur

Zorg ervoor dat u voldoet aan de volgende vereisten voor Azure:

• PowerShell Az.SQL moduleversie 4.0.0 of hoger ( geïnstalleerd of geopend via Azure Cloud Shell-).
• Azure CLI versie 2.42.0 of hoger (geïnstalleerd).
• Een geconfigureerde Azure Blob Storage-container.
• Een SAS-beveiligingstoken (Shared Access Signature) met Read- en List machtigingen die zijn gegenereerd voor de Blob Storage-container of een beheerde identiteit die toegang heeft tot de container. Het verlenen van meer machtigingen dan Read en List zorgt ervoor dat LRS mislukt.
• Plaats back-upbestanden voor een afzonderlijke database in een afzonderlijke map in een opslagaccount met behulp van een platte bestandsstructuur (verplicht). Het nesten van mappen in databasemappen wordt niet ondersteund.

Azure RBAC-machtigingen

Voor het uitvoeren van LRS via de opgegeven clients is een van de volgende RBAC-rollen (op rollen gebaseerd toegangsbeheer) van Azure vereist:

• rol inzender van SQL Managed Instance
• Een rol met de volgende machtiging: Microsoft.Sql/managedInstances/databases/*

Beste praktijken

Houd rekening met de volgende aanbevolen procedures wanneer u LRS gebruikt:

• Voer Data Migration Assistant uit om te controleren of uw databases klaar zijn om te worden gemigreerd naar SQL Managed Instance.
• Splits volledige en differentiële back-ups in meerdere bestanden, in plaats van één bestand te gebruiken.
• Schakel back-upcompressie in om de netwerkoverdrachtsnelheden te helpen.
• Gebruik Cloud Shell om PowerShell- of CLI-scripts uit te voeren, omdat deze altijd wordt bijgewerkt om de meest recente uitgebrachte cmdlets te gebruiken.
• Configureer een onderhoudsvenster zodat systeemupdates op een specifieke dag en tijd buiten het migratievenster worden gepland om te voorkomen dat de migratie wordt vertraagd of onderbroken.
• Plan om één LRS-migratietaak binnen maximaal 30 dagen te voltooien. Na verloop van dit tijdsbestek wordt de LRS-taak automatisch geannuleerd.
• Schakel CHECKSUM in wanneer u uw back-ups maakt om onbedoeld te voorkomen dat een beschadigde database wordt gemigreerd en voor een snellere herstelbewerking van de database. Hoewel SQL Managed Instance een basisintegriteitscontrole uitvoert op back-ups zonder CHECKSUM, is het niet gegarandeerd om alle vormen van beschadiging te ondervangen. Het maken van back-ups met CHECKSUM is de enige manier om ervoor te zorgen dat de back-up die is hersteld naar SQL Managed Instance niet beschadigd is. De basisintegriteitscontrole op back-ups zonder CHECKSUM verhoogt de hersteltijd van een database.
• Wanneer u migreert naar de servicelaag Bedrijfskritieke, moet u rekening houden met een langdurige vertraging in databasebeschikbaarheid na cutover, terwijl databases worden geseed naar secundaire replica's. Voor met name grote databases met minimale downtimevereisten kunt u eerst migreren naar de servicelaag Algemeen gebruik en vervolgens upgraden naar de servicelaag Bedrijfskritieke of de koppeling Managed Instance gebruiken om uw gegevens te migreren.
• Het uploaden van duizenden databasebestanden die moeten worden hersteld, kan leiden tot overmatige migratietijden en zelfs fouten. Voeg databases samen in minder bestanden om het migratieproces te versnellen en het succes ervan te garanderen.
• Als u de cutover-tijd wilt minimaliseren en het risico op fouten wilt verminderen, moet u ervoor zorgen dat uw laatste back-up zo klein mogelijk is.

Een onderhoudsvenster configureren

Systeemupdates voor SQL Managed Instance hebben voorrang op databasemigraties die worden uitgevoerd.

Migratie wordt anders beïnvloed op basis van de servicelaag:

• In de servicelaag Algemeen gebruik worden alle wachtende LRS-migraties opgeschort en hervat nadat de update is toegepast. Dit systeemgedrag kan de migratietijd verlengen, met name voor grote databases.
• In de bedrijfskritieke-servicelaag worden alle wachtende LRS-migraties geannuleerd en automatisch opnieuw opgestart nadat de update is toegepast. Dit systeemgedrag kan de migratietijd verlengen, met name voor grote databases.

Als u een voorspelbaar tijdstip voor databasemigraties wilt bereiken, kunt u overwegen om een onderhoudsvenster te configureren om systeemupdates voor een specifieke dag en tijd te plannen en migratietaken uit te voeren en uit te voeren buiten het aangewezen tijdsbestek voor onderhoudsvensters. Voor een migratie die op maandag begint, configureert u bijvoorbeeld uw aangepaste onderhoudsvenster op zondag, zodat de migratie de meeste tijd kan worden voltooid.

Het configureren van een onderhoudsvenster is niet vereist, maar wordt ten zeerste aanbevolen voor grote databases.

Notitie

Hoewel een onderhoudsvenster de voorspelbaarheid van geplande updates beheert, wordt niet gegarandeerd dat niet-geplande failovers of beveiligingsupdates niet worden uitgevoerd. Een niet-geplande failover of een beveiligingspatch (die voorrang heeft op alle andere updates) kan uw migratie nog steeds onderbreken.

Meerdere databases migreren

Als u meerdere databases migreert met behulp van dezelfde Azure Blob Storage-container, moet u back-upbestanden voor verschillende databases in afzonderlijke mappen in de container plaatsen. Alle back-upbestanden voor één database moeten in een platte bestandsstructuur in een databasemap worden geplaatst en de mappen kunnen niet worden genest. Het nesten van mappen in databasemappen wordt niet ondersteund.

Hier volgt een voorbeeld van een mapstructuur in een Azure Blob Storage-container, een structuur die nodig is om meerdere databases te migreren met behulp van 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>

Een opslagaccount maken

U gebruikt een Azure Blob Storage-account als intermediaire opslag voor back-upbestanden tussen uw SQL Server-exemplaar en uw SQL Managed Instance-implementatie. Ga als volgt te werk om een nieuw opslagaccount en een blobcontainer in het opslagaccount te maken:

1. Een opslagaccount maken.
2. Een blobcontainer maken in het opslagaccount.

Azure Storage configureren achter een firewall

Het gebruik van Azure Blob Storage die wordt beveiligd achter een firewall wordt ondersteund, maar vereist aanvullende configuratie. Als u lees-/schrijftoegang tot Azure Storage wilt inschakelen met Azure Firewall ingeschakeld, moet u het subnet van het beheerde SQL-exemplaar toevoegen aan de firewallregels van het virtuele netwerk voor het opslagaccount met behulp van MI-subnetdelegering en het opslagservice-eindpunt. Het opslagaccount en het beheerde exemplaar moeten zich in dezelfde regio bevinden of twee gekoppelde regio's.

Als uw Azure-opslag zich achter een firewall bevindt, ziet u mogelijk het volgende bericht in het foutenlogboek van het beheerde SQL-exemplaar:

Audit: Storage access denied user fault. Creating an email notification:

Hiermee wordt een e-mail gegenereerd die aangeeft dat de auditing voor het beheerde SQL-exemplaar niet in staat is om auditlogboeken naar het opslagaccount te schrijven. Als u deze fout ziet of deze e-mail ontvangt, volgt u de stappen in deze sectie om uw firewall te configureren.

Voer de volgende stappen uit om de firewall te configureren:

1. Ga naar uw beheerde exemplaar in de Azure Portal en selecteer het subnet om de pagina Subnetten te openen.

   

2. Selecteer op de pagina Subnetten de naam van het subnet om de configuratiepagina van het subnet te openen.

   

3. Onder subnetdelegatiekies Microsoft.Sql/managedInstances uit de Delegeren naar een service vervolgkeuzelijst. Wacht ongeveer een uur tot machtigingen zijn doorgegeven en kies vervolgens onder Service-eindpuntenMicrosoft.Storage in de vervolgkeuzelijst Services.

   

4. Ga vervolgens naar uw opslagaccount in Azure Portal, selecteer Netwerken onder Security + networking en kies vervolgens het tabblad Firewalls en virtuele netwerken.

5. Kies op het tabblad Firewalls en virtuele netwerken voor uw opslagaccount +Bestaand virtueel netwerk toevoegen om de pagina Netwerken toevoegen te openen.

   

6. Selecteer het juiste abonnement, het virtuele netwerk en het subnet van het beheerde exemplaar in de vervolgkeuzelijsten en selecteer vervolgens Toevoegen om het virtuele netwerk van het beheerde SQL-exemplaar toe te voegen aan het opslagaccount.

Verifiëren bij uw Blob Storage-account

Gebruik een SAS-token of een beheerde identiteit voor toegang tot uw Azure Blob Storage-account.

Waarschuwing

U kunt niet zowel een SAS-token als een beheerde identiteit parallel in hetzelfde opslagaccount gebruiken. U kunt een SAS-tokenof een beheerde identiteit gebruiken, maar niet allebei.

Een SAS-verificatietoken voor Blob Storage genereren voor LRS

Open uw Azure Blob Storage-account met behulp van een SAS-token.

U kunt een Azure Blob Storage-account gebruiken als tussenliggende opslag voor back-upbestanden tussen uw SQL Server-exemplaar en uw SQL Managed Instance-implementatie. Genereer een SAS-verificatietoken voor LRS met alleen lees- en lijstmachtigingen. Met het token kan LRS toegang krijgen tot uw Blob Storage-account en worden de back-upbestanden gebruikt om ze te herstellen naar uw beheerde exemplaar.

Volg deze stappen om het token te genereren:

1. Open in de Azure-portal Storage Explorer.

2. Vouw Blobcontainersuit.

3. Klik met de rechtermuisknop op de blobcontainer en selecteer Shared Access Signature ophalen.

   

4. Selecteer het tijdsbestek voor het verlopen van tokens. Zorg ervoor dat het token geldig is tijdens uw migratie.

5. Selecteer de tijdzone voor het token: UTC of uw lokale tijd.

   Belangrijk

   De tijdzone van het token en uw beheerde exemplaar komen mogelijk niet overeen. Zorg ervoor dat het SAS-token de juiste geldigheidsduur heeft, waarbij rekening wordt gehouden met tijdzones. Als u rekening wilt houden met tijdzoneverschillen, stelt u de geldigheid FROM waarde goed in voordat het migratievenster wordt gestart en stelt u de NAAR waarde goed in nadat u verwacht dat de migratie is voltooid.

6. Selecteer alleen machtigingen voor Lezen en Lijst.

   Belangrijk

   Selecteer geen andere machtigingen. Als u dit doet, zal LRS niet starten. Deze beveiligingsvereiste is standaard.

7. Selecteer Maak.

   

De SAS-verificatie wordt gegenereerd met de geldigheidsduur die u hebt opgegeven. U hebt de URI-versie van het token nodig, zoals wordt weergegeven in de volgende schermopname:

Notitie

Het gebruik van SAS-tokens die zijn gemaakt met machtigingen ingesteld door een opgeslagen toegangsbeleid te definiëren, wordt momenteel niet ondersteund. Volg de instructies in deze procedure om handmatig Lees- en List- machtigingen voor het SAS-token op te geven.

Parameters kopiëren van het SAS-token

Open uw Azure Blob Storage-account met behulp van een SAS-token of een beheerde identiteit.

Voordat u het SAS-token gebruikt om LRS te starten, moet u de structuur ervan begrijpen. De URI van het gegenereerde SAS-token bestaat uit twee delen, gescheiden door een vraagteken (?), zoals wordt weergegeven in dit voorbeeld:

Het eerste deel, beginnend met https:// tot het vraagteken (?), wordt gebruikt voor de parameter StorageContainerURI die wordt ingevoerd als invoer voor LRS. Het geeft LRS informatie over de map waarin de back-upbestanden van de database worden opgeslagen.

Het tweede deel, van na het vraagteken (?) tot het einde van de tekenreeks, is de StorageContainerSasToken parameter. Dit deel is het werkelijke ondertekende verificatietoken, dat geldig is gedurende de opgegeven tijd. Dit onderdeel hoeft niet per se te beginnen met sp=, zoals wordt weergegeven in het voorbeeld. Uw scenario kan afwijken.

Kopieer de parameters als volgt:

1. Kopieer het eerste deel van het token, van https:// tot en met het vraagteken (?). Gebruik deze als de parameter StorageContainerUri in PowerShell of de Azure CLI wanneer u LRS start.

   

2. Kopieer het tweede deel van het token, van na het vraagteken (?) tot het einde van de tekenreeks. Gebruik deze als de parameter StorageContainerSasToken in PowerShell of de Azure CLI wanneer u LRS start.

   

Notitie

Neem het vraagteken (?) niet op wanneer u een deel van het token kopieert.

beheerde identiteit

Als u een beheerde identiteit wilt gebruiken, wijst u een door het systeem beheerde of door de gebruiker beheerde identiteit toe voor toegang tot de Azure Blob Storage-container.

Voer hiervoor de volgende stappen uit:

1. Ga in de Azure Portalnaar het Blob Storage-account waartoe u de toegang van de beheerde instantie wilt verlenen.
2. Selecteer Toegangsbeheer (IAM).
3. Selecteer toevoegen en selecteer vervolgens Roltoewijzing toevoegen.
4. Zoek en selecteer de bestaande rol Storage Blob Data Reader. Aangepaste rollen worden ondersteund zolang ze lees- en lijstmachtigingen hebben, minimaal.
5. Selecteer Beheerde identiteit.
6. Gebruik de optie Leden selecteren om uw abonnement te identificeren.
7. Selecteer in de vervolgkeuzelijst Managed IdentitySQL Managed Instanceen selecteer vervolgens het beheerde exemplaar waarnaar u wilt migreren.
8. Kies Selecteer om uw instellingen op te slaan en toegang te autoriseren.
9. Voltooi het proces door Beoordelen en toewijzente selecteren.

De toegang tot de opslag van uw beheerde instantie valideren

Controleer of uw beheerde exemplaar toegang heeft tot uw Blob Storage-account.

Upload eerst een databaseback-up, zoals full_0_0.bak, naar uw Azure Blob Storage-container.

Maak vervolgens verbinding met uw beheerde exemplaar en voer een voorbeeldtestquery uit om te bepalen of uw beheerde exemplaar toegang heeft tot de back-up in de container.

Als u een SAS-token gebruikt om te verifiëren bij uw opslagaccount, vervangt u de <sastoken> door uw SAS-token en voert u de volgende query uit op uw exemplaar:

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' 

beheerde identiteit

Als u een beheerde identiteit gebruikt om te verifiëren bij uw opslagaccount, werkt u de CREATE CREDENTIAL bij met de URL van uw opslagaccount en voert u de volgende voorbeeldquery uit op uw exemplaar:

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' 

Back-ups uploaden naar uw Blob Storage-account

Wanneer uw blobcontainer gereed is en u hebt bevestigd dat uw beheerde exemplaar toegang heeft tot de container, kunt u beginnen met het uploaden van uw back-ups naar uw Blob Storage-account. U kunt het volgende doen:

• Kopieer uw back-ups naar uw Blob Storage-account.
• Maak back-ups van SQL Server rechtstreeks naar uw Blob Storage-account met behulp van de OPDRACHT BACKUP TO URL, als uw omgeving dit toestaat (te beginnen met SQL Server-versies 2012 SP1 CU2 en SQL Server 2014).

Bestaande back-ups kopiëren naar uw Blob Storage-account

Als u een eerdere versie van SQL Server gebruikt of als uw omgeving geen back-ups rechtstreeks naar een URL ondersteunt, maakt u uw back-ups op uw SQL Server-exemplaar zoals u dat normaal zou doen en kopieert u deze vervolgens naar uw Blob Storage-account.

Back-ups maken op een SQL Server-exemplaar

Stel databases in die u wilt migreren naar het volledige herstelmodel om logboekback-ups toe te staan.

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

Als u handmatig volledige, differentiële en logboekback-ups van uw database naar lokale opslag wilt maken, gebruikt u de volgende T-SQL-voorbeeldscripts. CHECKSUM is niet vereist, maar het wordt aanbevolen om te voorkomen dat een beschadigde database wordt gemigreerd en voor snellere hersteltijden.

In het volgende voorbeeld wordt een volledige databaseback-up naar de lokale schijf gemaakt:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

In het volgende voorbeeld wordt een differentiële back-up naar de lokale schijf gebruikt:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

In het volgende voorbeeld wordt een back-up van het transactielogboek naar de lokale schijf uitgevoerd:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

Back-ups kopiëren naar uw Blob Storage-account

Nadat uw back-ups klaar zijn en u wilt beginnen met het migreren van databases naar een beheerd exemplaar met behulp van LRS, kunt u de volgende methoden gebruiken om bestaande back-ups naar uw Blob Storage-account te kopiëren:

• Download en installeer AzCopy.
• Download en installeer Azure Storage Explorer.
• Gebruik Storage Explorer in azure Portal.

Notitie

Als u meerdere databases wilt migreren met behulp van dezelfde Azure Blob Storage-container, plaatst u alle back-upbestanden voor een afzonderlijke database in een afzonderlijke map in de container. Gebruik platte bestandsstructuur voor elke databasemap. Het nesten van mappen in databasemappen wordt niet ondersteund.

Maak rechtstreeks back-ups naar uw Blob Storage-account

Als u een ondersteunde versie van SQL Server gebruikt (te beginnen met SQL Server 2012 SP1 CU2 en SQL Server 2014), en uw bedrijf- en netwerkbeleid dit toestaat, kunt u back-ups van SQL Server rechtstreeks naar uw Blob Storage-account maken met behulp van de systeemeigen SQL Server BACKUP TO URL optie. Als u BACKUP TO URLkunt gebruiken, hoeft u geen back-ups te maken naar de lokale opslag en deze te uploaden naar uw Blob Storage-account.

Wanneer u systeemeigen back-ups rechtstreeks naar uw Blob Storage-account neemt, moet u zich verifiëren bij het opslagaccount.

Gebruik de volgende opdracht om een referentie te maken waarmee het SAS-token wordt geïmporteerd naar uw SQL Server-exemplaar:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';  

Raadpleeg de zelfstudie Azure Blob Storage gebruiken met SQL Servervoor gedetailleerde instructies voor het werken met SAS-tokens.

Nadat u de referentie hebt gemaakt om uw SQL Server-exemplaar te authenticeren met Blob Storage, kunt u de BACKUP TO URL opdracht gebruiken om back-ups rechtstreeks naar het opslagaccount te maken. CHECKSUM wordt aanbevolen, maar niet vereist.

In het volgende voorbeeld wordt een volledige databaseback-up naar een URL gemaakt:

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

In het volgende voorbeeld wordt een back-up van een differentiële database naar een URL gemaakt:

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

In het volgende voorbeeld wordt een back-up van een transactielogboek naar een URL gebruikt:

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

Meld u aan bij Azure en selecteer een abonnement

Gebruik de volgende PowerShell-cmdlet om u aan te melden bij Azure:

Login-AzAccount

Selecteer het abonnement waarin uw beheerde exemplaar zich bevindt met behulp van de volgende PowerShell-cmdlet:

Select-AzSubscription -SubscriptionId <subscription ID>

De migratie starten

Start de migratie door LRS te starten. U kunt de service starten in de modus automatisch aanvullen of continu.

Wanneer u de modus voor automatisch aanvullen gebruikt, wordt de migratie automatisch voltooid wanneer de laatste van de opgegeven back-upbestanden zijn hersteld. Voor deze optie moet de volledige back-upketen van tevoren beschikbaar zijn en naar uw Blob Storage-account worden geüpload. Het is niet toegestaan om nieuwe back-upbestanden toe te voegen terwijl de migratie wordt uitgevoerd. Voor deze optie is de start opdracht vereist om de bestandsnaam van het laatste back-upbestand op te geven. We raden deze modus aan voor passieve werkbelastingen waarvoor geen gegevensophaalbewerking is vereist.

Wanneer u continue modus gebruikt, scant de service continu de map Azure Blob Storage en herstelt deze nieuwe back-upbestanden die worden toegevoegd terwijl de migratie wordt uitgevoerd. De migratie wordt pas voltooid nadat de handmatige cutover is aangevraagd. U moet continue modusmigratie gebruiken wanneer u niet de volledige back-upketen van tevoren hebt en wanneer u van plan bent om nieuwe back-upbestanden toe te voegen nadat de migratie wordt uitgevoerd. We raden deze modus aan voor actieve werkbelastingen waarvoor gegevensophaalbewerking is vereist.

Plan om één LRS-migratietaak binnen maximaal 30 dagen te voltooien. Wanneer deze tijd verloopt, wordt de LRS-taak automatisch geannuleerd.

Notitie

Wanneer u meerdere databases migreert, moet elke database zich in een eigen map bevinden. LRS moet afzonderlijk worden gestart voor elke database, die verwijst naar het volledige URI-pad van de Azure Blob Storage-container en de afzonderlijke databasemap. Geneste mappen in databasemappen worden niet ondersteund.

LRS starten in de modus voor automatisch aanvullen

Zorg ervoor dat de volledige back-upketen is geüpload naar uw Azure Blob Storage-account. Met deze optie kunnen geen nieuwe back-upbestanden worden toegevoegd terwijl de migratie wordt uitgevoerd.

Als u LRS wilt starten in de modus voor automatisch aanvullen, gebruikt u PowerShell- of Azure CLI-opdrachten. Geef de naam van het laatste back-upbestand op met behulp van de parameter -LastBackupName. Nadat het herstellen van het laatst opgegeven back-upbestand is voltooid, start de service automatisch een cutover.

Herstel uw database vanuit het opslagaccount met behulp van het SAS-token of een beheerde identiteit.

Belangrijk

• Zorg ervoor dat de volledige back-upketen is geüpload naar uw Azure Blob Storage-account voordat u de migratie start in de modus voor automatisch aanvullen. In deze modus kunnen geen nieuwe back-upbestanden worden toegevoegd terwijl de migratie wordt uitgevoerd.
• Zorg ervoor dat u het laatste back-upbestand correct hebt opgegeven en dat u erna nog geen bestanden hebt geüpload. Als het systeem meer back-upbestanden detecteert dan het laatst opgegeven back-upbestand, mislukt de migratie.

In het volgende PowerShell-voorbeeld wordt LRS gestart in de modus voor automatisch aanvullen met behulp van een 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"

In het volgende Azure CLI-voorbeeld wordt LRS gestart in de modus voor automatisch aanvullen met behulp van een 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"

beheerde identiteit

In het volgende PowerShell-voorbeeld wordt LRS gestart in de modus voor automatisch aanvullen met behulp van een beheerde identiteit:

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"

LRS starten in continue modus

Zorg ervoor dat u de initiële back-upketen hebt geüpload naar uw Azure Blob Storage-account.

Belangrijk

Nadat u LRS in continue modus hebt gestart, kunt u nieuwe logboek- en differentiële back-ups toevoegen aan uw opslagaccount totdat de handmatige cutover is uitgevoerd. Nadat de handmatige cutover is gestart, kunnen er geen extra differentiële bestanden worden toegevoegd of hersteld.

In het volgende PowerShell-voorbeeld wordt LRS in continue modus gestart met behulp van een 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"

In het volgende Azure CLI-voorbeeld wordt LRS gestart in continue modus:

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"

beheerde identiteit

In het volgende PowerShell-voorbeeld wordt LRS in continue modus gestart met behulp van een beheerde identiteit:

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

Script voor de migratietaak

PowerShell- en Azure CLI-clients die LRS starten in continue modus, zijn synchroon. In deze modus wachten PowerShell en de Azure CLI op het API-antwoord om te rapporteren over succes of mislukking voordat de taak wordt gestart.

Tijdens deze wachttijd geeft het commando de controle niet terug aan de opdrachtregel. Als u de migratie-ervaring scriptt en u de LRS-startopdracht nodig hebt om direct de besturing terug te geven om door te gaan met de rest van het script, kunt u PowerShell uitvoeren als achtergrondtaak met de -AsJob-switch. Bijvoorbeeld:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Wanneer u een achtergrondtaak start, wordt een taakobject onmiddellijk geretourneerd, zelfs als het langer duurt voordat de taak is voltooid. U kunt zonder onderbreking in de sessie blijven werken terwijl de taak wordt uitgevoerd. Zie de documentatie PowerShell Start-Job voor meer informatie over het uitvoeren van PowerShell als achtergrondtaak.

Als u een Azure CLI-opdracht in Linux als achtergrondproces wilt starten, gebruikt u de ampersand (&) aan het einde van de LRS-startopdracht:

az sql midb log-replay start <required parameters> &

Migratievoortgang bewaken

Az.SQL 4.0.0 en hoger bevat een gedetailleerd voortgangsrapport. Bekijk de details van over het herstellen van beheerde databases - haal op voor een voorbeeldoutput.

Gebruik de volgende opdracht om de voortgang van de lopende migratie via PowerShell te controleren:

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

Gebruik de volgende opdracht om de voortgang van de lopende migratie via de Azure CLI te controleren:

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

Als u aanvullende informatie over een mislukte aanvraag wilt bijhouden, gebruikt u de PowerShell-opdracht Get-AzSqlInstanceOperation of gebruikt u de Azure CLI-opdracht az sql mi op show.

De migratie stoppen (optioneel)

Als u de migratie wilt stoppen, gebruikt u PowerShell of de Azure CLI. Als u de migratie stopt, wordt de hersteldatabase op uw beheerde exemplaar verwijderd, zodat het hervatten van de migratie niet mogelijk is.

Gebruik de volgende opdracht om het migratieproces via PowerShell te stoppen:

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

Gebruik de volgende opdracht om het migratieproces via de Azure CLI te stoppen:

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

De migratie voltooien (continue modus)

Als u LRS in continue modus start, moet u ervoor zorgen dat uw toepassing en SQL Server-workload zijn gestopt om te voorkomen dat er nieuwe back-upbestanden worden gegenereerd. Zorg ervoor dat de laatste back-up van uw SQL Server-exemplaar is geüpload naar uw Azure Blob Storage-account. Controleer op uw beheerde exemplaar de voortgang van het herstel en zorg ervoor dat de laatste log-back-up is hersteld.

Wanneer de laatste logboekstaart-back-up is hersteld op uw beheerde exemplaar, start u de handmatige overgang om de migratie te voltooien. Nadat de cutover is voltooid, is de database beschikbaar voor lees- en schrijftoegang op het beheerde exemplaar.

Gebruik de volgende opdracht om het migratieproces in de continue LRS-modus via PowerShell te voltooien:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Gebruik de volgende opdracht om het migratieproces in de continue LRS-modus via de Azure CLI te voltooien:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Beperkingen

Houd rekening met de volgende beperkingen bij het migreren met LRS:

• U kunt geen databases gebruiken die worden hersteld via LRS totdat het migratieproces is voltooid.
• Tijdens het migratieproces kunnen databases die worden gemigreerd, niet worden gebruikt voor alleen-lezentoegang op SQL Managed Instance.
• Nadat de migratie is voltooid, is het migratieproces definitief en kan het niet worden hervat met extra differentiële back-ups.
• Alleen database-.bak-, .log- en .diff-bestanden worden ondersteund door LRS. Dacpac- en bacpac-bestanden worden niet ondersteund.
• U moet een onderhoudsvenster configureren om systeemupdates op een specifieke dag en tijd te plannen. Plan om migraties uit te voeren en te voltooien buiten het geplande onderhoudsvenster.
• Back-ups van databases die worden gemaakt zonder CHECKSUM:
  • kan beschadigde databases mogelijk migreren.
  • duurt langer om te herstellen dan databaseback-ups met CHECKSUM ingeschakeld.
• Het SAS-token (Shared Access Signature) dat door LRS wordt gebruikt, moet worden gegenereerd voor de hele Azure Blob Storage-container en moet alleen Read en List machtigingen hebben. Als u bijvoorbeeld Read, Listen Write machtigingen verleent, kan LRS niet worden gestart vanwege de extra Write machtiging.
• Het gebruik van SAS-tokens die zijn gemaakt met machtigingen die zijn ingesteld door het definiëren van een opgeslagen toegangsbeleid niet wordt ondersteund. Volg de instructies in dit artikel om handmatig lees- en lijstmachtigingen voor het SAS-token op te geven.
• U moet back-upbestanden voor verschillende databases in afzonderlijke mappen in het Blob Storage-account in een platte bestandsstructuur plaatsen. Het nesten van mappen in databasemappen wordt niet ondersteund.
• Als u de modus voor automatisch aanvullen gebruikt, moet de volledige back-upketen vooraf beschikbaar zijn in het Blob Storage-account. Het is niet mogelijk om nieuwe back-upbestanden toe te voegen in de modus voor automatisch aanvullen. Gebruik de continue modus als u nieuwe back-upbestanden moet toevoegen terwijl de migratie wordt uitgevoerd.
• U moet LRS afzonderlijk starten voor elke database die verwijst naar het volledige URI-pad dat een afzonderlijke databasemap bevat.
• Het back-up-URI-pad, de containernaam of mapnamen mogen geen backup of backups bevatten, omdat dit gereserveerde trefwoorden zijn.
• Wanneer u meerdere herstelbewerkingen voor logboekherhaling parallel start, die gericht zijn op dezelfde opslagcontainer, moet u ervoor zorgen dat hetzelfde geldige SAS-token wordt opgegeven voor elke herstelbewerking.
• LRS kan maximaal 100 gelijktijdige herstelprocessen per beheerd exemplaar ondersteunen.
• Eén LRS-taak kan maximaal 30 dagen worden uitgevoerd, waarna deze automatisch wordt geannuleerd.
• Hoewel het mogelijk is om een Azure Storage-account achter een firewall te gebruiken, is er extra configuratie nodig en moet het opslagaccount en het beheerde exemplaar zich in dezelfde regio bevinden of twee gekoppelde regio's. Raadpleeg Firewall configureren voor meer informatie.
• Het maximum aantal databases dat u parallel kunt herstellen, is 200 per abonnement. In sommige gevallen is het mogelijk om deze limiet te verhogen door een ondersteuningsticket te openen.
• Het uploaden van duizenden databasebestanden die moeten worden hersteld, kan leiden tot overmatige migratietijden en zelfs fouten. Voeg databases samen in minder bestanden om het migratieproces te versnellen en het succes ervan te garanderen.
• Er zijn twee scenario's, aan het begin en einde van het migratieproces, waarbij een migratie wordt afgebroken als er een failover plaatsvindt en de migratietaak handmatig opnieuw moet worden gestart vanaf het begin, omdat de database wordt verwijderd uit SQL Managed Instance:
  • Als er een failover optreedt wanneer de eerste volledige databaseback-up wordt hersteld naar SQL Managed Instance wanneer de migratietaak voor het eerst wordt gestart, moet de migratietaak handmatig opnieuw worden gestart vanaf het begin.
  • Als er een failover optreedt nadat de migratie-cutover is gestart, moet de migratietaak handmatig opnieuw worden gestart vanaf het begin. Zorg ervoor dat het laatste back-upbestand zo klein mogelijk is om de cutover-tijd te minimaliseren en het risico op een failover tijdens het cutover-proces te verminderen.

Notitie

Als u wilt dat een database alleen-lezen toegankelijk is tijdens de migratie, met een aanzienlijk langere periode voor het uitvoeren van de migratie en met minimale downtime, overweeg dan om de functie Beheerde Instantie als een aanbevolen migratieoplossing te gebruiken.

Beperkingen bij het migreren naar de servicelaag Bedrijfskritieke

Wanneer u migreert naar een met SQL beheerd exemplaar in de servicelaag Bedrijfskritieke, moet u rekening houden met de volgende beperkingen:

• Bij het migreren van grote databases kan er aanzienlijke downtime optreden omdat databases na cutover niet beschikbaar zijn terwijl databases worden geseed naar secundaire replica's van de Bedrijfskritieke servicelaag. Tijdelijke oplossingen worden weergegeven in de langere overgang sectie.
• De migratie wordt vanaf het begin automatisch opnieuw gestart als de migratie wordt onderbroken door een niet-geplande failover, systeemupdate of beveiligingspatch, waardoor het moeilijk is om een voorspelbare migratie te plannen zonder verrassingen van last minute.

Belangrijk

Deze beperkingen zijn alleen van toepassing wanneer u migreert naar de servicelaag Bedrijfskritieke en niet naar de servicelaag Algemeen gebruik.

Langere cutover in de Bedrijfskritieke servicelaag

Als u migreert naar een met SQL beheerd exemplaar in de servicelaag Bedrijfskritieke, moet u rekening houden met de vertraging bij het online brengen van de databases op de primaire replica terwijl ze worden geseed naar de secundaire replica's. Dit geldt met name voor grotere databases.

Migreren naar een met SQL beheerd exemplaar in de Bedrijfskritieke servicelaag duurt langer dan in de servicelaag Algemeen gebruik. Nadat cutover naar Azure is voltooid, zijn databases niet beschikbaar totdat ze van de primaire replica naar de drie secundaire replica's zijn geseed, wat een langere tijd kan duren, afhankelijk van de grootte van uw database. Hoe groter de database, hoe langer het seeden naar de secundaire replica's duurt, mogelijk tot enkele uren.

Als het belangrijk is dat databases beschikbaar zijn zodra de cutover is voltooid, kunt u de volgende tijdelijke oplossingen overwegen:

• Migreer eerst naar de servicelaag Algemeen gebruik en voer vervolgens een upgrade uit naar de servicelaag Bedrijfskritiek. Het upgraden van uw servicelaag is een onlinebewerking waarmee uw databases online blijven totdat een korte failover als laatste stap van de upgradebewerking wordt uitgevoerd.
• Gebruik de Managed Instance-koppeling voor een onlinemigratie naar een bedrijfskritieke exemplaar zonder te hoeven wachten tot er databases beschikbaar zijn na de cutover.

LRS-problemen oplossen

Nadat u LRS hebt gestart, gebruikt u een van de volgende controle-cmdlets om de status van de lopende bewerking te bekijken:

• Voor PowerShell: get-azsqlinstancedatabaselogreplay
• Voor de Azure CLI: az_sql_midb_log_replay_show

Volg deze stappen om details over een mislukte bewerking te bekijken:

• Voor PowerShell: Get-AzSqlInstanceOperation
• Voor Azure CLI: az sql mi op show

Als LRS na enige tijd niet kan worden gestart en er een fout optreedt, controleert u op de meest voorkomende problemen:

• Heeft een bestaande database in uw beheerde exemplaar dezelfde naam als de database die u wilt migreren van uw SQL Server-exemplaar? Los dit conflict op door de naam van een van de databases te wijzigen.
• Zijn de machtigingen verleend voor het SAS-token lezen en vermelden alleen? Het verlenen van meer machtigingen dan Read en List zorgt ervoor dat LRS mislukt.
• Hebt u het SAS-token voor LRS gekopieerd na het vraagteken (?), met inhoud die eruitziet als sv=2020-02-10...?
• Is de geldigheidsduur van het SAS-token geschikt voor het tijdvenster voor het starten en voltooien van de migratie? Er kunnen verschillen zijn vanwege de verschillende tijdzones die worden gebruikt voor uw SQL Managed Instance-implementatie en het SAS-token. Probeer het SAS-token opnieuw te genereren en de geldigheid van het token van het tijdvenster voor en na de huidige datum uit te breiden.
• Wanneer u meerdere logboekherhalingsherstelbewerkingen parallel start voor dezelfde opslagcontainer, moet u ervoor zorgen dat voor elke herstelbewerking hetzelfde geldige SAS-token wordt opgegeven.
• Zijn de naam van de database, de naam van de resourcegroep en de naam van het beheerde exemplaar correct gespeld?
• Als u LRS in de modus voor automatisch aanvullen hebt gestart, is er een geldige bestandsnaam voor het laatste back-upbestand opgegeven?
• Bevat het back-up-URI-pad trefwoorden backup of backups? Wijzig de naam van de container of mappen die gebruikmaken van backup of backups omdat dit gereserveerde trefwoorden zijn.

Volgende stappen

• Meer te weten komen over het migreren van naar Azure SQL Managed Instance door gebruik te maken van de koppelingsfunctie.
• Meer informatie over migreren van SQL Server naar Azure SQL Managed Instance.
• Meer informatie over de verschillen tussen SQL Server en SQL Managed Instance.
• Kom meer te weten over best practices voor het inschatten van kosten en het bepalen van de grootte van workloads die naar Azurezijn gemigreerd.