Condividi tramite

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 SQL

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. Esaminare attentamente le sezioni limitazioni e procedure consigliate per garantire una migrazione corretta.

Importante

  • Prima di eseguire la migrazione dei database al livello di servizio Business Critical , prendere in considerazione queste limitazioni, che non si applicano al livello di servizio Per utilizzo generico.
  • 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.

Prima di eseguire la migrazione dei database al livello di servizio Business Critical , prendere in considerazione queste limitazioni, che non si applicano al livello di servizio Per utilizzo generico.

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

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 Read e List autorizzazioni generate per il contenitore di archiviazione BLOB o un'identità gestita che può accedere al contenitore. La concessione di più autorizzazioni rispetto Read a e List causerà l'esito negativo dell'archiviazione con ridondanza locale.
  • 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 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 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 evitare involontariamente la migrazione di un database danneggiato e per un ripristino più rapido del database, abilitare CHECKSUM quando si eseguono i backup. Anche se Istanza gestita di SQL esegue 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 aumentare il tempo di ripristino di 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 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.

Configurare una finestra di manutenzione

Gli aggiornamenti di sistema in Istanza gestita di SQL avranno 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 generico, tutte le migrazioni 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.
  • 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 è consigliabile per database di grandi dimensioni.

Nota

Anche se una finestra di manutenzione controlla la prevedibilità degli aggiornamenti pianificati , non garantisce che i failover non pianificati o gli aggiornamenti delle patch di sicurezza non si verifichino. Un failover non pianificato o una patch di sicurezza (che ha la precedenza su tutti gli altri aggiornamenti) può comunque interrompere la migrazione.

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

    Screenshot della pagina di panoramica dell'Istanza gestita di SQL nel portale di Azure, con la subnet selezionata.

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

    Screenshot della pagina della subnet dell'Istanza gestita di SQL nel portale di Azure, con la subnet selezionata.

  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 della pagina di configurazione della subnet dell'Istanza gestita di SQL nel portale di Azure, con la subnet selezionata.

  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 della pagina della Rete dell'account di archiviazione nel portale di Azure, con l'opzione Aggiungi rete virtuale esistente selezionata.

  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 che mostra le selezioni per la generazione di un token di autenticazione della firma di accesso condiviso (SAS).

  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 che mostra le selezioni per la scadenza del token di firma di accesso condiviso, il fuso orario e le autorizzazioni, insieme al pulsante Crea.

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 che mostra un esempio della versione URI di un token di firma di accesso condiviso.

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:

URI di esempio per un token di firma di accesso condiviso generato per il servizio di riproduzione log.

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 che mostra dove copiare la prima parte del 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 che mostra dove copiare la seconda parte del 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 è 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 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, ogni database deve trovarsi nella propria cartella. L'archiviazione con ridondanza locale deve essere avviata separatamente per ogni database, che punta al percorso URI completo del contenitore Archiviazione BLOB di Azure e alla singola cartella del database. Le cartelle annidate all'interno delle cartelle di database non sono supportate.

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

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

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"

Limiti

Quando si esegue la migrazione con l'archiviazione con ridondanza locale, prendere in considerazione le limitazioni seguenti:

  • Non è possibile usare i database che vengono ripristinati tramite 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 dall’archiviazione con ridondanza locale. 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 di firma di accesso condiviso usato dall'archiviazione con ridondanza locale deve essere generato per l'intero contenitore Archiviazione BLOB di Azure e deve avere Read solo autorizzazioni e List . Ad esempio, se si concedono Readautorizzazioni , Liste, l'archiviazione Write con ridondanza locale non viene avviata a causa dell'autorizzazione aggiuntiva Write .
  • L'uso di token di firma di accesso condiviso creati con autorizzazioni impostate tramite la definizione di criteri di accesso archiviati non è supportato. Seguire le istruzioni in questo articolo per specificare manualmente le autorizzazioni Lettura ed Elenco per il token di firma di accesso condiviso.
  • Inserire i file di backup per i vari database in una cartella separata nell’account di Archiviazione BLOB di Azure in una struttura di file flat. L'annidamento delle cartelle all'interno delle 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 di Archiviazione BLOB. 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 l'archiviazione con ridondanza locale per ogni database che punta al percorso URI completo che contiene una singola cartella del database.
  • Il percorso dell'URI di backup, il nome del contenitore o i nomi delle cartelle non devono contenere backup o backups 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.
  • L’archiviazione con ridondanza locale può supportare fino a 100 processi di ripristino simultanei per singola istanza gestita.
  • Un singolo processo di archiviazione con ridondanza locale 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 è 200 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.

Nota

Se è necessario che un database sia accessibile in sola lettura durante la migrazione, con un intervallo di tempo molto più lungo per l'esecuzione della migrazione e con tempi di inattività minimi, è consigliabile usare la funzionalità di collegamento Istanza gestita come soluzione di migrazione consigliata.

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, possono verificarsi tempi di inattività notevoli perché i database non sono disponibili dopo il cutover mentre i database vengono sottoposto a seeding in 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.

Importante

Queste limitazioni sono applicabili solo quando si esegue la migrazione al livello di servizio Business Critical e non al livello di servizio Per utilizzo generico.

Cutover più lungo nel livello di servizio Business Critical

Se si esegue la migrazione a un Istanza gestita di SQL nel livello di servizio Business Critical, tenere conto del ritardo nell'inserimento online dei database nella replica primaria mentre viene eseguito il seeding 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 in Azure, i database non sono disponibili fino a quando non sono stati sottoposti a seeding dalla replica primaria alle tre repliche secondarie, che possono richiedere una quantità prolungata di tempo a seconda delle dimensioni del database. Più grande è il database, il seeding più lungo per le repliche secondarie richiede 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 Utilizzo generico e quindi eseguire l'aggiornamento al livello di servizio Business Critical durante una finestra di manutenzione successiva. 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.

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 in corso:

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

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

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? La concessione di più autorizzazioni rispetto Read a e List causerà l'esito negativo dell'archiviazione con ridondanza locale.
  • È 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