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

Servizio Migrazione del database di Azure è un servizio completamente gestito progettato per consentire migrazioni senza problemi da più origini di database alle piattaforme dati di Azure con tempi di inattività minimi. Il servizio è attualmente disponibile a livello generale, con attività di sviluppo in corso incentrate 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 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 , il tempo di inattività dell'applicazione inizia all'avvio della migrazione. Con una migrazione online , il tempo di inattività è limitato al tempo necessario per il taglio alla fine della migrazione. È consigliabile testare una migrazione offline per determinare se il tempo di inattività è accettabile. In caso contrario, eseguire una migrazione online.

Servizio Migrazione del database di Azure è il metodo preferito per la migrazione del database a Microsoft Azure su larga scala. Per altre informazioni su come Servizio Migrazione del database di Azure confrontare con altri strumenti di migrazione del database Microsoft e per consigli sull'uso del servizio per diversi scenari, vedere Differenze tra Strumenti e servizi di migrazione del database microsoft.

Azure Migrate supporta la migrazione di macchine virtuali locali ad Azure IaaS. 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 di Servizio Migrazione del database di Azure, Azure Migrate non è un servizio di migrazione di database specializzato che offre per piattaforme di database relazionali PaaS di Azure, ad esempio database SQL di Azure o Istanza gestita di SQL di Azure.

No. 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/s (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/s stia scrivendo nel database di origine o di destinazione. È anche possibile sfruttare 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 bus di servizio di Azure argomenti per facilitare la comunicazione tra livelli di calcolo. Gli argomenti 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 Azure Macchine virtuali

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 a 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 pg_dump riga di comando e pg_restore . Quando si configura Change Data Capture per PostgreSQL, il Servizio Migrazione del database usa pg_dump internamente 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/MySql Connessione or. 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 bsondump formato 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 data sottocartella. Servizio Migrazione del database esamina solo i file inseriti nella metadata sottocartella e denominati usando il formato collection.json per i metadati.

Da Oracle a 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 il Toolkit di conversione schema di database per eseguire una migrazione dello schema per preparare il database di destinazione.

Da Oracle a Database di Azure per PostgreSQL

Molto simile a Oracle a database SQL di Azure, in questo scenario, il report AWR o un file di Windows perfmon viene utilizzato per fornire raccomandazioni di dimensionamento facoltative (ma altamente consigliate). La ora2pg libreria 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 relativi al firewall e al 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 necessari per garantire che 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 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 necessari per competere scenari di migrazione specifici usando Servizio Migrazione del database di Azure, vedere le esercitazioni correlate nella documentazione di Servizio Migrazione del database di Azure.

Potrebbe essere necessario aggiungere regole del firewall che consentono 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 ExpressRoute, questo indirizzo viene assegnato privatamente dalla rete aziendale. Il modo più semplice per identificare l'indirizzo IP appropriato consiste nell'esaminare lo stesso gruppo di risorse della risorsa di cui è stato effettuato il provisioning Servizio Migrazione del database di Azure per trovare l'interfaccia di rete associata. In genere il nome della risorsa interfaccia di rete inizia con il prefisso NIC e seguito da una sequenza di caratteri e numeri univoci, ad esempio 'NIC-jj6tnztnmarpsskr82rbndyp''. Selezionando questa risorsa dell'interfaccia di rete, è possibile visualizzare l'indirizzo IP che deve essere incluso nell'elenco elementi consentiti nella pagina di panoramica delle risorse portale di Azure.

Potrebbe anche essere necessario includere l'origine porta in ascolto di SQL Server nell'elenco elementi consentiti. 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 elementi 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

Mentre più esercitazioni Microsoft che possono illustrare il processo di configurazione di una rete virtuale, la documentazione ufficiale viene visualizzata nell'articolo Azure Rete virtuale.

Durante una semplice migrazione di database tipica, è necessario:

1. Creare uno o più database di destinazione.
2. Valutare i 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 anche SSMA 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 che specifica 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 la migrazione, creare una macchina virtuale nella stessa subnet della rete virtuale con cui si configura l'istanza del Servizio Migrazione del database. 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 in modo esplicito Servizio Migrazione del database di Azure (SERVIZIO Migrazione del database) o se il servizio è inattivo per 24 ore, il servizio si trova in uno stato arrestato o in pausa automatica. In ogni caso, il servizio non è disponibile e in uno stato arrestato. Per riprendere l'esecuzione delle migrazioni attive, riavviare il servizio.

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

• 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 l'istanza di destinazione database SQL di Azure allo SKU del livello Premium durante l'operazione di migrazione dei dati per ridurre al minimo database SQL di Azure limitazione che può influire sulle attività di trasferimento dei dati quando si usano SKU di livello inferiore.

Passaggi successivi

• Qual è la Servizio Migrazione del database di Azure.