Migrazione di un database SQL Server al database SQL nel cloud

Questo articolo illustra i due metodi principali per eseguire la migrazione di un database SQL Server 2005 o versione successiva a un database SQL di Azure. Il primo metodo è più semplice, ma comporta tempi di inattività anche lunghi durante la migrazione. Il secondo metodo è più complesso, ma elimina quasi completamente i tempi di inattività durante la migrazione.

In entrambi i casi, è necessario assicurarsi che il database di origine sia compatibile con database SQL di Azure, tramite Data Migration Assistant (DMA). Con la versione 12 del database SQL si sta raggiungendo la parità di funzionalità con SQL Server, a eccezione dei problemi legati alle operazioni a livello di server e tra database. I database e le applicazioni basati su funzionalità non supportate o supportate parzialmente devono essere riprogettati per risolvere tali incompatibilità prima della migrazione del database SQL Server.

Nota

Per eseguire la migrazione di database diversi dai database di SQL Server, inclusi Microsoft Access, Sybase, MySQL Oracle e DB2 nel database SQL di Azure, vedere il post di blog su SQL Server Migration Assistant.

Metodo 1: Migrazione con tempi di inattività durante la migrazione

Usare questo metodo se si è disposti a tollerare tempi di inattività o se si esegue una migrazione di prova di un database di produzione per una migrazione successiva. Per un'esercitazione, vedere Eseguire la migrazione di un database SQL Server.

L'elenco seguente illustra un flusso di lavoro generico per la migrazione di un database SQL Server con questo metodo.

Diagramma di migrazione di VSSSDT

  1. Valutare la compatibilità del database usando la versione più recente di Data Migration Assistant (DMA).
  2. Preparare eventuali correzioni necessarie come script Transact-SQL.
  3. Creare una copia del database di origine coerente a livello di transazione e assicurarsi che non vengano apportate ulteriori modifiche al database di origine. In alternativa, è possibile applicare manualmente le eventuali modifiche al termine della migrazione. Per disattivare un database sono disponibili vari metodi, dalla disabilitazione della connettività client alla creazione di uno snapshot del database.
  4. Distribuire gli script Transact-SQL per applicare le correzioni alla copia del database.
  5. Esportare la copia del database in un file BACPAC in un'unità locale.
  6. Importare il file BACPAC come nuovo database SQL di Azure usando uno dei tanti strumenti di importazione BACPAC disponibili. Lo strumento consigliato è SQLPackage.exe, che permette di ottenere prestazioni ottimali.

Ottimizzazione delle prestazioni di trasferimento dei dati durante la migrazione

L'elenco seguente contiene indicazioni che permettono di ottimizzare le prestazioni durante il processo di importazione.

  • Scegliere il livello di prestazioni e di servizio più elevato consentito 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.
  • Disabilitare le statistiche automatiche durante la migrazione.
  • Partizionare tabelle e indici.
  • Eliminare le viste indicizzate e ricrearle al termine della migrazione.
  • 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.

Ottimizzare le prestazioni al termine della migrazione

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

Metodo 2: Usare la 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 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 SQL di Azure. Al termine dello svuotamento delle eventuali modifiche rimaste nel database di origine da parte della replica transazionale, quando tutte le applicazioni puntano al database di Azure è possibile disinstallare la replica transazionale. Il database SQL di Azure è ora il sistema di produzione.

Diagramma di SeedCloudTR

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.

Migrazione al database SQL tramite il flusso di lavoro della replica transazionale

Importante

Usare sempre la versione più aggiornata di SQL Server Management Studio per restare sincronizzati con gli aggiornamenti di Microsoft Azure e del database SQL. Le versioni precedenti di SQL Server Management Studio non sono in grado di impostare il database SQL come sottoscrittore. Aggiornare SQL Server Management Studio.

  1. Configurare la distribuzione
  2. Creare la pubblicazione
  3. Creare la sottoscrizione

Suggerimenti e differenze per la migrazione al database SQL

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

Risoluzione dei problemi di compatibilità della migrazione di database

Esiste una vasta gamma di problemi di compatibilità che possono verificarsi, a seconda della versione del server SQL 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:

Oltre a ricerche su Internet e all'uso di queste risorse, usare il forum della community MSDN SQL Server o StackOverflow.

Passaggi successivi