Delen via

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

  • Artikel

Van toepassing op: Azure SQL Managed Instance

In dit artikel wordt uitgelegd hoe u databases migreert naar Azure SQL Managed Instance met behulp van Log Replay Service (LRS). 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 on Virtual 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)

Vereisten

Voordat u begint, moet u rekening houden met de volgende vereisten voor zowel uw SQL Server-exemplaar als Azure.

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 uploadt u deze handmatig naar uw Azure Blob Storage-account.
  • Voor SQL Server 2016 en hoger kunt u uw back-up rechtstreeks naar uw Azure Blob Storage-account maken.

CHECKSUM Hoewel het niet vereist is om back-ups te maken, raden we u ten zeerste aan om sneller herstelbewerkingen uit te voeren.

Azure

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 ingerichte Azure Blob Storage-container.
  • Een SAS-beveiligingstoken (Shared Access Signature) met lees- en lijstmachtigingen die zijn gegenereerd voor de Blob Storage-container of een beheerde identiteit die toegang heeft tot de container.
  • 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:

Aanbevolen procedures

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

  • Voer Data Migration Assistant uit om te controleren of uw databases gereed 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 netwerkoverdracht te versnellen.
  • 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 om het plannen van systeemupdates op een specifieke dag en tijd mogelijk te maken. Deze configuratie helpt een voorspelbarere tijd te bereiken voor databasemigraties, omdat systeemupgrades de actieve migraties kunnen onderbreken.
  • Plan om één LRS-migratietaak binnen maximaal 30 dagen te voltooien. Na verloop van dit tijdsbestek wordt de LRS-taak automatisch geannuleerd.
  • Schakel voor een snellere herstelbewerking CHECKSUM van de database in wanneer u uw back-ups maakt. SQL Managed Instance voert een integriteitscontrole uit op back-ups zonder CHECKSUM, waardoor de hersteltijd toeneemt.

Systeemupdates voor SQL Managed Instance hebben voorrang op databasemigraties die worden uitgevoerd. Tijdens een systeemupdate op een exemplaar worden alle wachtende LRS-migraties opgeschort en alleen hervat nadat de update is toegepast. Dit systeemgedrag kan de migratietijd verlengen, met name voor grote databases.

Voor een voorspelbare tijd voor databasemigraties kunt u overwegen 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 opgegeven tijdsbestek voor onderhoudsvensters.

Belangrijk

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

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. Maak een blobcontainer 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 vNet voor het opslagaccount met behulp van MI-subnetdelegering en het eindpunt van de opslagservice. 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 waarmee wordt aangegeven dat controle voor het beheerde SQL-exemplaar geen auditlogboeken naar het opslagaccount schrijft. 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 Azure Portal en selecteer het subnet om de pagina Subnetten te openen.

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

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

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

  3. Kies onder Subnetdelegering Microsoft.Sql/managedInstances van het subnet Delegeren naar een vervolgkeuzelijst voor de service. Wacht ongeveer een uur tot machtigingen zijn doorgegeven en kies vervolgens onder Service-eindpunten Microsoft.Storage in de vervolgkeuzelijst Services.

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

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

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

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

  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-token of een beheerde identiteit gebruiken, maar niet beide.

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 Storage Explorer in Azure Portal.

  2. Vouw BlobContainers uit.

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

    Screenshot that shows selections for generating a SAS authentication token.

  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 VAN de waarde goed in voordat het migratievenster wordt gestart en de WAARDE TO goed nadat u verwacht dat uw migratie is voltooid.

  6. Selecteer alleen lees- en lijstmachtigingen .

    Belangrijk

    Selecteer geen andere machtigingen. Als u dit wel doet, wordt LRS niet gestart. Deze beveiligingsvereiste is standaard.

  7. Selecteer Maken.

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

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:

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

Notitie

Het gebruik van SAS-tokens die zijn gemaakt met machtigingen die zijn ingesteld door een opgeslagen toegangsbeleid te definiëren, wordt op dit moment niet ondersteund. Volg de instructies in deze procedure om handmatig lees- en lijstmachtigingen 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:

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

Het eerste deel, beginnend met https:// het vraagteken (?), wordt gebruikt voor de StorageContainerURI parameter 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 deel hoeft niet per se te beginnen, 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:// maximaal tot maar niet inclusief het vraagteken (?). Gebruik deze als parameter StorageContainerUri in PowerShell of de Azure CLI wanneer u LRS start.

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

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

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

Notitie

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

Toegang tot uw beheerde exemplaar voor opslag 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 het <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'

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 hebt de volgende mogelijkheden:

  • 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 we raden het wel aan.

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:

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 rechtstreeks back-ups maken van SQL Server naar uw Blob Storage-account met behulp van de systeemeigen optie BACK-UP NAAR URL van SQL Server. Als u deze kunt gebruiken BACKUP TO URL, hoeft u geen back-ups naar de lokale opslag te maken 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 Server voor gedetailleerde instructies voor het werken met SAS-tokens.

Nadat u de referentie hebt gemaakt om uw SQL Server-exemplaar te verifiëren met Blob Storage, kunt u de opdracht BACKUP TO URL gebruiken om back-ups rechtstreeks naar het opslagaccount te maken. CHECKSUM wordt aanbevolen, maar is 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 doorlopend .

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 moet u de start bestandsnaam van het laatste back-upbestand opgeven. 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 LRS afzonderlijk worden gestart voor elke database en verwijzen naar het volledige URI-pad van de Azure Blob Storage-container en de afzonderlijke databasemap.

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 -LastBackupName parameter. 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"

LRS starten in continue modus

Zorg ervoor dat u de eerste 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"

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 geslaagd of mislukt voordat ze de taak starten.

Tijdens deze wachttijd retourneert de opdracht het besturingselement niet naar de opdrachtprompt. 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. Voorbeeld:

$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 powerShell-documentatie voor het starten van taken voor PowerShell 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. Details van herstel van beheerde database controleren - Ophalen voor een voorbeelduitvoer.

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

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

Gebruik de volgende opdracht om de migratievoortgang via de Azure CLI te controleren:

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

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 de herstelvoortgang op uw beheerde exemplaar en zorg ervoor dat de laatste back-up van de logboekstaart is hersteld.

Wanneer de laatste back-up van logboekstaart is hersteld op uw beheerde exemplaar, start u de handmatige cutover 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"

LRS-problemen oplossen

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

  • Voor PowerShell: get-azsqlinstancedatabaselogreplay
  • Voor de Azure CLI: az_sql_midb_log_replay_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 alleen verleend voor het SAS-token Lezen en Lijst?
  • Hebt u het SAS-token voor LRS gekopieerd na het vraagteken (?), met inhoud die er als volgt sv=2020-02-10...uitziet? 
  • 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