Preparare l'ambiente per la migrazione LRS - migrazione SQL Server in Azure Arc

Applica a:SQL Server

Questo articolo illustra come preparare l'ambiente per una migrazione Log Replay Service (LRS dell'istanza di SQL Server abilitata da Azure Arc a Istanza gestita di SQL di Azure nel portale di Azure.

Con LRS, è possibile eseguire la migrazione dei database SQL Server ad Istanza gestita di SQL di Azure usando il backup e il ripristino tramite il log shipping (migrazione online):

Prerequisiti

Per eseguire la migrazione dei database SQL Server a Istanza gestita di SQL di Azure tramite il portale di Azure, sono necessari i prerequisiti seguenti:

• Sottoscrizione attiva Azure. Se non ne hai uno, crea un account gratuito.
• Istanza di SQL Server supportataabilitata da Azure Arc con la versione più recente dell'estensione Azure per SQL Server. Per aggiornare l'estensione, vedere Aggiornare l'estensione.

Versioni di SQL Server supportate

La migrazione con LRS (archiviazione con ridondanza locale) funziona con ogni edizione di SQL Server su Windows. Anche se la migrazione ai livelli di servizio Utilizzo generico e Business Critical di Istanza gestita di SQL è supportata, la migrazione diretta al livello di servizio Business Critical presenta alcune limitazioni importanti da considerare.

Nella tabella seguente sono elencate le versioni minime supportate di SQL Server per LRS:

La migrazione inversa è supportata solo per SQL Server 2025 e SQL Server 2022 da istanze gestite di SQL con i criteri update corrispondenti. È possibile invertire manualmente una migrazione tramite altri strumenti, ad esempio il backup e il ripristino nativi, oppure configurare manualmente un collegamento in SSMS.

Permissions

Questa sezione descrive le autorizzazioni necessarie per eseguire la migrazione dell'istanza di SQL Server per Istanza gestita di SQL tramite il portale di Azure.

Nell'istanza di SQL Server di origine sono necessarie le autorizzazioni seguenti:

• Se si abilitano privilegi minimi, le autorizzazioni necessarie, ad esempio sysadmin , vengono concesse in base alle esigenze durante il processo di migrazione del database.
• Se non è possibile usare privilegi minimi, sono necessarie autorizzazioni sysadmin per l'istanza di SQL Server di origine.

Per migrare con LRS, è necessaria una delle seguenti autorizzazioni sulla destinazione Istanza gestita di SQL:

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

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. L'account di archiviazione deve trovarsi nella stessa sottoscrizione Azure della destinazione 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:
   1. Cercare Account di archiviazione nel portale di Azure e selezionare Crea.
   2. Nella scheda Informazioni di base selezionare la sottoscrizione e il gruppo di risorse. L'area deve corrispondere alla destinazione Istanza gestita di SQL.
   3. Lasciare vuoto il tipo di archiviazione preferito .
   4. Usare le impostazioni predefinite per le altre schede e selezionare Rivedi e crea.
   5. Al termine della convalida selezionare Crea.
2. Crea un contenitore BLOB nell'account di archiviazione.
   1. Passare al nuovo account di archiviazione nel portale di Azure.
   2. In Archiviazione dati selezionare Contenitori.
   3. Usare Aggiungi contenitore per aprire il riquadro Nuovo contenitore .
   4. Immettere un nome per il contenitore, lasciare le opzioni predefinite e selezionare Crea per creare il contenitore.
3. (Facoltativo) Se il Archiviazione di Azure è protetto da un firewall, l'archiviazione BLOB Azure richiede configurazione aggiuntiva dopo il provisioning dell'istanza gestita di SQL.

Concedere le autorizzazioni per Archiviazione BLOB di Azure

Migrazione di SQL Server in Azure Arc con LRS usa un'identità gestita per autenticarsi in Archiviazione BLOB di Azure.

È necessario concedere le autorizzazioni seguenti:

• Concedere all'utente l'accesso all'account di archiviazione in cui si prevede di archiviare i backup durante il processo di migrazione.
• Concedere all'utente l'accesso al gruppo di risorse che contiene l'account di archiviazione.
• Concedere l'accesso all'identità gestita all'account di archiviazione dopo il provisioning dell'istanza gestita di SQL.

Concedere all'utente l'accesso all'account di archiviazione

Per accedere ai backup del database durante il processo di migrazione, assegnare all'utente che accede al portale di Azure ed esegue la migrazione al Storage Blob Data Reader ruolo per l'account di archiviazione che contiene i backup.

Per assegnare il ruolo, seguire questa procedura:

1. Nel portale di Azure passare al gruppo di risorse che contiene l'account di archiviazione.

2. Selezionare Controllo di accesso (IAM) dal menu delle risorse.

3. Usare + Aggiungi per selezionare Aggiungi assegnazione di ruolo e aprire il riquadro Aggiungi assegnazione di ruolo .

4. Cercare e selezionare il ruolo Lettore dati BLOB di archiviazione. Quindi seleziona Avanti.

   

5. Usare + Seleziona membri per aprire il riquadro Seleziona membri e cercare l'account utente della persona che esegue la migrazione. Se più persone eseguono la migrazione dei dati, concedere a tutti gli utenti l'accesso. Selezionare l'account utente e quindi utilizzare Seleziona per salvare la selezione. Selezionare l'opzione per assegnare l'accesso a Utente, gruppo o entità servizio.

6. Selezionare Rivedi e assegna per passare alla scheda Rivedi e assegna e quindi selezionare di nuovo Rivedi e assegna per completare l'assegnazione di ruolo.

Concedere all'utente l'accesso al gruppo di risorse

Per accedere ai backup del database durante il processo di migrazione, all'utente che accede al portale di Azure ed esegue la migrazione deve essere assegnato il ruolo Reader nel gruppo di risorse che contiene l'account di archiviazione.

Per assegnare il ruolo, seguire questa procedura:

1. Nel portale di Azure passare al gruppo di risorse che contiene l'account di archiviazione.

2. Selezionare Controllo di accesso (IAM) dal menu delle risorse.

3. Usare + Aggiungi per selezionare Aggiungi assegnazione di ruolo e aprire il riquadro Aggiungi assegnazione di ruolo .

4. Cercare e selezionare il ruolo Lettore . Quindi seleziona Avanti.

   

5. Usare + Seleziona membri per aprire il riquadro Seleziona membri e cercare l'account utente della persona che esegue la migrazione. Se più persone eseguono la migrazione dei dati, concedere a tutti gli utenti l'accesso. Selezionare l'account utente e quindi utilizzare Seleziona per salvare la selezione. Selezionare l'opzione per assegnare l'accesso a Utente, gruppo o entità servizio e quindi usare Avanti per continuare.

6. Nella scheda Tipo di assegnazione impostare Tipo di assegnazione su Attivo e durata assegnazione su Permanente:

   Screenshot che mostra come impostare il tipo di assegnazione su Attivo e la durata dell'assegnazione su Permanente nella scheda Tipo di assegnazione del portale Azure.

7. Selezionare Rivedi e assegna per passare alla scheda Rivedi e assegna e quindi selezionare di nuovo Rivedi e assegna per completare l'assegnazione di ruolo.

Concedere l'accesso all'identità gestita all'account di archiviazione

Dopo il provisioning dell'istanza gestita di SQL, è necessario assegnare l'identità gestita dell'istanza gestita di SQL al ruolo Storage Blob Data Reader in modo che possa accedere all'account Archiviazione BLOB di Azure durante il processo di migrazione.

Prima di tutto, è necessario determinare il tipo di identità gestita usata dall'istanza gestita di SQL. A tale scopo, seguire questa procedura:

1. Vai alla tua istanza gestita di SQL nel portale di Azure.
2. In Sicurezza selezionare Identità.
   1. Se nella sezione Identità gestita assegnata dall'utente vedi Nessuna identità gestita assegnata dall'utente trovata, l'istanza gestita di SQL usa l'identità gestita predefinita assegnata dal sistema.
   2. Se viene visualizzata una voce nel campo Identità primaria, l'istanza gestita di SQL utilizza un'identità gestita assegnata dall'utente personalizzata. Prendere nota di questa identità da usare nel passaggio in cui si seleziona questa identità gestita quando si concede all'account di archiviazione l'accesso con autorizzazioni di lettura dei dati BLOB di archiviazione.

Per concedere l'accesso all'account di archiviazione, seguire questa procedura:

1. Passare all'account Archiviazione BLOB di Azure nel portale di Azure che si intende usare per la migrazione.
2. Selezionare Controllo di accesso (IAM) dal menu delle risorse.
3. Usare + Aggiungi per selezionare Aggiungi assegnazione di ruolo e aprire il riquadro Aggiungi assegnazione di ruolo .
4. Cercare e selezionare il ruolo Lettore dati BLOB di archiviazione. Quindi seleziona Avanti.
5. Sotto Assegna accesso a, seleziona l'opzione Identità gestita.
6. Usare Seleziona membri per aprire il riquadro Seleziona membri .
7. Se l'istanza gestita di SQL usa l'identità gestita assegnata dal sistema predefinita:
   1. In Identità gestita selezionare Istanza gestita di SQL.
   2. Cercare e selezionare il nome dell'istanza gestita di SQL.
   3. Usare Seleziona per salvare la selezione.
8. Se l'istanza gestita di SQL usa un'identità gestita assegnata dall'utente:
   1. In Identità gestita selezionare Identità gestita assegnata dall'utente.
   2. Cercare il nome dell'identità primaria annotato in precedenza nella pagina Identitàdell'istanza gestita di SQL e selezionarla.
   3. Usare Seleziona per salvare la selezione.
9. Selezionare Rivedi e assegna per passare alla scheda Rivedi e assegna e quindi selezionare di nuovo Rivedi e assegna per completare l'assegnazione di ruolo.

Dopo aver caricato almeno un backup completo in questo account di archiviazione, è possibile eseguire il comando seguente nell'istanza gestita di SQL per verificare che possa accedere all'account Archiviazione BLOB di Azure:

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Configurare il database di SQL Server di origine

Abilitare il ripristino accelerato del database e Service Broker nell'istanza di SQL Server di origine se si prevede di usare queste funzionalità nel Istanza gestita di SQL di destinazione dopo la migrazione, perché queste funzionalità non possono essere abilitate dopo la migrazione se non sono già abilitate nell'istanza di SQL Server di origine.

Abilitare il ripristino accelerato del database

Per SQL Server 2019 e versioni successive, abilitare il ripristino del database accelerato e assicurarsi che l'archivio versioni permanente sia impostato su PRIMARY. Se il ripristino accelerato del database non è abilitato nel database di SQL Server di origine, non è possibile abilitarlo nell'istanza gestita di SQL di destinazione dopo la migrazione del database. 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.

Per SQL Server 2017 e versioni precedenti, il ripristino accelerato del database non è supportato, quindi questo passaggio non è necessario.

Per configurare correttamente il ripristino accelerato del database nel database di SQL Server di origine, seguire questa procedura:

1. Abilitare il ripristino accelerato del database eseguendo lo script di Transact-SQL seguente in SQL Server:

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. L'archivio versioni permanenti (PVS) deve essere impostato su PRIMARY nel database di origine, ovvero la configurazione predefinita. Se è stato modificato in precedenza, è necessario tornare a PRIMARY prima di avviare la migrazione.

Abilitare Service Broker

Service Broker è abilitato per impostazione predefinita per tutte le versioni di SQL Server. Se Service Broker è stato disabilitato e si prevede di usarlo in Istanza gestita di SQL, abilitare Service Broker nel database di origine SQL Server prima di eseguire la migrazione a Istanza gestita di SQL. Se Service Broker non è abilitato nel database SQL Server di origine, non è possibile usarlo nell'istanza gestita di SQL di destinazione.

Per verificare se Service Broker è abilitato, eseguire lo script di Transact-SQL seguente nell'istanza di SQL Server:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Se Service Broker è disabilitato, abilitarlo eseguendo lo script di Transact-SQL seguente nel database di origine SQL Server:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Caricare i backup nell'account gestione rete virtuale di Azure

Quando il contenitore BLOB è pronto e si è verificato che l'istanza gestita di SQL può accedere al contenitore, è possibile iniziare a caricare i backup nell'account Archiviazione BLOB di Azure. Quando tutti i backup vengono caricati nell'account di archiviazione, è possibile procedere con la migrazione.

Per caricare i backup in Azure:

• Eseguire il backup su un'istanza di SQL Server.
• Copy i backup nell'account gestione rete virtuale di Azure.
• In alternativa, SQL Server 2025 (17.x) su Windows Server introduce il supporto delle identità gestite per i backup direttamente sull'URL. Per effettuare il backup direttamente su un URL per SQL Server 2022 e versioni precedenti, è necessario utilizzare un token SAS. Per usare un'identità gestita con SQL Server 2022 e versioni precedenti, copiare i backup nell'account gestione rete virtuale di Azure usando AzCopy. L'unica eccezione è se si esegue la migrazione da SQL Server in macchine virtuali Azure, che supporta il backup direttamente nell'URL con l'autenticazione con identità gestita a partire da SQL Server 2022 CU 17.

Prendere in considerazione le procedure consigliate seguenti:

• Effettuare backup utilizzando le opzioni COMPRESSION e CHECKSUM per ridurre le dimensioni dei file di backup e prevenire la migrazione di un database danneggiato.
• Eseguire il backup in lotti più piccoli.
• Usare thread di caricamento paralleli.
• Rendere il più piccolo possibile l'ultimo file di backup.
• Per eseguire la migrazione di più database usando lo stesso contenitore 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'inserimento di cartelle nelle cartelle di database non è supportato.

Eseguire backup in un'istanza di SQL Server

I passaggi di questa sezione illustrano come eseguire il backup in locale, ma è anche possibile eseguire il backup direttamente nell'URL.

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

Se non sono già presenti backup esistenti, 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 SQL usando LRS (archiviazione con ridondanza locale), utilizzare i seguenti approcci per copiare i backup esistenti nel proprio account di archiviazione BLOB.

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

Limitazioni

Le limitazioni di LRS si applicano alle migrazioni tramite il portale di Azure.

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, è possibile che si verifichino tempi di inattività notevoli perché i database non sono disponibili dopo il cutover durante il seeding 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 il failover non pianificato, l'aggiornamento del sistema o la patch di sicurezza interrompe la migrazione. Questa limitazione rende 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. Questo ritardo è particolarmente vero 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 passaggio ad Azure, i database non sono disponibili fino a quando non vengono sottoposti a seeding dalla replica primaria alle tre repliche secondarie. Il processo di seeding può richiedere una quantità prolungata di tempo 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 Utilizzo generico, 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.

Il monitoraggio della migrazione tramite il portale di Azure è disponibile solo per le istanze di SQL Server che soddisfano i requisiti di licenza di monitoraggio.

Risolvere i problemi comuni

Per risolvere i problemi comuni durante la migrazione alla Istanza gestita di SQL di Azure, vedere Risoluzione dei problemi di migrazione.

Passo successivo

Contenuti correlati

• migrazione SQL Server in Azure Arc
• Preparare l'ambiente per una migrazione di collegamenti di Istanza gestita
• Panoramica di SQL Server abilitato da Azure Arc
• Feedback sull'esperienza di migrazione direttamente al gruppo di prodotti
• Migrazione verso Istanza gestita di SQL di Azure - migrazione di SQL Server in Azure Arc