Eseguire la migrazione di database da SQL Server con Log Replay Service - Istanza gestita di SQL di Azure

  • Articolo

Si applica a:Istanza gestita di SQL di Azure

Questo articolo illustra come eseguire la migrazione dei database a Istanza gestita di SQL di Azure usando il Log Replay Service (LRS). L’archiviazione con ridondanza locale è un servizio cloud gratuito disponibile per l'Istanza gestita di SQL di Azure basato sulla tecnologia di log shipping di SQL Server.

Sono supportate le origini seguenti:

  • SQL Server in 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, considerare i requisiti seguenti per l'istanza di SQL Server e Azure.

SQL Server

Assicurarsi di soddisfare i requisiti seguenti per il server di SQL:

  • Versioni SQL Server da 2008 a 2022.
  • Il database di SQL Server usa il modello di recupero con registrazione completa (obbligatorio).
  • Backup completo dei database (uno o più file).
  • Backup differenziale (uno o più file).
  • Backup del log (non suddiviso per un file di log delle transazioni).
  • Per le versioni SQL Server da 2008 a 2016, eseguire un backup in locale e caricarlo manualmente nell'account Archiviazione BLOB di Azure.
  • Per SQL Server 2016 e versioni successive, è possibile eseguire il backup direttamente nell'account Archiviazione BLOB di Azure.

Anche se non è necessaria l'abilitazione di CHECKSUM per i backup, è consigliabile eseguire operazioni di ripristino più veloci.

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).
  • Versione 2.42.0 o successive dell’Interfaccia della riga di comando di Azure (installata).
  • Contenitore di Archiviazione BLOB di Azure di cui è stato effettuato il provisioning.
  • Token di sicurezza della firma di accesso condiviso con autorizzazioni di lettura ed elenco generate per il contenitore archiviazione BLOB o un'identità gestita che può accedere al contenitore.
  • 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'annidamento delle cartelle all'interno delle cartelle di database non è supportato.

Autorizzazioni del Controllo degli accessi in base al ruolo di Azure

L'esecuzione dell’archiviazione con ridondanza locale tramite i client forniti richiede uno dei seguenti ruoli di Controllo degli accessi in base al ruolo di Azure:

Procedure consigliate

Prendere in considerazione le procedure consigliate seguenti quando si usa l’archiviazione con ridondanza locale:

  • Eseguire Data Migration Assistant per verificare che i database siano pronti per la migrazione a Istanza gestita di SQL.
  • 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 usare i cmdlet rilasciati più recenti.
  • Configurare una finestra di manutenzione per consentire la pianificazione degli aggiornamenti di sistema in un giorno e un'ora specifici. Questa configurazione consente di ottenere un tempo più prevedibile per le migrazioni di database, perché gli aggiornamenti del sistema possono interrompere le migrazioni in corso.
  • Pianificare il completamento di un singolo processo di migrazione con ridondanza locale entro un massimo di 30 giorni. Alla scadenza di questo intervallo di tempo, il processo di archiviazione con ridondanza locale viene annullato automaticamente.
  • Per un ripristino del database più rapido, abilitare CHECKSUM quando si eseguono i backup. Istanza gestita di SQL esegue un controllo di integrità sui backup senza CHECKSUM, che aumenta il tempo di ripristino.

Gli aggiornamenti di sistema in Istanza gestita di SQL avranno la precedenza sulle migrazioni di database in corso. Durante un aggiornamento di sistema in un'istanza, tutte le migrazioni con archiviazione con ridondanza locale in sospeso vengono sospese e riprese solo 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 delle migrazioni di database, è consigliabile configurare una finestra di manutenzione che consenta la pianificazione degli aggiornamenti di sistema in un giorno/ora specifici e di considerare l'esecuzione e il completamento dei processi di migrazione al di fuori del giorno/ora della finestra di manutenzione pianificata.

Importante

  • Non è possibile usare i database che vengono ripristinati tramite archiviazione con ridondanza locale fino al termine del processo di migrazione.
  • L'archiviazione con ridondanza locale non supporta l'accesso in sola lettura ai database durante la migrazione.
  • Una volta terminata, la migrazione è definitiva e non può essere ripresa con backup differenziali aggiuntivi.

Eseguire la migrazione di più database

Se si esegue la migrazione di più database usando lo stesso contenitore Archivio 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'annidamento delle cartelle all'interno delle 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. Creare un contenitore BLOB nell'account di archiviazione.

Configurare l'archiviazione di Azure dietro un firewall

L'uso dell'archiviazione BLOB di Azure protetto da 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 servizio Archiviazione. L'account di archiviazione e l'istanza gestita devono trovarsi nella stessa area o in due aree abbinate.

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

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 nel portale di Azure e selezionare la subnet per aprire la pagina Subnet.

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

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

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

  3. In Delega subnet scegliere Microsoft.Sql/managedInstances dal menu a discesa Delega subnet a un servizio. Attendere circa un'ora per la propagazione delle autorizzazioni e quindi, in Endpoint servizio, scegliere Microsoft.Storage dall'elenco a discesa Servizi.

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

  4. Passare quindi all'account di archiviazione nel portale di Azure, selezionare Rete in Sicurezza e rete e quindi scegliere la scheda Firewall 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.

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

  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.

Autenticare l'accesso all'account di archiviazione BLOB

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

Avviso

Non è possibile usare sia un token di firma di accesso condiviso che un'identità gestita in parallelo nello stesso account di archiviazione. È possibile usare o un token di firma di accesso condiviso o un'identità gestita, ma non entrambi.

Generare un token per l’autenticazione della firma di accesso condiviso per l’autenticazione dell’archiviazione BLOB per l'archiviazione con ridondanza locale

Accedere all'account Archiviazione BLOB di Azure usando un token di firma di accesso condiviso.

È possibile usare 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. Generare un token per l’autenticazione della firma per l’accesso condiviso all'archiviazione con ridondanza locale con autorizzazioni di sola lettura ed elenco. Il token consente all'archiviazione con ridondanza locale di accedere all'account di Archiviazione BLOB e usa i file di backup per ripristinarli nell'istanza gestita.

Per generare il token, seguire questi passaggi:

  1. Aprire Storage Explorer nel portale di Azure.

  2. Espandere contenitori BLOB.

  3. Fare clic con il pulsante destro del mouse sul contenitore BLOB e quindi selezionare Ottieni firma di accesso condiviso.

    Screenshot that shows selections for generating a SAS authentication token.

  4. Selezionare l'intervallo di tempo per la scadenza del token. Assicurarsi che il token sia valido durante la migrazione.

  5. Selezionare il fuso orario per il token: UTC o l'ora locale.

    Importante

    Il fuso orario del token e dell'istanza gestita potrebbero non corrispondere. Assicurarsi che il token di firma di accesso condiviso abbia la validità dell'ora appropriata, prendendo in considerazione i fusi orari. Per tenere conto delle differenze del fuso orario, impostare il valore FROM di validità ben prima dell'avvio della finestra di migrazione e il valore TO dopo il completamento della migrazione.

  6. Selezionare solamente le autorizzazioni Lettura ed Elenco.

    Importante

    Non selezionare altre autorizzazioni. In questo caso, l'archiviazione con ridondanza locale (LRS) non verrà avviata. Questo requisito di sicurezza è previsto dalla progettazione.

  7. Seleziona Crea.

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

L'autenticazione della firma di accesso condiviso viene generata con la validità dell'ora specificata. È necessaria la versione URI del token, come illustrato nello screenshot seguente:

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

Nota

L'uso di token di firma di accesso condiviso creati con le autorizzazioni impostate definendo un criterio di accesso archiviato non è attualmente supportato. Seguire le istruzioni riportate in questa procedura per specificare manualmente le autorizzazioni Read e List per il token di firma di accesso condiviso.

Copiare i parametri dal token di firma di accesso condiviso

Accedere all'account Archiviazione BLOB di Azure usando un token di firma di accesso condiviso o un'identità gestita.

Prima di usare il token di firma di accesso condiviso per avviare l'archiviazione con ridondanza locale, è necessario comprenderne la struttura. L'URI del token di firma di accesso condiviso generato è costituito da due parti, separate da un punto interrogativo (?), come illustrato in questo esempio:

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

La prima parte, a partire da https:// fino al punto interrogativo (?), viene usata per il parametro StorageContainerURI fornito come input per l'archiviazione con ridondanza locale. Fornisce informazioni sull'archiviazione con ridondanza locale sulla cartella in cui sono archiviati i file di backup del database.

La seconda parte, da dopo il punto interrogativo (?) fino alla fine della stringa, è il parametro StorageContainerSasToken. Questa parte è il token di autenticazione firmato effettivo, valido durante l'ora specificata. Questa parte non deve necessariamente iniziare con sp= come illustrato nell'esempio. Lo scenario potrebbe essere diverso.

Copiare i parametri come indicato di seguito:

  1. Copiare la prima parte del token, da https:// fino a al punto interrogativo (?), ma senza includerlo. Usarlo come parametro StorageContainerUri in PowerShell o nell'interfaccia della riga di comando di Azure quando si avvia l'archiviazione con ridondanza locale.

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

  2. Copiare la seconda parte del token, da dopo il punto interrogativo (?) fino alla fine della stringa. Usarlo come parametro StorageContainerSasToken in PowerShell o nell'interfaccia della riga di comando di Azure quando si avvia l'archiviazione con ridondanza locale.

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

Nota

Non includere il punto interrogativo (?) quando si copia una delle parti del token.

Convalidare l'accesso all'archiviazione dell'istanza gestita

Verificare che l'istanza gestita possa accedere all'account di Archiviazione BLOB.

Prima di tutto, caricare 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.

Se si usa un token di firma di accesso condiviso per eseguire l'autenticazione nell'account di archiviazione, sostituire <sastoken> con il token di firma di accesso condiviso ed eseguire la query seguente nell'istanza:

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'

Caricare i backup nell'account di archiviazione BLOB

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

  • Copiare i backup nell'account di Archiviazione BLOB.
  • Eseguire i backup da SQL Server direttamente all'account di archiviazione BLOB 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 di Archiviazione BLOB

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 di Archiviazione BLOB.

Eseguire il backup in un'istanza di SQL Server

Impostare i database di cui si vuole eseguire la migrazione al modello di recupero con registrazione completa 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 è obbligatorio, ma è consigliato.

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 di Archiviazione BLOB

Dopo che i backup sono pronti e si vuole avviare la migrazione dei database a un'istanza gestita usando l'archiviazione con ridondanza locale, è possibile usare gli approcci seguenti per copiare i backup esistenti nell'account di Archiviazione BLOB:

Nota

Per eseguire la migrazione di più database usando lo stesso contenitore di Archiviazione BLOB di Azure, inserire tutti i file di backup per un singolo database in una cartella separata all'interno del contenitore. Usare la struttura di file flat per ogni cartella di database. L'annidamento delle cartelle all'interno delle cartelle di database non è supportato.

Eseguire i backup direttamente nell'account di Archiviazione BLOB

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

Quando si eseguono backup nativi direttamente nell'account di Archiviazione BLOB, è necessario eseguire l'autenticazione nell'account di archiviazione.

Usare il comando seguente per creare credenziali che importano il token di firma di accesso condiviso 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 archiviazione BLOV, è possibile usare il comando BACKUP TO URL per eseguire i backup direttamente nell'account di archiviazione. CHECKSUM è consigliato, ma non obbligatorio.

L'esempio seguente viene eseguito un backup completo del database in 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 ad Azure e selezionare una sottoscrizione

Usare il seguente cmdlet di PowerShell per accedere ad 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

Avviare la migrazione avviando l'archiviazione con ridondanza locale. È 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 di Archiviazione BLOB. 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 la richiesta del cutover 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 il completamento di un singolo processo di migrazione con ridondanza locale entro un massimo di 30 giorni. Alla scadenza di questo periodo, il processo di archiviazione con ridondanza locale viene annullato automaticamente.

Nota

Quando si esegue la migrazione di più database, è necessario avviare l’archiviazione con ridondanza locale separatamente per ogni database che punta al percorso URI completo del contenitore di archiviazione BLOB di Azure e alla singola cartella del database.

Avviare l'archiviazione con ridondanza locale 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 l'archiviazione con ridondanza locale in modalità di completamento automatico, usare i comandi di PowerShell o dell'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.

Ripristinare il database dall'account di archiviazione usando il token di firma di accesso condiviso o un'identità gestita.

Importante

  • Assicurarsi che l'intera catena di backup sia stata caricata nell'account Archiviazione BLOB di Azure prima di avviare la migrazione in modalità di completamento automatico. Questa modalità non consente l'aggiunta di nuovi file di backup mentre è in corso la migrazione.
  • Assicurarsi di aver specificato correttamente l'ultimo file di backup e che non siano stati caricati altri file dopo di esso. Se il sistema rileva più file di backup oltre l'ultimo file di backup specificato, la migrazione avrà esito negativo.

L'esempio di PowerShell seguente avvia l'archiviazione con ridondanza locale in modalità di completamento automatico usando un token di firma di accesso condiviso:

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"

L'esempio seguente dell'interfaccia della riga di comando di Azure avvia l'archiviazione con ridondanza locale in modalità completamento automatico usando un token di firma di accesso condiviso:

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"

Avviare l'archiviazione con ridondanza locale in modalità continua

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

Importante

Dopo aver avviato l’archiviazione con ridondanza locale in modalità continua, sarà possibile aggiungere nuovi backup di log e differenziali all’account di archiviazione fino al cutover manuale. Dopo aver avviato il cutover manuale, non è possibile aggiungere o ripristinare altri file differenziali.

L'esempio di PowerShell seguente avvia l'archiviazione con ridondanza locale in modalità continua usando un token di firma di accesso condiviso:

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"

L'esempio seguente dell'interfaccia della riga di comando di Azure avvia l'archiviazione con ridondanza locale in modalità continua:

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"

Creare uno script per il processo di migrazione

I client PowerShell e dell'interfaccia della riga di comando di Azure che avviano l'archiviazione con ridondanza locale 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 processo.

Durante questa attesa, il comando non restituisce il controllo al prompt dei comandi. Se si esegue lo script dell'esperienza di migrazione ed è necessario il comando di avvio dell'archiviazione con ridondanza locale per restituire immediatamente il controllo per continuare con il resto dello script, è possibile 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, viene restituito immediatamente un oggetto processo, anche se il completamento del processo richiede molto tempo. È possibile continuare a lavorare nella sessione senza interruzioni durante l'esecuzione del processo. Per informazioni dettagliate sull'esecuzione di PowerShell come processo in background, vedere la documentazione Processo di avvio di PowerShell.

Analogamente, per avviare un comando dell'interfaccia della riga di comando di Azure in Linux come processo in background, usare la e commerciale (&) alla fine del comando di avvio dell'archiviazione con ridondanza locale:

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. Esaminare Dettagli ripristino del database gestito: Get un output di esempio.

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

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

Per monitorare lo stato di avanzamento della migrazione tramite l'interfaccia della riga di comando di Azure, usare il comando seguente:

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

Arrestare la migrazione (facoltativo)

Se è necessario arrestare la migrazione, usare PowerShell o l'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 l'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 l'archiviazione con ridondanza locale 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, avviare 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 con archiviazione con ridondanza locale tramite PowerShell, usare il comando seguente:

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

Per completare il processo di migrazione in modalità continua con ridondanza locale tramite l'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"

Risolvere i problemi relativi all’archiviazione con ridondanza locale

Dopo aver avviato l'archiviazione con ridondanza locale, usare uno dei cmdlet di monitoraggio seguenti per visualizzare lo stato dell'operazione:

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

Se l'archiviazione con ridondanza locale non viene avviata dopo un certo periodo di tempo e viene visualizzato 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 di firma di accesso condiviso sono di sola lettura ed elenco?
  • È stato copiato il token di firma di accesso condiviso per l'archiviazione con ridondanza locale dopo il punto interrogativo (?), con contenuto simile a sv=2020-02-10...? 
  • L'ora di validità del token di firma di accesso condiviso è appropriata per l'intervallo di tempo di avvio e completamento della migrazione? I fusi orari utilizzati per la distribuzione Istanza gestita di SQL e il token di firma di accesso condiviso potrebbero non corrispondere. Provare a rigenerare il token di firma di accesso condiviso ed estendere la validità del token dell'intervallo di tempo prima e dopo la data corrente.
  • Quando si avviano più ripristini di riproduzione log in parallelo destinati allo stesso contenitore di archiviazione, assicurarsi che venga fornito lo stesso token di firma di accesso condiviso valido per ogni operazione di ripristino.
  • Il nome del database, il nome del gruppo di risorse e il nome dell'istanza gestita sono scritti correttamente?
  • Se è stata avviata l'archiviazione con ridondanza locale 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.

Passaggi successivi