Eseguire la migrazione di database da SQL Server usando il servizio di riproduzione log - Istanza gestita di SQL di Azure

Applica a:Istanza gestita di SQL di Azure

Questo articolo illustra come eseguire la migrazione di database SQL Server a Istanza gestita di SQL di Azure usando Log Replay Service (LRS). LRS è un servizio cloud gratuito per le migrazioni di Istanza gestita di SQL di Azure, basato sulla tecnologia di log shipping di SQL Server. Imparare il processo completo dai prerequisiti al cutover, incluse le procedure consigliate per una migrazione del database di successo.

Sono supportate le seguenti fonti:

• SQL Server su macchine virtuali
• Amazon EC2 (Elastic Compute Cloud)
• Amazon RDS (Relational Database Service) per SQL Server
• Google Compute Engine
• Cloud SQL per SQL Server - GCP (Google Cloud Platform)

Prerequisiti

Prima di iniziare, prendere in considerazione i requisiti in questa sezione sia per l'istanza di SQL Server che per Azure. Esaminare attentamente le sezioni limitazioni e procedure consigliate per garantire una migrazione corretta.

SQL Server

Assicurarsi di soddisfare i requisiti seguenti per SQL Server:

• SQL Server versioni da 2008 a 2022.
• Il database SQL Server utilizza il modello di recupero completo (obbligatorio).
• Backup completo dei database (uno o più file).
• Backup differenziale (uno o più file).
• Backup del log (non suddiviso per file del log delle transazioni).
• Per le versioni di SQL Server dal 2008 al 2016, eseguire backup localmente e caricare manualmente nell'account Archiviazione BLOB di Azure.
• Per SQL Server 2016 e versioni successive, è possibile prendere direttamente il backup all'account Archiviazione BLOB di Azure.
• CHECKSUM Anche se l'abilitazione per i backup non è necessaria, è consigliabile evitare involontariamente la migrazione di un database danneggiato e per operazioni di ripristino più veloci.
• Qualsiasi versione di Windows Server è supportata in base al supporto delle versioni SQL Server.
• Per SQL Server 2019 e versioni successive, è necessario abilitare il ripristino accelerato del database, con l'archivio delle versioni persistente impostato su PRIMARY. Per ulteriori informazioni, vedere Problemi noti dopo la migrazione a Istanza gestita di SQL in questo articolo.
• Per usare Service Broker in un database migrato a Istanza gestita di SQL di Azure, è necessario abilitare Service Broker nel database di origine prima della migrazione. Per ulteriori informazioni, vedere problemi conosciuti dopo la migrazione a Istanza gestita di SQL in questo articolo.

Azure

Assicurarsi di soddisfare i requisiti seguenti per Azure:

• PowerShell Az.SQL modulo versione 4.0.0 o successiva (installato o accessibile tramite Azure Cloud Shell).
• interfaccia della riga di comando di Azure versione 2.42.0 o successiva (installata).
• Il contenitore di Archiviazione BLOB di Azure di cui è stato effettuato il provisioning.
• Token di sicurezza SAS (firma di accesso condiviso) con autorizzazioni Read e List generato per un contenitore di gestione rete virtuale di Azure o un'identità gestita in grado di accedere al contenitore. La concessione di più autorizzazioni rispetto a Read e List causerà il fallimento di LRS.
• Inserire i file di backup per un singolo database all'interno di una cartella separata in un account di archiviazione usando una struttura di file flat (obbligatoria). L'inserimento di cartelle nelle cartelle di database non è supportato.

autorizzazioni Azure per il controllo degli accessi in base al ruolo

L'esecuzione di LRS tramite i client forniti richiede uno dei seguenti ruoli di controllo degli accessi basato sui ruoli di Azure (RBAC):

• ruolo Istanza gestita di SQL collaboratore
• Ruolo con l'autorizzazione seguente: Microsoft.Sql/managedInstances/databases/*

Procedure consigliate

Quando si utilizza LRS, prendere in considerazione le seguenti procedure consigliate:

• Suddividere i backup completi e differenziali in più file, anziché usare un singolo file.
• Abilitare la compressione dei backup per favorire la velocità di trasferimento in rete.
• Usare Cloud Shell per eseguire script di PowerShell o CLI, perché verrà sempre aggiornato per utilizzare i cmdlet più recenti rilasciati.
• Configurare una finestra di manutenzione in modo che gli aggiornamenti di sistema vengano pianificati in un giorno e un'ora specifici al di fuori della finestra di migrazione per evitare ritardi o interruzioni della migrazione.
• Pianificare di completare un unico processo di migrazione a storage a ridondanza locale entro un massimo di 30 giorni. Alla scadenza di questo periodo di tempo, il lavoro LRS viene annullato automaticamente.
• Per evitare involontariamente la migrazione di un database danneggiato e per un ripristino più rapido del database, abilitare CHECKSUM quando si eseguono i backup. Sebbene Istanza gestita di SQL esegua un controllo di integrità di base sui backup senza CHECKSUM, l'intercettazione di tutte le forme di danneggiamento non è garantita. L'esecuzione di backup con CHECKSUM è l'unico modo per garantire che il backup ripristinato in Istanza gestita di SQL non sia danneggiato. Il controllo di integrità di base sui backup senza CHECKSUM aumenta il tempo necessario per ripristinare un database.
• Quando si esegue la migrazione al livello di servizio Business Critical , tenere conto di un ritardo prolungato nella disponibilità del database dopo il cutover, mentre il seeding dei database viene eseguito nelle repliche secondarie. Per i database di grandi dimensioni con requisiti di tempo di inattività minimi, è consigliabile eseguire prima la migrazione al livello di servizio Utilizzo generico e quindi eseguire l'aggiornamento al livello di servizio Business Critical oppure usare il collegamento Istanza gestita per eseguire la migrazione dei dati.
• Il caricamento di migliaia di file di database da ripristinare può causare tempi di migrazione eccessivi e persino errori. Consolidare i database in un minor numero di file per velocizzare il processo di migrazione e garantirne il successo.
• Per ridurre al minimo il tempo di cutover e ridurre il rischio di errore, assicurarsi che l'ultimo backup sia il più piccolo possibile.

Configurare una finestra di manutenzione

Gli aggiornamenti di sistema per Istanza gestita di SQL hanno la precedenza sulle migrazioni di database in corso.

La migrazione è interessata in modo diverso in base al livello di servizio:

• Nel livello di servizio utilizzo generale, tutte le migrazioni LRS in sospeso vengono sospese e riprese solo dopo che l'aggiornamento è stato applicato. Questo comportamento del sistema potrebbe prolungare il tempo di migrazione, soprattutto per database di grandi dimensioni.
• Nel livello di servizio Business Critical, tutte le migrazioni con ridondanza locale in sospeso vengono annullate e riavviate automaticamente dopo l'applicazione dell'aggiornamento. Questo comportamento del sistema potrebbe prolungare il tempo di migrazione, soprattutto per database di grandi dimensioni.

Per ottenere un tempo prevedibile per le migrazioni di database, è consigliabile configurare una finestra di manutenzione per pianificare gli aggiornamenti di sistema per un giorno e un'ora specifici ed eseguire e completare i processi di migrazione all'esterno dell'intervallo di tempo di manutenzione designato. Ad esempio, per una migrazione che inizia il lunedì, configurare la finestra di manutenzione personalizzata domenica per consentire il massimo tempo per completare la migrazione.

La configurazione di una finestra di manutenzione non è necessaria, ma è altamente consigliata per i database di grandi dimensioni.

Eseguire la migrazione di più database

Se si esegue la migrazione di più database usando lo stesso contenitore Archiviazione BLOB di Azure, è necessario inserire i file di backup per database diversi in cartelle separate all'interno del contenitore. Tutti i file di backup per un database singolo devono essere inseriti in una struttura di file flat all'interno di una cartella di database e le cartelle non possono essere annidate. L'inserimento di cartelle nelle cartelle di database non è supportato.

Ecco un esempio di struttura di cartelle all'interno di un contenitore Archiviazione BLOB di Azure, una struttura necessaria per eseguire la migrazione di più database usando l'archiviazione con ridondanza locale.

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

Creare un account di archiviazione

Si usa un account Archiviazione BLOB di Azure come risorsa di archiviazione intermedia per i file di backup tra l'istanza di SQL Server e la distribuzione Istanza gestita di SQL. Per creare un nuovo account di archiviazione e un contenitore BLOB all'interno dell'account di archiviazione:

1. Creare un account di archiviazione.
2. Crea un contenitore BLOB nell'account di archiviazione.

Configurare l'archiviazione di Azure dietro un firewall

L'uso dell'archiviazione BLOB di Azure protetta dietro un firewall è supportato, ma richiede una configurazione aggiuntiva. Per abilitare l'accesso in lettura/scrittura a Archiviazione di Azure con Firewall di Azure attivato, è necessario aggiungere la subnet dell'istanza gestita di SQL alle regole del firewall della rete virtuale per l'account di archiviazione usando la delega della subnet MI e l'endpoint del servizio di archiviazione. L'account di archiviazione e l'istanza gestita devono trovarsi nella stessa area o in due aree abbinate.

Se l'archiviazione Azure si trova dietro un firewall, è possibile che venga visualizzato il messaggio seguente nel log degli errori dell'istanza gestita di SQL:

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

Viene generata un’email che informa che il controllo per l'istanza gestita di SQL non riesce a scrivere log di controllo nell'account di archiviazione. Se viene visualizzato questo errore o si riceve questo messaggio di posta elettronica, seguire la procedura descritta in questa sezione per configurare il firewall.

Per configurare il firewall, effettuare le operazioni seguenti:

1. Passare all'istanza gestita di SQL nel portale Azure e selezionare la subnet per aprire la pagina Subnets.

   

2. Nella pagina Subnet selezionare il nome della subnet per aprire la pagina di configurazione della subnet.

   

3. Sotto Subnet delegation, scegliere Microsoft.Sql/managedInstances dal menu a discesa Delegare subnet a un servizio. Attendere circa un'ora affinché le autorizzazioni si propagano e poi, sotto Endpoint dei servizi, scegliere Microsoft.Storage dall'elenco a discesa Servizi.

   

4. Passare quindi all'account di archiviazione nel portale di Azure, selezionare Networking in Security + networking e quindi scegliere la scheda Firewalls e reti virtuali.

5. Nella scheda Firewall e reti virtuali per l'account di archiviazione scegliere +Aggiungi rete virtuale esistente per aprire la pagina Aggiungi reti.

   

6. Selezionare la sottoscrizione appropriata, la rete virtuale e la subnet dell'istanza gestita dai menu a discesa e quindi selezionare Aggiungi per aggiungere la rete virtuale dell'istanza gestita di SQL all'account di archiviazione.

Eseguire l'autenticazione all'account gestione rete virtuale di Azure

Usare un token SAS o un'identità gestita per accedere all'account Archiviazione BLOB di Azure.

Convalidare l'accesso all'archiviazione dell'istanza gestita

Verificare che l'istanza gestita possa accedere all'account gestione rete virtuale di Azure.

Caricare prima di tutto qualsiasi backup del database, ad esempio full_0_0.bak, nel contenitore Archiviazione BLOB di Azure.

Connettersi quindi all'istanza gestita ed eseguire una query di test di esempio per determinare se l'istanza gestita è in grado di accedere al backup nel contenitore.

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

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

Caricare i backup nell'account gestione rete virtuale di Azure

Quando il contenitore BLOB è pronto e si è verificato che l'istanza gestita può accedere al contenitore, è possibile iniziare a caricare i backup nell'account gestione rete virtuale di Azure. È possibile:

• Copiare i backup nell'account gestione rete virtuale di Azure.
• Eseguire i backup da SQL Server direttamente all'account gestione rete virtuale di Azure usando il comando BACKUP TO URL, se l'ambiente lo consente (a partire da SQL Server versioni 2012 SP1 CU2 e SQL Server 2014).

Copiare i backup esistenti nell'account gestione rete virtuale di Azure

Se si usa una versione precedente di SQL Server o se l'ambiente non supporta il backup direttamente in un URL, eseguire i backup nell'istanza di SQL Server come si farebbe normalmente e quindi copiarli nell'account gestione rete virtuale di Azure.

Eseguire backup in un'istanza di SQL Server

Imposta i database che vuoi migrare al modello di recupero completo per consentire i backup del log.

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

Per eseguire manualmente backup completi, differenziali e del log del database nell'archiviazione locale, usare gli script T-SQL di esempio seguenti. CHECKSUM non è necessario, ma è consigliabile impedire la migrazione di un database danneggiato e per tempi di ripristino più rapidi.

Nell'esempio seguente viene eseguito un backup completo del database nel disco locale:

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

L'esempio seguente esegue un backup differenziale sul disco locale:

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

Nell'esempio seguente viene eseguito un backup del log delle transazioni nel disco locale:

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

Copiare i backup nell'account gestione rete virtuale di Azure

Dopo che i backup sono pronti e si vuole avviare la migrazione dei database a un'istanza gestita di Azure tramite LRS, è possibile usare gli approcci seguenti per copiare i backup esistenti nell'account di Archiviazione Blob:

• Scaricare e installare AzCopy.
• Scaricare e installare Azure Storage Explorer.
• Usare Storage Explorer nel portale di Azure.

Eseguire i backup direttamente nell'account gestione rete virtuale di Azure

Se si usa una versione supportata di SQL Server (a partire da SQL Server 2012 SP1 CU2 e SQL Server 2014) e i criteri aziendali e di rete lo consentono, è possibile eseguire backup da SQL Server direttamente all'account gestione rete virtuale di Azure usando il SQL Server nativo opzione BACKUP TO URL. Se è possibile usare BACKUP TO URL, non è necessario eseguire backup nell'archiviazione locale e caricarli nell'account gestione rete virtuale di Azure.

Quando si eseguono backup nativi direttamente nell'account gestione rete virtuale di Azure, è necessario eseguire l'autenticazione nell'account di archiviazione.

Usare il comando seguente per creare una credenziale che importi il SAS token nell'istanza di SQL Server.

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

Per istruzioni dettagliate sull'uso dei token di firma di accesso condiviso, vedere l'esercitazione Usare Archiviazione BLOB di Azure con SQL Server.

Dopo aver creato le credenziali per autenticare l'istanza di SQL Server con gestione rete virtuale di Azure, è possibile usare il comando BACKUP TO URL per eseguire i backup direttamente nell'account di archiviazione. CHECKSUM è consigliato, ma non obbligatorio.

Il seguente esempio esegue un backup completo del database su un 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

Nell'esempio seguente viene eseguito un backup differenziale del database in un 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

Nell'esempio seguente viene eseguito un backup del log delle transazioni in un 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;

Accedere a Azure e selezionare una sottoscrizione

Usare il cmdlet di PowerShell seguente per accedere a Azure:

Login-AzAccount

Selezionare la sottoscrizione in cui risiede l'istanza gestita usando il cmdlet di PowerShell seguente:

Select-AzSubscription -SubscriptionId <subscription ID>

Avviare la migrazione

Iniziare la migrazione avviando LRS. È possibile avviare il servizio in modalità di completamento automatico o continua.

Quando si usa la modalità di completamento automatico, la migrazione termina automaticamente quando l'ultimo dei file di backup specificati è stato ripristinato. Questa opzione richiede che l'intera catena di backup sia disponibile in anticipo e caricata nell'account gestione rete virtuale di Azure. Non consente l'aggiunta di nuovi file di backup durante la migrazione. Questa opzione richiede il comando start per specificare il nome file dell'ultimo file di backup. Consigliamo questa modalità per i carichi di lavoro passivi per i quali non è necessario il recupero dei dati.

Quando si usa la modalità continua, il servizio analizza continuamente la cartella Archiviazione BLOB di Azure e ripristina tutti i nuovi file di backup aggiunti durante la migrazione. La migrazione viene completata solo dopo l'arrivo della richiesta di passaggio manuale. È necessario utilizzare la migrazione in modalità continua quando non si dispone dell'intera catena di backup in anticipo e quando si prevede di aggiungere nuovi file di backup mentre la migrazione è in corso. Questa modalità è consigliata per i carichi di lavoro attivi per i quali è necessario il recupero dei dati.

Pianificare di completare un unico processo di migrazione a storage a ridondanza locale entro un massimo di 30 giorni. Al termine di questo intervallo di tempo, il lavoro LRS viene annullato automaticamente.

Avvia LRS in modalità completamento automatico

Assicurarsi che l'intera catena di backup sia stata caricata nell'account Archiviazione BLOB di Azure. Questa opzione non consente l'aggiunta di nuovi file di backup mentre è in corso la migrazione.

Per avviare LRS in modalità di completamento automatico, usare comandi PowerShell o interfaccia della riga di comando di Azure. Specificare il nome del file di backup usando il parametro -LastBackupName. Al termine del ripristino dell'ultimo file di backup specificato, il servizio avvia automaticamente un cutover.

Ripristina il database dall'account di archiviazione attraverso il token SAS o un'identità gestita.

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"

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"

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"

Avvia LRS in modalità continua

Assicurarsi di aver caricato la catena di backup iniziale nell'account Archiviazione BLOB di Azure.

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"

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"

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

Creare uno script per il processo di migrazione

PowerShell e i client interfaccia della riga di comando di Azure che avviano LRS in modalità continua sono sincroni. In questa modalità, PowerShell e l'interfaccia della riga di comando di Azure attendono che la risposta dell'API segnali l'esito positivo o negativo prima di avviare il lavoro.

Durante questa attesa, il comando non restituisce il controllo al prompt dei comandi. Se stai impostando l'esperienza di migrazione e hai bisogno che il comando di avvio LRS restituisca immediatamente il controllo per proseguire con il resto dello script, puoi eseguire PowerShell come processo in background con lo switch -AsJob. Ad esempio:

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

Quando si avvia un processo in background, un oggetto processo viene immediatamente restituito, anche se il completamento del processo richiede un tempo prolungato. Puoi continuare a lavorare nella sessione senza interruzioni mentre il processo è in esecuzione. Per informazioni dettagliate sull'esecuzione di PowerShell come processo in background, vedere la documentazione Processo di avvio di PowerShell.

Analogamente, per avviare un comando interfaccia della riga di comando di Azure in Linux come processo in background, usare il simbolo & () alla fine del comando di avvio LRS.

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

Monitorare il progresso della migrazione

Az.SQL 4.0.0 e versioni successive fornisce un report dettagliato sullo stato di avanzamento. Esamina Dettagli ripristino del database gestito - Get per vedere un esempio di output.

Per monitorare lo stato di avanzamento della migrazione in corso tramite PowerShell, usare il comando seguente:

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

Per monitorare lo stato di avanzamento della migrazione in corso attraverso il interfaccia della riga di comando di Azure, usare il comando seguente:

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

Per tenere traccia di altri dettagli su una richiesta non riuscita, usare il comando di PowerShell Get-AzSqlInstanceOperation o usare interfaccia della riga di comando di Azure comando az sql mi op show.

Arrestare la migrazione (facoltativo)

Se è necessario arrestare la migrazione, usare PowerShell o il interfaccia della riga di comando di Azure. L'arresto della migrazione elimina il database di ripristino nell'istanza gestita, quindi la ripresa della migrazione non sarà possibile.

Per arrestare il processo di migrazione tramite PowerShell, usare il comando seguente:

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

Per arrestare il processo di migrazione tramite il interfaccia della riga di comando di Azure, usare il comando seguente:

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

Completare la migrazione (modalità continua)

Se si avvia LRS in modalità continua, assicurarsi che l'applicazione e il carico di lavoro di SQL Server siano stati arrestati per impedire la generazione di nuovi file di backup. Assicurarsi che l'ultimo backup dell'istanza di SQL Server sia stato caricato nell'account Archiviazione BLOB di Azure. Monitorare lo stato di avanzamento del ripristino nell'istanza gestita e verificare che l'ultimo backup della parte finale del log sia stato ripristinato.

Quando l'ultimo backup della parte finale del log è stato ripristinato nell'istanza gestita, avvia il cutover manuale per completare la migrazione. Al termine del cutover, il database diventa disponibile per l'accesso in lettura e scrittura nell'istanza gestita.

Per completare il processo di migrazione in modalità continua tramite LRS usando PowerShell, utilizzare il comando seguente:

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

Per completare il processo di migrazione in modalità continua tramite LRS usando l'interfaccia a riga di comando di Azure (interfaccia della riga di comando di Azure), usare il comando seguente:

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

Limiti

Considerare le seguenti limitazioni quando si esegue la migrazione con LRS:

• Non è possibile usare i database che vengono ripristinati tramite LRS (archiviazione con ridondanza locale) fino al termine del processo di migrazione.
• Durante il processo di migrazione, i database di cui viene eseguita la migrazione non possono essere usati per l'accesso in sola lettura in Istanza gestita di SQL.
• Una volta terminata, la migrazione è definitiva e non può essere ripresa con backup differenziali aggiuntivi.
• Solo i file di database .bak, .log e .diff sono supportati da LRS. I file Dacpac e bacpac non sono supportati.
• È necessario configurare una finestra di manutenzione per pianificare gli aggiornamenti di sistema in un giorno e un'ora specifici. Pianificare l'esecuzione e completare le migrazioni all'esterno della finestra di manutenzione pianificata.
• Backup del database eseguiti senza CHECKSUM:
  • può potenzialmente eseguire la migrazione di database danneggiati.
  • il ripristino richiede più tempo rispetto ai backup del database con CHECKSUM abilitato.
• Il token della firma di accesso condiviso (SAS) usato dall'Archiviazione con ridondanza locale (LRS) deve essere generato per l'intero contenitore di Archiviazione BLOB di Azure e deve avere esclusivamente le autorizzazioni Read e List. Ad esempio, se si concedono le autorizzazioni Read, List e Write, LRS non si avvia a causa dell'autorizzazione aggiuntiva Write.
• L'uso di token di firma di accesso condiviso creati con autorizzazioni impostate tramite la definizione di politica di accesso memorizzata non è supportato. Seguire le istruzioni in questo articolo per specificare manualmente le autorizzazioni di Lettura e Lista per il token SAS.
• È necessario inserire i file di backup per database diversi in cartelle separate nell'account gestione rete virtuale di Azure in una struttura di file flat. L'inserimento di cartelle nelle cartelle di database non è supportato.
• Se si usa la modalità di completamento automatico, l'intera catena di backup deve essere disponibile in anticipo nell'account gestione rete virtuale di Azure. Non è possibile aggiungere nuovi file di backup in modalità completamento automatico. Usare la modalità continua se è necessario aggiungere nuovi file di backup durante la migrazione.
• È necessario avviare separatamente LRS per ogni database che punta al percorso URI completo, il quale contiene una singola cartella del database.
• Il percorso dell'URI di backup, il nome del contenitore o i nomi delle cartelle non possono contenere backup o Backup perché si tratta di parole chiave riservate.
• Quando si avviano più ripristini di Log Replay in parallelo e la destinazione è lo stesso contenitore di archiviazione, assicurarsi che venga fornito lo stesso token di firma di accesso condiviso valido per ogni operazione di ripristino.
• LRS supporta la migrazione del numero totale di database a una singola istanza fino ai limiti delle risorse del tier di servizio. Ad esempio, è possibile ripristinare fino a 100 database totali nel livello di servizio Utilizzo generico e fino a 500 database totali nel livello di servizio Utilizzo generico di nuova generazione .
• LRS supporta 100 ripristini simultanei del database in una singola istanza e 150 ripristini simultanei per tutte le istanze in una singola sottoscrizione. Ad esempio, è possibile ripristinare 100 database in parallelo a due istanze nella stessa sottoscrizione contemporaneamente oppure 50 database in tre batch simultanei in parallelo a quattro istanze separate all'interno della stessa sottoscrizione.
• Un singolo lavoro LRS può essere eseguito per un massimo di 30 giorni, dopo il quale verrà annullato automaticamente.
• Anche se è possibile usare un account Archiviazione di Azure dietro un firewall, è necessaria una configurazione aggiuntiva e l'account di archiviazione e l'istanza gestita devono trovarsi nella stessa area o in due aree abbinate. Per altre informazioni, vedere Configurare il firewall.
• Il numero massimo di database che è possibile ripristinare in parallelo è 150 per sottoscrizione singola. In alcuni casi, è possibile aumentare questo limite aprendo un ticket di supporto.
• Il caricamento di migliaia di file di database da ripristinare può causare tempi di migrazione eccessivi e persino errori. Consolidare i database in un minor numero di file per velocizzare il processo di migrazione e garantirne il successo.
• Esistono due scenari, all'inizio e alla fine del processo di migrazione, in cui viene interrotta una migrazione se si verifica un failover e il processo di migrazione deve essere riavviato manualmente dall'inizio quando il database viene eliminato da Istanza gestita di SQL:
  • Se si verifica un failover quando il primo backup completo del database è in fase di ripristino in Istanza gestita di SQL all'avvio del processo di migrazione, il processo di migrazione deve essere riavviato manualmente dall'inizio.
  • Se si verifica un failover dopo l'inizio del cutover della migrazione, il processo di migrazione deve essere riavviato manualmente dall'inizio. Assicurarsi che l'ultimo file di backup sia il più piccolo possibile per ridurre al minimo il tempo di cutover e ridurre il rischio di un failover durante il processo di cutover.
• Se ripristino accelerato del database è disabilitato sul SQL Server di origine 2019 e versioni successive, non è più possibile abilitarlo dopo la migrazione ad Istanza gestita di SQL di Azure. Inoltre, se l'archivio versioni permanenti (PVS) non è impostato su PRIMARY, è possibile riscontrare problemi con le operazioni di ripristino nell'istanza gestita di SQL di destinazione.
• Se Service Broker è disabilitato nell'istanza di SQL Server di origine, non è possibile usare Service Broker nell'istanza gestita di SQL di destinazione dopo la migrazione.

Limitazioni durante la migrazione al livello di servizio Business Critical

Quando si esegue la migrazione a un Istanza gestita di SQL nel livello di servizio Business Critical considerare le limitazioni seguenti:

• Quando si esegue la migrazione di database di grandi dimensioni, potrebbe verificarsi un notevole tempo di inattività perché i database non sono disponibili dopo il cutover, mentre il seeding dei database viene eseguito nelle repliche secondarie del livello di servizio Business Critical . Le soluzioni alternative sono elencate nella sezione cutover più lunga.
• La migrazione viene riavviata automaticamente dall'inizio se la migrazione viene interrotta da un failover non pianificato, da un aggiornamento del sistema o da una patch di sicurezza, rendendo difficile pianificare una migrazione prevedibile senza sorprese dell'ultimo minuto.

Cutover più lungo nel livello di servizio Business Critical

Se si sta effettuando una migrazione verso un'istanza SQL gestita nel livello di servizio Business Critical, considerare il ritardo nel portare online i database sulla replica primaria mentre vengono inizializzati nelle repliche secondarie. Ciò vale soprattutto per i database di dimensioni maggiori.

La migrazione a un Istanza gestita di SQL nel livello di servizio Business Critical richiede più tempo rispetto al livello di servizio per utilizzo generico. Al termine del cutover ad Azure, i database non sono disponibili fino a quando non sono stati replicati dalla replica primaria alle tre repliche secondarie, cosa che può richiedere un tempo prolungato a seconda delle dimensioni del database. Maggiore è il database, più tempo richiede il seeding alle repliche secondarie, fino a diverse ore, potenzialmente.

Se è importante che i database siano disponibili non appena viene completato il cutover, prendere in considerazione le soluzioni alternative seguenti:

• Eseguire prima la migrazione al livello di servizio Generico e quindi eseguire l'aggiornamento al livello di servizio Business Critical. L'aggiornamento del livello di servizio è un'operazione online che mantiene online i database fino a quando non viene eseguito un breve failover come passaggio finale dell'operazione di aggiornamento.
• Usare il collegamento Istanza gestita per una migrazione online a un'istanza Business Critical senza dover attendere che i database siano disponibili dopo il cutover.

Problemi noti dopo la migrazione a Istanza gestita di SQL

Considerare i problemi noti seguenti dopo la migrazione a Istanza gestita di SQL di Azure:

Errori dell'operazione di ripristino dopo la migrazione a Istanza gestita di SQL

Se si esegue la migrazione di un database ad Istanza gestita di SQL di Azure da SQL Server 2019 e versioni successive con ripristino accelerato del database abilitato, ma configurato con l'archivio delle versioni permanente impostato su un valore diverso dal gruppo di file PRIMARY, potrebbero verificarsi errori durante le operazioni di ripristino nell'istanza gestita SQL di destinazione.

Per risolvere questo problema, assicurarsi di impostare l'archivio delle versioni persistent version store (PVS) su PRIMARY nel database di SQL Server di origine prima di eseguirne la migrazione a Istanza gestita di SQL. Se è già stata eseguita la migrazione del database senza impostare pvS su PRIMARY, è possibile impostarla nel database di origine SQL Server e quindi eseguire nuovamente la migrazione del database a Istanza gestita di SQL.

Impossibile usare il ripristino accelerato del database dopo la migrazione a Istanza gestita di SQL

A partire da SQL Server 2019, se si esegue la migrazione di un database su Istanza gestita di SQL di Azure e il database di origine ha il ripristino di database accelerato disabilitato, non è possibile usare il ripristino di database accelerato nell'istanza gestita di destinazione.

Per risolvere questo problema, assicurarsi di abilitare il ripristino accelerato del database nel database di SQL Server di origine prima di eseguirne la migrazione a Istanza gestita di SQL. Se è già stata eseguita la migrazione del database senza abilitare il ripristino accelerato del database, è possibile abilitarlo nel database di SQL Server di origine e quindi eseguire nuovamente la migrazione del database all'istanza gestita di SQL.

SQL Server 2017 e versioni precedenti non supportano il ripristino accelerato del database, quindi questo problema non si applica ai database migrati da tali versioni di SQL Server.

Impossibile usare Service Broker dopo la migrazione a Istanza gestita di SQL

Se si esegue la migrazione di un database a Istanza gestita di SQL di Azure e Service Broker è disabilitato nel database di origine, non è possibile usare Service Broker nell'istanza gestita di SQL di destinazione.

Per risolvere questo problema, assicurarsi di abilitare Service Broker nel database di origine SQL Server prima di eseguirne la migrazione a Istanza gestita di SQL. Se è già stata eseguita la migrazione del database senza abilitare Service Broker, è possibile abilitarlo nel database di SQL Server di origine e quindi eseguire nuovamente la migrazione del database a Istanza gestita di SQL.

Risolvere i problemi relativi a LRS

Dopo aver avviato LRS, usare uno dei cmdlet di monitoraggio seguenti per visualizzare lo stato dell'operazione in corso:

• Per PowerShell: get-azsqlinstancedatabaselogreplay
• Per il interfaccia della riga di comando di Azure: az_sql_midb_log_replay_show

Per esaminare i dettagli relativi a un'operazione non riuscita:

• Per PowerShell: Get-AzSqlInstanceOperation
• Per interfaccia della riga di comando di Azure: az sql mi op show

Se LRS non viene avviato dopo un po' di tempo e si verifica un errore, verificare la presenza dei problemi più comuni:

• Un database esistente nell'istanza gestita ha lo stesso nome di quello di cui si sta tentando di eseguire la migrazione dall'istanza di SQL Server? Risolvere il conflitto rinominando uno dei database.
• Le autorizzazioni concesse per il token SAS sono solo di lettura e di elenco? La concessione di più autorizzazioni rispetto a Read e List causerà il fallimento di LRS.
• Hai copiato il token SAS per LRS dopo il punto interrogativo (?), con contenuto simile a sv=2020-02-10...?
• Il tempo di validità del token di firma di accesso condiviso è appropriato per l'intervallo di tempo di avvio e completamento della migrazione? Potrebbero verificarsi mancate corrispondenze a causa dei diversi fusi orari usati per la distribuzione dell'istanza gestita SQL e il token SAS. Provare a rigenerare il token SAS ed estendere la validità del token per l'intervallo di tempo che precede e segue la data corrente.
• Quando si avviano più ripristini di riproduzione log in parallelo e questi sono destinati allo stesso contenitore di archiviazione, assicurarsi che per ogni operazione di ripristino venga fornito lo stesso token SAS valido.
• Il nome del database, il nome del gruppo di risorse e il nome dell'istanza gestita sono scritti correttamente?
• Se hai avviato LRS in modalità completamento automatico, è stato specificato un nome file valido per l'ultimo file di backup?
• Il percorso dell'URI di backup contiene parole chiave backup o backups? Rinominare il contenitore o le cartelle che usano backup o backups perché si tratta di parole chiave riservate.

Contenuto correlato

• Panoramica del servizio di replica dei log con Istanza gestita di SQL di Azure
• Panoramica del collegamento Istanza gestita
• Migrate da SQL Server a Istanza gestita di SQL di Azure
• differenze T-SQL tra SQL Server e Istanza gestita di SQL di Azure
• Migliori pratiche per valutare costi e dimensioni dei carichi di lavoro migrati su Azure.
• Confronta LRS con il collegamento a Istanza gestita