Esercitazione: Eseguire la migrazione di SQL Server a Istanza gestita di SQL di Azure online in Azure Data Studio

  • Articolo

Usare l'estensione di migrazione SQL di Azure in Azure Data Studio per eseguire la migrazione di database da un'istanza di SQL Server a un Istanza gestita di SQL di Azure con tempi di inattività minimi. Per i metodi che potrebbero richiedere operazioni manuali, vedere l'articolo Migrazione dell'istanza di SQL Server a Istanza gestita di SQL di Azure.

In questa esercitazione si esegue la migrazione del database AdventureWorks da un'istanza locale di SQL Server a Istanza gestita di SQL di Azure con tempi di inattività minimi usando Azure Data Studio con Servizio Migrazione del database di Azure (DMS). Questa esercitazione è incentrata sulla modalità di migrazione online in cui il tempo di inattività dell'applicazione è limitato a un breve cutover alla fine della migrazione.

In questa esercitazione apprenderai a:

  • Avviare la procedura guidata Eseguire la migrazione ad Azure SQL in Azure Data Studio
  • Eseguire una valutazione dei database SQL Server di origine
  • Raccogliere dati sulle prestazioni dall'origine SQL Server
  • Ottenere una raccomandazione dello SKU Istanza gestita di SQL di Azure più adatto per il carico di lavoro
  • Specificare i dettagli dell'istanza di SQL Server di origine, il percorso di backup e il Istanza gestita di SQL di Azure di destinazione
  • Creare un nuovo Servizio Migrazione del database di Azure e installare il runtime di integrazione self-hosted per accedere al server di origine e ai backup
  • Avviare e monitorare lo stato di avanzamento della migrazione
  • Eseguire il cutover della migrazione quando si è pronti

Importante

Prepararsi per la migrazione e ridurre la durata del processo di migrazione online il più possibile per ridurre al minimo il rischio di interruzione causata dalla riconfigurazione dell'istanza o dalla manutenzione pianificata. Se si verifica un evento di questo tipo, il processo di migrazione ricomincerà dall'inizio. In caso di manutenzione pianificata, è previsto un periodo di tolleranza di 36 ore in cui la configurazione o la manutenzione del Istanza gestita di SQL di Azure di destinazione verrà mantenuta prima del riavvio del processo di migrazione.

Suggerimento

In Servizio Migrazione del database di Azure è possibile eseguire la migrazione dei database offline o mentre sono online. In una migrazione offline , il tempo di inattività dell'applicazione inizia all'avvio della migrazione. Per limitare il tempo di inattività al tempo necessario per passare al nuovo ambiente dopo la migrazione, usare una migrazione online . È consigliabile testare una migrazione offline per determinare se il tempo di inattività è accettabile. Se il tempo di inattività previsto non è accettabile, eseguire una migrazione online.

Questo articolo descrive una migrazione online del database da SQL Server a Istanza gestita di SQL di Azure. Per una migrazione offline del database, vedere Eseguire la migrazione di SQL Server a un Istanza gestita di SQL offline con Azure Data Studio con Servizio Migrazione del database.

Prerequisiti

Per completare questa esercitazione, è necessario:

  • Scaricare e installare Azure Data Studio

  • Installare l'estensione di migrazione sql di Azure dal marketplace di Azure Data Studio

  • Avere un account Azure assegnato a uno dei ruoli predefiniti elencati di seguito:

    • Collaboratore per il Istanza gestita di SQL di Azure di destinazione (e Archiviazione account per caricare i file di backup del database dalla condivisione di rete SMB).
    • Ruolo lettore per i gruppi di risorse di Azure contenenti il Istanza gestita di SQL di Azure di destinazione o l'account di archiviazione di Azure.
    • Ruolo Proprietario o Collaboratore per la sottoscrizione di Azure (obbligatorio se si crea un nuovo servizio Servizio Migrazione del database).
    • In alternativa all'uso dei ruoli predefiniti precedenti, è possibile assegnare un ruolo personalizzato come definito in questo articolo.

    Importante

    L'account Azure è necessario solo quando si configurano i passaggi di migrazione e non è necessario per la valutazione o i passaggi consigliati di Azure nella procedura guidata per la migrazione.

  • Creare un Istanza gestita di SQL di Azure di destinazione.

  • Assicurarsi che gli account di accesso usati per connettere l'istanza di SQL Server di origine siano membri del ruolo del server sysadmin o dispongano CONTROL SERVER dell'autorizzazione.

  • Usare una delle opzioni di archiviazione seguenti per i file di backup completi del database e del log delle transazioni:

    • Condivisione di rete SMB
    • Condivisione file o contenitore BLOB dell'account di archiviazione di Azure

    Importante

    • L'estensione Migrazione SQL di Azure per Azure Data Studio non esegue backup del database o non avvia alcun backup del database per conto dell'utente. Il servizio usa invece i file di backup del database esistenti per la migrazione.
    • Se i file di backup del database vengono forniti in una condivisione di rete SMB, creare un account di archiviazione di Azure che consenta al servizio Servizio Migrazione del database di caricare i file di backup del database. Assicurarsi di creare l'account di archiviazione di Azure nella stessa area in cui viene creata l'istanza di Servizio Migrazione del database di Azure.
    • Ogni backup può essere scritto in un file di backup separato o in più file di backup. Tuttavia, l'aggiunta di più backup ( ovvero full e t-log) in un singolo supporto di backup non è supportata.
    • Usare i backup compressi per ridurre la probabilità di riscontrare potenziali problemi associati alla migrazione di backup di grandi dimensioni.

  • Assicurarsi che l'account del servizio che esegue l'istanza di SQL Server di origine disponga delle autorizzazioni di lettura e scrittura per la condivisione di rete SMB che contiene i file di backup del database.

  • Prima di eseguire la migrazione dei dati, è necessario eseguire la migrazione del certificato dell'istanza di SQL Server di origine da un database protetto da Transparent Data Encryption (TDE) alla Istanza gestita di SQL di Azure di destinazione o a SQL Server nella macchina virtuale di Azure. Per altre informazioni sulla migrazione di database abilitati per TDE, vedere Esercitazione: Eseguire la migrazione di database abilitati per TDE (anteprima) ad Azure SQL in Azure Data Studio.

    Suggerimento

    Se il database contiene dati sensibili protetti da Always Encrypted, il processo di migrazione che usa Azure Data Studio con Servizio Migrazione del database eseguirà automaticamente la migrazione delle chiavi Always Encrypted al Istanza gestita di SQL di Azure di destinazione o SQL Server nella macchina virtuale di Azure.

  • Se i backup del database si trovano in una condivisione file di rete, fornire un computer per installare il runtime di integrazione self-hosted per accedere ed eseguire la migrazione dei backup del database. La migrazione guidata fornisce il collegamento di download e le chiavi di autenticazione per scaricare e installare il runtime di integrazione self-hosted. In preparazione per la migrazione, assicurarsi che il computer in cui si prevede di installare il runtime di integrazione self-hosted disponga delle regole del firewall in uscita e dei nomi di dominio seguenti abilitati:

    Nomi di dominio Porte in uscita Descrizione
    Cloud pubblico: {datafactory}.{region}.datafactory.azure.net
    o *.frontend.clouddatahub.net
    Azure per enti pubblici:{datafactory}.{region}.datafactory.azure.us
    Cina: {datafactory}.{region}.datafactory.azure.cn    		 443 Richiesto dal runtime di integrazione self-hosted per connettersi al servizio Migrazione dati.
    Per una data factory appena creata nel cloud pubblico, individuare il nome di dominio completo dalla chiave di runtime di integrazione self-hosted, in formato {datafactory}.{region}.datafactory.azure.net. Per la data factory precedente, se non viene visualizzato il nome di dominio completo nella chiave di integrazione self-hosted, usare invece *.frontend.clouddatahub.net.
    download.microsoft.com 443 Richiesta dal runtime di integrazione self-hosted per il download degli aggiornamenti. Se l'aggiornamento automatico è stato disabilitato, è possibile ignorare la configurazione di questo dominio.
    *.core.windows.net 443 Usato dal runtime di integrazione self-hosted che si connette all'account di archiviazione di Azure per caricare i backup del database dalla condivisione di rete

    Suggerimento

    Se i file di backup del database sono già disponibili in un account di archiviazione di Azure, non è necessario un runtime di integrazione self-hosted durante il processo di migrazione.

  • Quando si usa un runtime di integrazione self-hosted, assicurarsi che il computer in cui è installato il runtime possa connettersi all'istanza di SQL Server di origine e alla condivisione file di rete in cui si trovano i file di backup. La porta in uscita 445 deve essere abilitata per consentire l'accesso alla condivisione file di rete. Vedere anche le raccomandazioni per l'uso di un runtime di integrazione self-hosted

  • Se si usa il Servizio Migrazione del database di Azure per la prima volta, assicurarsi che il provider di risorse Microsoft.DataMigration sia registrato nella sottoscrizione. È possibile seguire la procedura per registrare il provider di risorse

Avviare la procedura guidata Eseguire la migrazione ad Azure SQL in Azure Data Studio

  1. Aprire Azure Data Studio e selezionare l'icona del server per connettersi a SQL Server locale (o SQL Server nella macchina virtuale di Azure).
  2. Nella connessione server fare clic con il pulsante destro del mouse e scegliere Gestisci.
  3. Nella home page del server selezionare Estensione Migrazione SQL di Azure.
  4. Nel dashboard di Migrazione SQL di Azure selezionare Migrate to Azure SQL (Eseguire la migrazione a SQL di Azure) per avviare la migrazione guidata. Launch Migrate to Azure SQL wizard
  5. La prima pagina della procedura guidata consente di avviare una nuova sessione o riprendere una sessione salvata in precedenza. Selezionare la prima opzione per avviare una nuova sessione.

Eseguire la valutazione del database, raccogliere dati sulle prestazioni e ottenere consigli di Azure

  1. Selezionare i database per eseguire la valutazione e selezionare Avanti.
  2. Selezionare Istanza gestita di SQL di Azure come destinazione. Assessment confirmation
  3. Selezionare il pulsante Visualizza/Seleziona per visualizzare i dettagli dei risultati della valutazione per i database, selezionare i database di cui eseguire la migrazione e selezionare OK. Se nei risultati della valutazione vengono visualizzati problemi, è necessario risolverli prima di procedere con i passaggi successivi. Database assessment details
  4. Selezionare il pulsante Ottieni raccomandazione di Azure.
  5. Selezionare l'opzione Raccogli dati sulle prestazioni e immettere un percorso per i log delle prestazioni da raccogliere e selezionare il pulsante Start .
  6. Azure Data Studio raccoglierà ora i dati sulle prestazioni fino a quando non si arresta la raccolta, premere il pulsante Avanti nella procedura guidata o chiudere Azure Data Studio.
  7. Dopo 10 minuti viene visualizzata una configurazione consigliata per il Istanza gestita di SQL di Azure. È anche possibile premere il collegamento Aggiorna raccomandazione dopo i 10 minuti iniziali per aggiornare la raccomandazione con i dati aggiuntivi raccolti.
  8. Nella casella precedente Istanza gestita di SQL di Azure* selezionare il pulsante Visualizza dettagli per altre informazioni sulla raccomandazione.
  9. Chiudere la casella dei dettagli della visualizzazione e premere il pulsante Avanti .

Configurare le impostazioni di migrazione

  1. Specificare il Istanza gestita di SQL di Azure selezionando la sottoscrizione, la località, il gruppo di risorse negli elenchi a discesa corrispondenti e quindi selezionare Avanti.
  2. Selezionare Migrazione online come modalità di migrazione.

    Nota

    Nella modalità di migrazione online, il database SQL Server di origine può essere usato per l'attività di lettura e scrittura mentre i backup del database vengono ripristinati continuamente nei Istanza gestita di SQL di Azure di destinazione. Il tempo di inattività dell'applicazione è limitato alla durata del cutover al termine della migrazione.

  3. Selezionare il percorso dei backup del database. I backup del database possono trovarsi in una condivisione di rete locale o in un contenitore BLOB di archiviazione di Azure.

    Nota

    Se i backup del database vengono forniti in una condivisione di rete locale, il Servizio Migrazione del database richiederà di configurare un runtime di integrazione self-hosted nel passaggio successivo della procedura guidata. Se è necessario un runtime di integrazione self-hosted per accedere ai backup del database di origine, verificare la validità del set di backup e caricarli nell'account di archiviazione di Azure.
    Se i backup del database sono già in un contenitore BLOB di archiviazione di Azure, non è necessario configurare un runtime di integrazione self-hosted.

  • Per i backup che si trovano in una condivisione di rete, specificare i dettagli seguenti di SQL Server di origine, il percorso di backup di origine, il nome del database di destinazione e l'account di archiviazione di Azure in cui caricare i file di backup:

    Campo Descrizione
    Credenziali di origine - Nome utente Credenziali (autenticazione di Windows/SQL) per connettersi all'istanza di SQL Server di origine e convalidare i file di backup.
    Credenziali di origine - Password Credenziali (autenticazione di Windows/SQL) per connettersi all'istanza di SQL Server di origine e convalidare i file di backup.
    Percorso condivisione di rete che contiene i backup Percorso di condivisione di rete che contiene i file di backup completi e del log delle transazioni. Eventuali file o file di backup non validi nella condivisione di rete che non appartengono al set di backup valido verranno ignorati automaticamente durante il processo di migrazione.
    Account utente di Windows con accesso in lettura al percorso della condivisione di rete Credenziali di Windows (nome utente) con accesso in lettura alla condivisione di rete per recuperare i file di backup.
    Password Credenziali di Windows (password) con accesso in lettura alla condivisione di rete per recuperare i file di backup.
    Nome database di destinazione Il nome del database di destinazione può essere modificato se si desidera modificare il nome del database nella destinazione durante il processo di migrazione.
    Archiviazione dettagli dell'account Gruppo di risorse e account di archiviazione in cui vengono caricati i file di backup. Non è necessario creare un contenitore perché il Servizio Migrazione del database creerà automaticamente un contenitore BLOB nell'account di archiviazione specificato durante il processo di caricamento.

  • Per i backup archiviati in un contenitore BLOB di archiviazione di Azure, specificare i dettagli seguenti del nome del database di destinazione, del gruppo di risorse, dell'account di archiviazione di Azure e del contenitore BLOB dagli elenchi a discesa corrispondenti.

    Campo Descrizione
    Nome database di destinazione Il nome del database di destinazione può essere modificato se si desidera modificare il nome del database nella destinazione durante il processo di migrazione.
    Archiviazione dettagli dell'account Gruppo di risorse, account di archiviazione e contenitore in cui si trovano i file di backup.

    Importante

    Se la funzionalità di controllo del loopback è abilitata e la condivisione file e SQL Server di origine si trovano nello stesso computer, l'origine non sarà in grado di accedere alla condivisione file tramite FQDN. Per risolvere questo problema, disabilitare la funzionalità di controllo del loopback usando le istruzioni riportate qui

  • L'estensione di migrazione sql di Azure per Azure Data Studio non richiede più configurazioni specifiche nelle impostazioni di rete dell'account Archiviazione di Azure per eseguire la migrazione dei database di SQL Server ad Azure. Tuttavia, a seconda del percorso di backup del database e delle impostazioni di rete dell'account di archiviazione desiderato, sono necessari alcuni passaggi per assicurarsi che le risorse possano accedere all'account Archiviazione di Azure. Vedere la tabella seguente per i vari scenari di migrazione e configurazioni di rete:

    Scenario Condivisione di rete SMB Archiviazione di Azure contenitore dell'account
    Abilitato da tutte le reti Nessun passaggio aggiuntivo Nessun passaggio aggiuntivo
    Abilitato da reti virtuali e indirizzi IP selezionati Vedere 1a Vedere 2a
    Abilitato da reti virtuali selezionate e indirizzi IP + endpoint privato Vedere 1b Vedere 2b

    1a - Configurazione di rete dell'archiviazione BLOB di Azure

    Se il runtime di integrazione self-hosted è installato in una macchina virtuale di Azure, vedere la sezione 1b - Configurazione della rete di archiviazione BLOB di Azure. Se nella rete locale è installato il runtime di integrazione self-hosted, è necessario aggiungere l'indirizzo IP client del computer host nell'account di Archiviazione di Azure come indicato di seguito:

    Screenshot that shows the storage account network details

    Per applicare questa configurazione specifica, connettersi al portale di Azure dal computer SHIR, aprire la configurazione dell'account Archiviazione di Azure, selezionare Rete e quindi selezionare la casella di controllo Aggiungi indirizzo IP client. Selezionare Salva per rendere persistente la modifica. Per i passaggi rimanenti, vedere la sezione 2a - Configurazione di rete dell'archiviazione BLOB di Azure (endpoint privato).

    1b - Configurazione di rete dell'archiviazione BLOB di Azure

    Se il servizio SHIR è ospitato in una macchina virtuale di Azure, è necessario aggiungere la rete virtuale della macchina virtuale all'account Archiviazione di Azure poiché la macchina virtuale ha un indirizzo IP non pubblico che non può essere aggiunto alla sezione Intervallo di indirizzi IP.

    Screenshot that shows the storage account network firewall configuration.

    Per applicare questa configurazione specifica, individuare l'account Archiviazione di Azure, nel pannello Archiviazione dati selezionare Rete e quindi selezionare la casella di controllo Aggiungi rete virtuale esistente. Viene aperto un nuovo pannello, selezionare la sottoscrizione, la rete virtuale e la subnet della macchina virtuale di Azure che ospita il runtime di integrazione. Queste informazioni sono disponibili nella pagina Panoramica della macchina virtuale di Azure. In caso affermativo, la subnet potrebbe indicare che l'endpoint del servizio è necessario , selezionare Abilita. Quando tutto è pronto, salvare gli aggiornamenti. Per i passaggi rimanenti necessari, vedere la sezione 2a - Configurazione di rete dell'archiviazione BLOB di Azure (endpoint privato).

    2a - Configurazione di rete dell'archiviazione BLOB di Azure (endpoint privato)

    Se i backup vengono inseriti direttamente in un contenitore di Archiviazione di Azure, tutti i passaggi precedenti non sono necessari perché non esiste un runtime di integrazione che comunica con l'account Archiviazione di Azure. Tuttavia, è comunque necessario assicurarsi che l'istanza di SQL Server di destinazione possa comunicare con l'account Archiviazione di Azure per ripristinare i backup dal contenitore. Per applicare questa configurazione specifica, seguire le istruzioni nella sezione 1b - Configurazione della rete di archiviazione BLOB di Azure, specificando l'istanza SQL di destinazione Rete virtuale quando si compila il popup "Aggiungi rete virtuale esistente".

    2b - Configurazione di rete dell'archiviazione BLOB di Azure (endpoint privato)

    Se è stato configurato un endpoint privato nell'account Archiviazione di Azure, seguire i passaggi descritti nella sezione 2a - Configurazione della rete di archiviazione BLOB di Azure (endpoint privato). È tuttavia necessario selezionare la subnet dell'endpoint privato, non solo la subnet di SQL Server di destinazione. Verificare che l'endpoint privato sia ospitato nella stessa rete virtuale dell'istanza di SQL Server di destinazione. In caso contrario, creare un altro endpoint privato usando il processo nella sezione Archiviazione di Azure configurazione dell'account.

Creare il Servizio Migrazione del database di Azure

  1. Creare un nuovo Servizio Migrazione del database di Azure o riutilizzare un servizio esistente creato in precedenza.

    Nota

    Se il Servizio Migrazione del database è stato creato in precedenza usando il portale di Azure, non è possibile riutilizzarlo nella procedura guidata di migrazione in Azure Data Studio. È possibile riutilizzare solo il Servizio Migrazione del database creato in precedenza usando Azure Data Studio.

  2. Selezionare il gruppo di risorse in cui è presente un servizio Migrazione del database esistente o crearne uno nuovo. Nell'elenco a discesa Servizio Migrazione del database di Azure è elencato qualsiasi servizio Migrazione del database esistente nel gruppo di risorse selezionato.
  3. Per riutilizzare un Servizio Migrazione del database esistente, selezionarlo nell'elenco a discesa e lo stato del runtime di integrazione self-hosted verrà visualizzato nella parte inferiore della pagina.
  4. Per creare un nuovo Servizio Migrazione del database, selezionare Crea nuovo. Nella schermata Crea Servizio Migrazione del database di Azure specificare il nome del Servizio Migrazione del database e selezionare Crea.
  5. Dopo aver creato il Servizio Migrazione del database, verranno forniti i dettagli per configurare il runtime di integrazione.
  6. Selezionare Scarica e installa il runtime di integrazione per aprire il collegamento di download in un Web browser. Completare il download. Installare il runtime di integrazione in un computer che soddisfi i prerequisiti per la connessione a SQL Server di origine e il percorso contenente il backup di origine.
  7. Al termine dell'installazione, Microsoft Integration Runtime Configuration Manager avvierà automaticamente per avviare il processo di registrazione.
  8. Copiare e incollare una delle chiavi di autenticazione fornite nella schermata della procedura guidata in Azure Data Studio. Se la chiave di autenticazione è valida, viene visualizzata un'icona di spunta verde in Integration Runtime Configuration Manager che indica che è possibile continuare a Eseguire la registrazione.
  9. Dopo aver completato correttamente la registrazione del runtime di integrazione self-hosted, chiudere Microsoft Integration Runtime Configuration Manager e tornare alla migrazione guidata in Azure Data Studio.
  10. Selezionare Test connessione nella schermata Crea Servizio Migrazione del database di Azure in Azure Data Studio per verificare che il servizio Migrazione del database appena creato sia connesso al runtime di integrazione self-hosted appena registrato. Test connection integration runtime
  11. Esaminare il riepilogo della migrazione e selezionare Fine per avviare la migrazione del database.

Monitorare la migrazione

  1. Nello stato della migrazione del database è possibile tenere traccia delle migrazioni in corso, delle migrazioni completate e delle migrazioni non riuscite (se presenti).

    monitor migration dashboard

  2. Selezionare Migrazioni di database in corso per visualizzare le migrazioni in corso e ottenere altri dettagli selezionando il nome del database.

  3. Nella pagina dei dettagli della migrazione vengono visualizzati i file di backup e lo stato corrispondente:

    Status Descrizione
    Arrivata Il file di backup è arrivato nel percorso di backup di origine e convalidato
    Caricamento Il runtime di integrazione sta attualmente caricando il file di backup in Archiviazione di Azure
    Caricato Il file di backup viene caricato in Archiviazione di Azure
    Restoring Servizio Migrazione del database di Azure sta attualmente ripristinando il file di backup in Istanza gestita di SQL di Azure
    Ripristinata Il file di backup viene ripristinato correttamente in Istanza gestita di SQL di Azure
    Annullati Processo di migrazione annullato
    Ignorato Il file di backup è stato ignorato perché non appartiene a una catena di backup del database valida

    backup restore details

Completare il cutover della migrazione

Il passaggio finale dell'esercitazione consiste nel completare il cutover della migrazione per assicurarsi che il database migrato in Istanza gestita di SQL di Azure sia pronto per l'uso. Questo processo è l'unica parte che richiede tempi di inattività per le applicazioni che si connettono al database e quindi la tempistica del cutover deve essere pianificata attentamente con gli stakeholder aziendali o dell'applicazione.

Per completare il cutover:

  1. Arrestare tutte le transazioni in ingresso nel database di origine.
  2. Apportare modifiche alla configurazione dell'applicazione in modo che puntino al database di destinazione in Istanza gestita di SQL di Azure.
  3. Eseguire un backup del log finale del database di origine nel percorso di backup specificato
  4. Inserire il database di origine in modalità di sola lettura. Pertanto, gli utenti possono leggere i dati dal database ma non modificarli.
  5. Verificare che tutti i backup del database abbiano lo stato Ripristinato nella pagina dei dettagli di monitoraggio.
  6. Selezionare Completare cutover nella pagina dei dettagli del monitoraggio.

Durante il processo di cutover, lo stato della migrazione cambia da in corso a completamento. Al termine del processo di cutover, lo stato della migrazione viene modificato in modo da indicare che la migrazione del database ha esito positivo e che il database migrato è pronto per l'uso.

Importante

Dopo il cutover, la disponibilità di Istanza gestita di SQL con il livello di servizio Business Critical può richiedere molto più tempo rispetto a Utilizzo generico perché è necessario eseguire il seeding di tre repliche secondarie per il gruppo di disponibilità elevata AlwaysOn. Questa durata dell'operazione dipende dalle dimensioni dei dati. Per altre informazioni, vedere Durata delle operazioni di gestione.

Limiti

La migrazione a Istanza gestita di SQL di Azure usando l'estensione Azure SQL per Azure Data Studio presenta le limitazioni seguenti:

  • Se si esegue la migrazione di un database singolo, i backup del database devono essere inseriti in una struttura di file flat all'interno di una cartella di database (inclusa la cartella radice del contenitore) e le cartelle non possono essere annidate, perché l'annidamento non è supportato.
  • 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.
  • La sovrascrittura dei database esistenti tramite Servizio Migrazione del database nell'Istanza gestita di SQL di Azure di destinazione non è supportata.
  • Il Servizio Migrazione del database non supporta la configurazione della disponibilità elevata e del ripristino di emergenza nella destinazione in modo che corrisponda alla topologia di origine.
  • Gli oggetti server seguenti non sono supportati:
    • SQL Server Agent - processi
    • Credenziali
    • Pacchetti SSIS
    • Controllo server
  • Non è possibile usare un runtime di integrazione self-hosted esistente creato da Azure Data Factory per le migrazioni di database con Servizio Migrazione del database. Inizialmente, il runtime di integrazione self-hosted deve essere creato usando l'estensione di migrazione Azure SQL in Azure Data Studio e può essere riutilizzato per altre migrazioni di database.
  • Un singolo processo di archiviazione con ridondanza locale (creato dal Servizio Migrazione del database) può essere eseguito per un massimo di 30 giorni. Alla scadenza di questo periodo, il processo viene annullato automaticamente, in modo che il database di destinazione venga eliminato automaticamente.
  • Se è stato visualizzato l'errore seguente: Memory-optimized filegroup must be empty in order to be restored on General Purpose tier of SQL Database Managed Instance. Questo problema è per impostazione predefinita, Hekaton (noto anche come OLTP in memoria di SQL Server) non è supportato nel livello Utilizzo generico di Istanza gestita di SQL di Azure. Per continuare la migrazione, un modo consiste nell'eseguire l'aggiornamento al livello Business Critical, che supporta Hekaton. Un altro modo consiste nel assicurarsi che il database di origine non lo usi mentre il Istanza gestita di SQL di Azure è utilizzo generico.

Passaggi successivi