Domande frequenti sull'uso del Servizio Migrazione del database di Azure

Il Servizio Migrazione del database di Azure è un servizio completamente gestito, progettato per abilitare le migrazioni senza interruzioni da più origini di database alle piattaforme di dati di Azure con tempi di inattività minimi. Il servizio è attualmente disponibile a livello generale, con progetti di sviluppo continuativi incentrati su:

• Affidabilità e prestazioni.
• Aggiunta iterativa di coppie origine-destinazione.
• Investimento continuo su migrazioni senza problemi.

Il servizio supporta attualmente varie coppie di origine/destinazione o scenari di migrazione. Per un elenco completo dello stato di ogni scenario di migrazione disponibile vedere l'articolo Stato degli scenari di migrazione supportati dal Servizio Migrazione del database di Azure.

Quando si esegue la migrazione da SQL Server, le origini supportate per il Servizio Migrazione del database di Azure sono SQL Server 2008 e versioni successive. Se si usa Azure Data Studio con l'estensione Migrazione SQL, le origini supportate sono da SQL Server 2008 a SQL Server 2022.

È possibile usare servizio Migrazione del database di Azure per eseguire migrazioni offline e online. Con una migrazione offline, i tempi di inattività dell'applicazione partono dall'inizio della migrazione. Con una migrazione online, il tempo di inattività è limitato al tempo di trasferimento al termine della migrazione. È consigliabile testare una migrazione offline per determinare se il tempo di inattività è accettabile. In caso contrario, eseguire una migrazione online.

Il Servizio Migrazione del database di Azure è il metodo preferito per la migrazione di database in Microsoft Azure su larga scala. Per altre informazioni sulle differenze tra il Servizio Migrazione del database di Azure e altri strumenti di migrazione di database Microsoft e per raccomandazioni sull'uso del servizio in diversi scenari, vedere Differenze tra gli strumenti e i servizi di migrazione di database di Microsoft.

Azure Migrate supporta la migrazione di macchine virtuali locali a IaaS di Azure. Il servizio valuta l'idoneità alla migrazione e il dimensionamento in base alle prestazioni e offre stime dei costi per l'esecuzione delle macchine virtuali locali in Azure. Azure Migrate è utile per le migrazioni in modalità lift-and-shift di carichi di lavoro basati su VM locali a VM IaaS di Azure. Tuttavia, a differenza del Servizio Migrazione del database di Azure, Azure Migrate non è un'offerta di servizio di migrazione di database specializzata per le piattaforme di database relazionale PaaS di Azure, ad esempio il database SQL di Azure, SQL Azure o Istanza gestita di SQL di Azure.

No. Il Servizio Migrazione del database non archivia i dati dei clienti.

Per le destinazioni della macchina virtuale SQL di Azure e dell'istanza gestita di SQL di Azure, Servizio Migrazione del database usa la migrazione fisica, ad esempio usando il backup e il ripristino. Come descritto di seguito, la modalità di migrazione scelta determina come i dati vengono mantenuti coerenti tra l'origine e la destinazione.

• Migrazione offline: durante la migrazione offline alla macchina virtuale SQL di Azure e alle destinazioni dell'istanza gestita di SQL di Azure, il tempo di inattività dell'applicazione inizia all'avvio della migrazione. Il servizio Migrazione del database ripristina tutti i file di backup nella destinazione, purché il file di backup o i file di backup più recenti dall'origine siano stati trasferiti all'archiviazione di rete SMB o al contenitore BLOB di Azure (in base alla configurazione della migrazione). Se il backup viene eseguito con l'opzione CHECKSUM, l'operazione di ripristino del Servizio Migrazione del database esegue automaticamente la convalida. In assenza di checksum, l'integrità del backup viene verificata in modo esplicito prima del ripristino. In questo modo, il file di ripristino è identico al file di backup e pertanto ha gli stessi dati. È possibile verificare tutti i file di backup, incluso l'ultimo nome del file di backup dall'origine, con il file di backup applicato/ripristino nella destinazione visualizzata nella pagina di monitoraggio della migrazione del Servizio Migrazione del Database di Azure e convalidare il rispettivo checksum.

• Migrazione online: durante la migrazione online alla macchina virtuale SQL di Azure e alle destinazioni dell'istanza gestita di SQL di Azure, il tempo di inattività inizia dopo aver avviato il cutover della migrazione insieme all'arresto dell'applicazione. Il servizio Migrazione del database ripristina tutti i file di backup nella destinazione, purché il file di backup o i file di backup più recenti dall'origine siano stati trasferiti all'archiviazione di rete SMB o al contenitore BLOB di Azure (in base alla configurazione della migrazione). Dopo aver premuto il pulsante cutover, servizio Migrazione del database mostra il numero di file di backup in sospeso (se presenti) presenti nell'archiviazione di rete SMB o nel contenitore BLOB di Azure e ancora da applicare/ripristinare nella destinazione. Se il backup viene eseguito con l'opzione CHECKSUM, l'operazione di ripristino del Servizio Migrazione del database esegue automaticamente la convalida. In assenza di checksum, l'integrità del backup viene verificata in modo esplicito prima del ripristino. In questo modo, il file di ripristino è identico al file di backup e pertanto ha gli stessi dati. È possibile verificare tutti i file di backup, incluso l'ultimo nome del file di backup dall'origine, con il file di backup applicato/ripristino nella destinazione visualizzata nella pagina di monitoraggio della migrazione del Servizio Migrazione del Database di Azure e convalidare il rispettivo checksum.

Per le destinazioni del database SQL di Azure, il Servizio Migrazione del database SQL di Azure esegue la migrazione logica nel caso del database SQL di Azure, ovvero copia i dati dalle tabelle del database SQL di origine e li scrive nelle tabelle del database SQL di Azure di destinazione. Poiché Il Servizio Migrazione del database supporta solo la migrazione offline al database SQL di Azure, il tempo di inattività dell'applicazione inizia all'avvio della migrazione. È possibile monitorare e convalidare il numero di righe lette (dalla tabella del database di origine) e copiate (scritte nella tabella del database SQL di Azure di destinazione) dalla pagina di monitoraggio della migrazione. Come conferma aggiuntiva, è possibile eseguire il TSQL seguente per ottenere il checksum sia nei database di origine che in quello di destinazione e convalidare che i dati di origine e ripristino siano identici.

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

Nota: purché nessuna applicazione stia scrivendo nel database di origine o di destinazione. È anche possibile usare strumenti come lo strumento confronto database per il confronto dei dati.

L'elenco seguente contiene le risorse di Azure che possono essere create in background per eseguire una migrazione dei dati. I servizi usati possono variare in base allo scenario di migrazione.

• Monitoraggio di Azure
• Macchina virtuale di Azure
• Archiviazione di Azure
• Bus di servizio di Azure
• Azure Data Factory

Internamente, Servizio Migrazione del database gestisce un archivio di metadati che include informazioni su percorsi di rete, credenziali, file di backup e attività completati. Le credenziali e i campi selezionati, ad esempio le chiavi dell'account, vengono crittografati. I dati, ad esempio i nomi di tabella che possono essere inclusi nei dati di telemetria, vengono con hash. I nomi utente possono essere visualizzati in testo normale nei log del servizio, ma le password non verranno mai visualizzate. I dati di telemetria sono silo per area, regolati dai criteri di conservazione e disponibili solo per il personale autorizzato all'interno di Microsoft per scopi validi per la risoluzione dei problemi. I nomi delle risorse di Azure, ad esempio i nomi di server e database, seguono le regole per le risorse di Azure.

Servizio Migrazione del database (versione classica) usa gli argomenti del bus di servizio di Azure per facilitare la comunicazione tra i livelli di calcolo. Gli argomenti del bus di servizio di Azure sono univoci per ogni istanza del Servizio Migrazione del database e tutti i dati personali vengono crittografati.

Istanza gestita di SQL di Azure e SQL Server in macchine virtuali di Azure

La migrazione dello schema e dei dati viene eseguita usando il backup e il ripristino. I clienti hanno la possibilità di eseguire il ripristino da una condivisione di rete o direttamente da un contenitore di archiviazione. Un file contenente i dati sulle prestazioni di Windows può essere utilizzato per fornire raccomandazioni facoltative (ma altamente consigliate) per il ridimensionamento del carico di lavoro.

Database SQL di Azure

Le migrazioni al database SQL di Azure vengono eseguite in due passaggi. Il primo passaggio è una migrazione dello schema. Servizio Migrazione del database (versione classica) usa SQL Management Objects (SMO) per la migrazione dello schema. Il secondo passaggio è la migrazione effettiva dei dati. SqlBulkCopy viene usato per eseguire la migrazione dei dati. Servizio Migrazione del database non supporta la migrazione dello schema. I dati vengono migrati usando Azure Data Factory. Facoltativamente, ma altamente consigliato, è possibile utilizzare un file contenente i dati sulle prestazioni di Windows per fornire raccomandazioni sul ridimensionamento del carico di lavoro.

Database di Azure per PostgreSQL

In questo scenario, l'utente finale estrae i metadati, in questo caso lo schema, usando le utilità della riga di comando pg_dump e pg_restore. Quando si configura Change Data Capture per PostgreSQL, il Servizio Migrazione del database usa internamente pg_dump e pg_restore per eseguire il seeding iniziale per CDC. I dati vengono archiviati in un archivio temporaneo crittografato accessibile solo all'istanza del Servizio Migrazione del database. Un file contenente i dati sulle prestazioni di Windows può essere utilizzato per fornire raccomandazioni facoltative (ma altamente consigliate) per il ridimensionamento del carico di lavoro.

Database di Azure per MySQL

In questo scenario, l'estrazione e la migrazione dello schema vengono eseguite dal Servizio Migrazione del database (versione classica) usando mysql-net/MySqlConnector. Laddove possibile, la replica binlog di MySQL viene usata per replicare sia i dati che le modifiche dello schema. Il codice personalizzato viene usato per sincronizzare le modifiche in cui non è possibile usare la replica binlog.

Da MongoDB ad Azure Cosmos DB

Servizio Migrazione del database estrae e inserisce dati da un MongoDB in Cosmos DB. Offre anche la possibilità di estrarre i dati da un dump BSON o JSON.

Per i dump BSON, Servizio Migrazione del database usa i dati in formato bsondump all'interno della stessa cartella all'interno di un contenitore BLOB. Servizio Migrazione del database cerca solo i file di metadati usando il formato collection.metadata.json.

Per i dump JSON, il Servizio Migrazione del database leggerà i file nelle cartelle del contenitore BLOB denominate dopo i database contenenti. All'interno di ogni cartella del database, servizio Migrazione del database usa solo i file di dati inseriti nella sottocartella data. Il Servizio Migrazione del database esamina solo i file inseriti nella sottocartella metadata e denominati usando il formato collection.json per i metadati.

Da Oracle al database SQL di Azure

In questo scenario, il report AWR o un file di Windows perfmon viene utilizzato per fornire raccomandazioni di ridimensionamento del carico di lavoro facoltative (ma altamente consigliate). L'utente che esegue la migrazione usa Database Schema Conversion Toolkit per eseguire una migrazione dello schema per preparare il database di destinazione.

Oracle in Database di Azure per PostgreSQL

Analogamente a Oracle al database SQL di Azure, in questo scenario, il report AWR o un file di Windows perfmon viene usato per fornire raccomandazioni di dimensionamento facoltative (ma altamente consigliate). La libreria ora2pg viene usata per estrarre lo schema ed eseguire manualmente la migrazione dei dati dall'utente che esegue la migrazione.

Servizio Migrazione del database (versione classica) si basa sulla configurazione di rete del cliente. Se l'origine della migrazione usa endpoint privati, si usano endpoint privati, ovvero la configurazione preferita. Gli endpoint pubblici vengono usati se sono l'unica opzione.

Il Servizio Migrazione del database usa ADF in modo pesante dietro le quinte per la pianificazione e il coordinamento dello spostamento dei dati. Inoltre, il runtime di integrazione self-hosted non è diverso da quello già usato per le pipeline di Azure Data Factory. Per altre informazioni sui problemi del firewall e del server proxy, vedere Creare e configurare un runtime di integrazione self-hosted.

Tutti i dati dei clienti vengono crittografati inattivi. Alcuni metadati, inclusi i nomi dei server logici e i nomi dei database, nonché lo stato di migrazione e lo stato della migrazione vengono visualizzati nei log del servizio non crittografati.

Tutti i dati in transito sono protetti con la crittografia TLS 1.2 per impostazione predefinita. I client legacy che richiedono versioni precedenti di TLS richiedono le versioni necessarie abilitate nella pagina del portale del Servizio Migrazione del database (versione classica). Per servizio Migrazione del database, è possibile configurare il computer in cui è installato il runtime di integrazione self-hosted per consentire alle impostazioni TLS necessarie di supportare i client legacy. Per altre informazioni sulla configurazione di TLS per SQL Server, vedere KB3135244 - Supporto di TLS 1.2 per Microsoft SQL Server.

Laddove possibile, vengono usati endpoint privati. Se gli endpoint privati non sono un'opzione, gli endpoint pubblici vengono usati per la comunicazione tra livelli di servizio. Indipendentemente dal tipo di endpoint, tutte le risorse sono dedicate/con ambito per l'istanza specifica del Servizio Migrazione del database e protette con credenziali univoche.

Le chiavi gestite dal cliente non sono supportate per la crittografia dei dati all'interno del piano dati o del piano di controllo. Tuttavia, tutti i dati dei clienti vengono crittografati inattivi usando chiavi gestite dal servizio. Alcuni metadati, inclusi i nomi dei server logici e i nomi dei database, nonché lo stato di migrazione e lo stato di avanzamento vengono visualizzati nei log del servizio in formato non crittografato.

Per impostazione predefinita, tutti i dati in transito vengono crittografati con la crittografia TLS 1.2. La pagina del portale del Servizio Migrazione del database (versione classica) consente l'uso di versioni precedenti di TLS per i client legacy. Per servizio Migrazione del database, il computer in cui è installato il runtime di integrazione self-hosted può essere configurato per consentire la gestione delle impostazioni TLS per supportare i client legacy. Per altre informazioni sulla configurazione di TLS per SQL Server, vedere KB3135244 - Supporto di TLS 1.2 per Microsoft SQL Server.

Non è possibile esporre la funzionalità per crittografare i dati nel piano dati o nel controllo con chiavi gestite dal cliente. Tutti i dati dei clienti vengono eliminati quando l'istanza del Servizio Migrazione del database viene eliminata, ad eccezione dei log del servizio. I log del servizio Servizio Migrazione del database vengono conservati solo per 30 giorni.

TDE

Servizio Migrazione del database supporta la migrazione di chiavi gestite dal cliente (CMK) ad Azure SQL per Transparent Database Encryption (TDE). Per istruzioni dettagliate sulla migrazione delle chiavi TDE, vedere Esercitazione: Eseguire la migrazione di database abilitati per TDE (anteprima) ad Azure SQL in Azure Data Studio.

Crittografia delle celle

La crittografia a livello di cella viene gestita a livello di schema. Gli strumenti di migrazione dello schema consentono di eseguire la migrazione di tutti gli oggetti schema, incluse le funzioni e le stored procedure necessarie per implementare la crittografia a livello di cella.

Always Encrypted

Il Servizio Migrazione del database non supporta attualmente la migrazione di Always Encrypted tramite scenari in cui viene eseguita la migrazione di singole righe di dati tra origine e destinazione. Le colonne crittografate tramite Always Encrypted vengono migrate come previsto negli scenari che usano backup/ripristino, ad esempio il passaggio alla macchina virtuale SQL di Azure o all'istanza gestita di SQL di Azure da un'istanza di SQL Server esistente.

Non vengono implementati controlli di accesso in grado di conoscere la posizione oltre a ciò che è già disponibile in Azure. Tutti i dati associati a un'istanza del Servizio Migrazione del database si trovano nella stessa area della risorsa del Servizio Migrazione del database.

I nostri servizi vengono usati in vari ambienti con diversi controlli interni e processi aziendali. Il Servizio Migrazione del database sposta i dati da e verso qualsiasi punto in cui l'account in uso abbia accesso. È responsabilità dell'utente comprendere le autorizzazioni e i controlli interni dell'ambiente in cui lavorano. È particolarmente importante assicurarsi che l'account usato dal Servizio Migrazione del database per connettersi all'origine abbia accesso per visualizzare tutti i dati di cui si intende eseguire la migrazione dall'origine.

L'inserimento della rete virtuale è l'azione di aggiunta di una risorsa di Azure che si trova all'interno del tenant Microsoft, a una subnet in una rete virtuale nel tenant del cliente. Questo approccio è stato adottato con Il Servizio Migrazione del database per consentire di gestire il calcolo per conto del cliente, mantenendo comunque l'accesso alle risorse dei clienti. Poiché la rete si trova nella sottoscrizione del cliente, Microsoft non può gestire la macchina virtuale oltre all'emissione di comandi Start, Stop, Delete o Deploy. Tutte le altre azioni di gestione che richiedono l'accesso alla macchina virtuale richiedono una richiesta di supporto e un'approvazione avviate dal cliente.

Esistono diversi prerequisiti obbligatori per assicurare che il Servizio Migrazione del database di Azure venga eseguito senza problemi quando si eseguono migrazioni di database. Alcuni dei prerequisiti si applicano a tutti gli scenari (coppie di origine-destinazione) supportati dal servizio, mentre altri prerequisiti sono univoci per uno scenario specifico.

In base ai prerequisiti del Servizio Migrazione del database di Azure comuni a tutti gli scenari di migrazione supportati, è necessario:

• Creare una rete virtuale di Microsoft Azure per il servizio Migrazione del database di Azure usando il modello di distribuzione Azure Resource Manager, che offre la connettività da sito a sito per i server di origine locali con ExpressRoute o VPN.
• Assicurarsi che le regole del gruppo di sicurezza di rete della rete virtuale non blocchino la porta 443 di ServiceTag per ServiceBus, Archiviazione e AzureMonitor. Per informazioni dettagliate sul filtro del traffico dei gruppi di sicurezza di rete della rete virtuale di Azure, vedere l'articolo Filtrare il traffico di rete con gruppi di sicurezza di rete.
• Quando si usa un'appliance firewall all'ingresso dei database di origine, potrebbe essere necessario aggiungere regole del firewall per consentire al Servizio Migrazione del database di Azure di accedere ai database di origine per la migrazione.

Per un elenco di tutti i prerequisiti obbligatori per supportare scenari di migrazione specifici con il Servizio Migrazione del database di Azure, vedere le esercitazioni correlate nella documentazione del Servizio Migrazione del database di Azure.

Potrebbe essere necessario aggiungere regole del firewall che consentono al Servizio Migrazione del database di Azure di accedere al database di origine per la migrazione. L'indirizzo IP per il servizio è dinamico, ma, se si usa Express Route, questo indirizzo viene assegnato privatamente dalla rete aziendale. Il modo più semplice per identificare l'indirizzo IP appropriato è cercare nello stesso gruppo di risorse della risorsa del Servizio Migrazione del database di Azure di cui viene effettuato il provisioning per trovare l'interfaccia di rete associata. Il nome della risorsa dell'interfaccia di rete inizia in genere con il prefisso NIC ed è seguito da una sequenza alfanumerica univoca, ad esempio `NIC-jj6tnztnmarpsskr82rbndyp``. Se si seleziona questa risorsa dell'interfaccia di rete, è possibile visualizzare l'indirizzo IP che deve essere incluso nell'elenco indirizzi consentiti nella pagina del portale di Azure della panoramica.

Potrebbe essere necessario includere nell'elenco indirizzi consentiti anche l'origine della porta su cui SQL Server è in ascolto. Per impostazione predefinita, si tratta della porta 1433, ma l'istanza di SQL Server di origine potrebbe essere configurata per l'ascolto anche su altre porte. In questo caso, è necessario includere anche tali porte nell'elenco indirizzi consentiti. È possibile determinare la porta su cui SQL Server è in ascolto usando una query DMV:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

È anche possibile determinare la porta su cui SQL Server è in ascolto eseguendo una query sul log degli errori di SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Oltre alle numerose esercitazioni Microsoft che illustrano il processo di configurazione di una rete virtuale, è disponibile la documentazione ufficiale nell'articoloRete virtuale di Azure.

Durante una semplice migrazione di database tipica, è necessario:

1. Creare uno o più database di destinazione.
2. Valutazione del/dei database di origine.
   • Per le migrazioni omogenee, valutare i database esistenti usando DMA.
   • Per le migrazioni eterogenee (da origini competi), valutare i database esistenti con SSMA. Si usa SSMA anche per convertire gli oggetti di database ed eseguire la migrazione dello schema alla piattaforma di destinazione.
3. Creare un'istanza del servizio Migrazione del database di Azure.
4. Creare un progetto di migrazione specificando i database di origine, i database di destinazione e le tabelle di cui eseguire la migrazione.
5. Avviare il caricamento completo.
6. Selezionare la convalida successiva.
7. Eseguire un passaggio manuale dell'ambiente di produzione al nuovo database basato sul cloud.

Se si verificano problemi di connessione al sistema di database di origine durante l'esecuzione di attività o la migrazione, creare una macchina virtuale nella stessa subnet della rete virtuale in cui è stata configurata l'istanza. Nella macchina virtuale dovrebbe essere possibile eseguire un test di connessione, ad esempio usando un file UDL per testare una connessione a SQL Server o scaricare Robo 3T per testare le connessioni MongoDB. Se il test di connessione ha esito positivo, non dovrebbe verificarsi alcun problema con la connessione al database di origine. Se il test di connessione ha esito negativo, contattare l'amministratore di rete.

Se l'utente arresta esplicitamente il Servizio Migrazione del database di Azure (DMS) o se il servizio rimane inattivo per 24 ore, viene attivato uno stato di arresto o sospensione automatica. In entrambi i casi, il servizio non è disponibile e risulterà in stato di arresto. Per riprendere l'esecuzione delle migrazioni attive, riavviare il servizio.

È possibile eseguire alcune operazioni per velocizzare la migrazione del database con il servizio:

Per Servizio Migrazione del database (classico)-

• Usare il piano tariffario per utilizzo generico per più CPU quando si crea l'istanza del servizio per consentire al servizio di sfruttare più vCPU per la parallelizzazione e un trasferimento dei dati più veloce.
• Aumentare temporaneamente le prestazioni dell'istanza di destinazione del database SQL di Azure passando allo SKU del piano Premium durante l'operazione di migrazione dei dati per ridurre al minimo la limitazione delle richieste del database SQL di Azure che potrebbe influire sulle attività di trasferimento dei dati quando si usano SKU di livello inferiore.

Per Il Servizio Migrazione del database

• Se si copiano backup dalla condivisione file locale all'archiviazione BLOB di Azure OPPURE durante l'esecuzione della migrazione al database SQL di Azure di destinazione, il Servizio Migrazione del database usa il nodo SHIR come calcolo. Assicurarsi quindi di monitorare l'utilizzo delle risorse del nodo SHIR.
• Aumentare temporaneamente le prestazioni dell'istanza di destinazione del database SQL di Azure passando allo SKU del piano Premium durante l'operazione di migrazione dei dati per ridurre al minimo la limitazione delle richieste del disco di database SQL di Azure che potrebbe influire sulle attività di trasferimento dei dati quando si usano SKU di livello inferiore.
• Per informazioni più dettagliate, vedere il blog.

Passaggi successivi

• Definizione del Servizio Migrazione del database di Azure.