Condividi tramite

Guida alla migrazione: SQL Server al database SQL di Azure

  • Articolo

Si applica a: SQL Server database SQL di Azure

In questa guida viene illustrato come eseguire la migrazione dell'istanza di SQL Server a database SQL di Azure.

Esaminare i prerequisiti e completare i passaggi di pre-migrazione prima di continuare.

Migrazione

Dopo aver completato i passaggi della fase di pre-migrazione, è possibile eseguire la migrazione dello schema e dei dati.

Eseguire la migrazione dei dati usando il metodo di migrazione scelto.

Eseguire la migrazione usando l'estensione di migrazione di Azure SQL per Azure Data Studio

Per eseguire una migrazione offline con Azure Data Studio, seguire questa procedura dettagliata. Per un'esercitazione dettagliata, vedere Esercitazione: eseguire la migrazione di SQL Server a database SQL di Azure (offline).

  1. Scaricare e installare Azure Data Studio e l'estensione di Migrazione SQL di Azure.
  2. Avviare la procedura guidata Eseguire la migrazione in migrazione di Azure SQL nell'estensione di Azure Data Studio.
  3. Selezionare i database per la valutazione e visualizzare i problemi di idoneità o di preparazione della migrazione (se presenti). Inoltre, raccogliere i dati sulle prestazioni e ottenere consigli di Azure appropriati.
  4. Selezionare l'account Azure e il database SQL di Azure di destinazione dalla sottoscrizione.
  5. Selezionare l'elenco di tabelle di cui eseguire la migrazione.
  6. Creare un nuovo Servizio Migrazione del database di Azure usando la procedura guidata in Azure Data Studio. Se in precedenza è stato creato un Servizio Migrazione del database di Azure usando Azure Data Studio, è possibile riutilizzare lo stesso, se necessario.
  7. Facoltativo: è necessario scaricare e installare il runtime di integrazione self-hosted in una macchina con accesso all'istanza di SQL Server di origine e alla posizione contenente i file di backup se i backup si trovano in una condivisione di rete locale.
  8. Dopo aver avviato la migrazione del database, è possibile monitorare lo stato di avanzamento in Azure Data Studio. È anche possibile tenere traccia dello stato di avanzamento nel portale di Azure nella risorsa del servizio Migrazione del database di Azure.

Sincronizzazione e cutover dei dati

Quando si usano opzioni di migrazione che replicano/sincronizzano continuamente le modifiche dei dati dall'origine alla destinazione, i dati e lo schema di origine possono cambiare e derivare dalla destinazione. Durante la sincronizzazione dei dati, assicurarsi che tutte le modifiche nell'origine vengano acquisite e applicate alla destinazione durante il processo di migrazione.

Dopo aver verificato che i dati siano uguali sia nell'origine che nella destinazione, è possibile passare dall'origine all'ambiente di destinazione. Pianificando il processo di cutover con i team aziendali/applicativi per garantire un'interruzione minima durante il cutover non si influisce sulla continuità aziendale.

Importante

Per informazioni dettagliate sui passaggi specifici associati all'esecuzione di un cutover come parte delle migrazioni tramite Servizio Migrazione del database, vedere Esercitazione: eseguire la migrazione di SQL Server a database SQL di Azure tramite Servizio Migrazione del database (versione classica).

Eseguire la migrazione con replica transazionale

Quando non è possibile rimuovere il database SQL Server dalla produzione durante la migrazione, è possibile usare la replica transazionale di SQL Server come soluzione di migrazione. Per poter usare questo metodo, il database di origine deve soddisfare i requisiti per la replica transazionale ed essere compatibile con il database SQL di Azure. Per informazioni sulla replica di SQL con i gruppi di disponibilità, vedere Configurare la replica per i gruppi di disponibilità Always On.

Per usare questa soluzione, è necessario configurare il database SQL di Azure come sottoscrittore dell'istanza di SQL Server di cui si vuole eseguire la migrazione. Il server di distribuzione della replica transazionale sincronizza i dati dal database da sincronizzare, ovvero il server di pubblicazione, mentre continua l'esecuzione di transazioni.

Con la replica transazionale, tutte le modifiche ai dati o allo schema vengono visualizzate nel database SQL di Azure. Quando la sincronizzazione è completata e si è pronti a eseguire la migrazione, è sufficiente modificare la stringa di connessione delle applicazioni in modo che puntino al database. Al termine dello svuotamento delle eventuali modifiche rimaste nel database di origine da parte della replica transazionale, quando tutte le applicazioni puntano al database SQL di Azure è possibile disinstallare la replica transazionale. Il database SQL di Azure è ora il sistema di produzione.

Suggerimento

È anche possibile usare la replica transazionale per eseguire la migrazione di un subset del database di origine. La pubblicazione di cui si esegue la replica nel database SQL di Azure può essere limitata a un subset delle tabelle nel database replicato. Per ogni tabella replicata, è possibile limitare i dati a un subset di righe e/o di colonne.

Flusso di lavoro di replica transazionale

Importante

Usare sempre la versione più aggiornata di SQL Server Management Studio per restare sincronizzati con gli aggiornamenti di Azure e del database SQL. Le versioni precedenti di SQL Server Management Studio non possono impostare il database SQL come sottoscrittore. Scaricare la versione più recente di SQL Server Management Studio..

Procedi metodo
Configurare la distribuzione SQL Server Management Studio | Transact-SQL
Creare la pubblicazione SQL Server Management Studio | Transact-SQL
Creazione di una sottoscrizione SQL Server Management Studio | Transact-SQL

Suggerimenti e differenze per la migrazione al database SQL

  • Usare un server di distribuzione locale
    • Questo influisce sulle prestazioni del server.
    • Se l'impatto sulle prestazioni non è accettabile, è possibile usare un altro server aumentando la complessità delle operazioni di gestione e amministrazione.
  • Quando si seleziona una cartella snapshot, assicurarsi che le dimensioni della cartella selezionata siano sufficienti a contenere un BCP di ogni tabella da replicare.
  • La creazione di snapshot consente di bloccare le tabelle associate fino al completamento; è quindi consigliabile pianificare lo snapshot in modo appropriato.
  • Nel database SQL di Azure sono supportate solo le sottoscrizioni push. È possibile aggiungere sottoscrittori unicamente dal database di origine.

Raccomandazioni sulla migrazione

Quando si esegue la migrazione al database SQL di Azure, tenere presente quanto segue:

Conflitti tra risorse Elemento consigliato
Origine (in genere in locale) I colli di bottiglia principale durante la migrazione dall'origine sono l'I/O e la latenza del file di dati, che deve essere monitorata attentamente. In base all'I/O e alla latenza del file di dati e a seconda che si tratti di una macchina virtuale o di un server fisico, si potrebbe edover coinvolgere l'amministratore dell'archiviazione ed esplorare le opzioni per attenuare il collo di bottiglia.
Destinazione (database SQL di Azure) Il fattore di limitazione più importante è la velocità di generazione e la latenza dei log nel file di log del database. Con database SQL di Azure, è possibile ottenere una velocità massima di generazione del log di 96 MB/s. Per velocizzare la migrazione, aumentare le prestazioni del database SQL di Azure di destinazione a Business Critical Gen5 8 vCore per ottenere la velocità massima di generazione del log di 96 MB/s, che offre anche bassa latenza per i file di log. Il livello di servizio Hyperscale offre una frequenza di log di 100 MB/s indipendentemente dal livello di servizio scelto.
Rete La larghezza di banda di rete necessaria è uguale alla velocità massima di inserimento dei log di 96 MB/s (768 Mb/s) A seconda della connettività di rete dal data center locale ad Azure, controllare la larghezza di banda di rete (in genere Azure ExpressRoute) per soddisfare la frequenza massima di inserimento dei log.

È anche possibile prendere in considerazione queste raccomandazioni per ottenere prestazioni ottimali durante il processo di migrazione.

  • Scegliere il livello di servizio e le dimensioni di calcolo più elevati consentiti dal budget per ottimizzare le prestazioni di trasferimento. Per risparmiare, è possibile ridurre le prestazioni al termine della migrazione.
  • Ridurre al minimo la distanza tra il file BACPAC e il data center di destinazione se si usano file BACPAC.
  • Disabilitare l'aggiornamento automatico e la creazione automatica delle statistiche durante la migrazione.
  • Partizionare tabelle e indici.
  • Eliminare le viste indicizzate e ricrearle al termine.
  • Rimuovere i dati cronologici raramente sottoposti a query in un altro database ed eseguire la migrazione di tali dati in un database SQL di Azure separato. Sarà quindi possibile eseguire query sui dati cronologici usando query elastiche.

Dopo la migrazione

Dopo aver completato la fase di migrazione, è necessario eseguire una serie di attività post-migrazione per assicurarsi che tutto funzioni nel modo corretto e più efficiente possibile.

La fase di post-migrazione è fondamentale per risolvere eventuali problemi di accuratezza dei dati e verificarne la completezza, nonché per risolvere possibili problemi di prestazioni con il carico di lavoro.

Aggiornare le statistiche

Aggiornare le statistiche con un'analisi completa dopo aver completato la migrazione.

Correggere le applicazioni

Dopo la migrazione dei dati nell'ambiente di destinazione, tutte le applicazioni che in precedenza usavano l'origine devono iniziare a usare la destinazione. Per ottenere questo risultato, in alcuni casi sarà necessario apportare modifiche alle applicazioni.

Eseguire test

L'approccio di test per la migrazione del database prevede le attività seguenti:

  1. Sviluppare i test di convalida: per testare la migrazione del database, è necessario usare query SQL. È necessario creare le query di convalida da eseguire sia sul database di origine che su quello di destinazione. Le query di convalida devono essere estese all'ambito definito.
  2. Configurare un ambiente di test: l'ambiente di test deve contenere una copia del database di origine e del database di destinazione. Assicurarsi di isolare l'ambiente di test.
  3. Eseguire i test di convalida: eseguire i test di convalida sull'origine e sulla destinazione, quindi analizzare i risultati.
  4. Eseguire test delle prestazioni: eseguire test delle prestazioni sull'origine e sulla destinazione, quindi analizzare e confrontare i risultati.

Usare le funzionalità avanzate

Assicurarsi di sfruttare le funzionalità avanzate basate sul cloud offerte dal database SQL, ad esempio disponibilità elevata predefinita, rilevamento delle minacce e monitoraggio e ottimizzazione del carico di lavoro.

Alcune funzionalità di SQL Server sono disponibili solo dopo la modifica del livello di compatibilità del database al livello di compatibilità più recente.

Per altre informazioni vedere Gestione del database SQL di Azure dopo la migrazione.

Risolvere i problemi di compatibilità della migrazione del database

Esiste una vasta gamma di problemi di compatibilità che potrebbero verificarsi, a seconda della versione dell’SQL Server del database di origine e della complessità del database verso cui si esegue la migrazione. Le versioni precedenti di SQL Server presentano più problemi di compatibilità. Oltre a una ricerca mirata su Internet tramite i propri motori di ricerca preferiti, si consiglia di usare le risorse seguenti:

Importante

Istanza gestita di database SQL consente di eseguire la migrazione di un'istanza di SQL Server esistente e dei relativi database con problemi trascurabili o addirittura nessun problema di compatibilità. Vedere Che cos'è Istanza gestita di SQL di Azure?

Contenuto correlato