Migrazione dei dati da Oracle a Cloud SQL per MySQL

Questo documento fa parte di una serie che mostra come eseguire la migrazione dei dati da Oracle a Cloud SQL per MySQL. I seguenti documenti della serie approfondiscono:

Preparazione alla migrazione dei dati

Questa sezione si concentra su come eseguire la migrazione dei dati da Oracle a Cloud SQL per MySQL. I seguenti prerequisiti sono fondamentali per evitare problemi durante la migrazione live:

  • La conversione dello schema da Oracle a Cloud SQL per MySQL è stata eseguita per tutti gli oggetti di database, inclusi tabelle, viste, procedure archiviate e funzioni.
  • Lo schema di destinazione è stato testato con alcuni dati di esempio per garantire che possa contenere gli stessi dati dello schema di origine.

Esistono due metodi di base per eseguire la migrazione dei dati: carico una tantum e replica in tempo reale. Il metodo di caricamento unico è il luogo in cui puoi esportare i dati esistenti da Oracle e importarli in MySQL. Il metodo di replica in tempo reale consente di copiare immediatamente i dati da Oracle a MySQL durante la generazione.

Per il metodo di caricamento una tantum, il database di origine deve essere aperto solo per le scritture durante questo processo. Pertanto, questo metodo è noto anche come migrazione dei dati offline. Uno degli strumenti più diffusi per l'esportazione di dati da Oracle è Oracle SQL Developer. Questo strumento può esportare dati dalle tabelle Oracle in diversi formati, tra cui istruzioni di inserimento CSV e SQL. In alternativa, puoi utilizzare SQL*Plus per selezionare e formattare i dati, quindi spoolarli in un file. Dopo che i dati sono stati esportati da Oracle in un file semplice, puoi caricarli in MySQL utilizzando il comando LOAD DATA INFILE. Questo metodo è spesso il meno costoso, ma può comportare più input manuali ed essere più lento rispetto a uno strumento di migrazione. e durante la migrazione.

Al contrario, il metodo di replica in tempo reale, noto anche come modifica dell'acquisizione di dati, è un metodo di migrazione dei dati online. Durante la copia iniziale dei dati, il database di origine rimane aperto. Un prodotto di replica acquisisce le modifiche ai dati mentre vengono effettuate sul database di origine e le trasferisce, poi applica queste modifiche al database di destinazione. Per le migrazioni dei dati di produzione, puoi utilizzare questo metodo per ridurre al minimo i tempi di inattività richiesti e garantire un tempo di inattività pressoché zero prima che si verifichi il cutover. Questo metodo comporta l'utilizzo di un prodotto di acquisizione dati CDC (Change Data Capture) di terze parti come GoldenGate, Striim o Informatica Data Replication.

Per consentire CDC da Oracle come database di origine, consigliamo di abilitare il logging supplementare a livello di database con il comando seguente:

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Database altered.

Questo comando fa sì che i file di log di ripetizione registrino dati di colonne aggiuntivi in aggiunta alle solite colonne primarie o indici univoci.

Puoi utilizzare un prodotto CDC di terze parti sia per il passaggio iniziale del caricamento, che trasferisce tutti i dati esistenti (fino a più TB di dati) dall'ambiente di database di origine di Oracle, sia per acquisire le modifiche dei dati in corso finché entrambi gli ambienti non sono sincronizzati, prima di eseguire il passaggio tra le due piattaforme. In genere un prodotto CDC fornisce funzionalità aggiuntive, come conversioni di tipo dati e altre semplici trasformazioni.

Esecuzione della migrazione dei dati

Quando esegui la migrazione dei dati, segui queste linee guida, la maggior parte delle quali si applicano ai metodi di replica una tantum e di caricamento in tempo reale:

  • Set di caratteri: assicurati che i set di caratteri compatibili tra il database Oracle di origine e il database MySQL target siano compatibili.
  • Chiavi esterne: per velocizzare l'importazione, disattiva temporaneamente i vincoli relativi alle chiavi esterne sul database MySQL di destinazione. Quando il carico è completato, abilita i vincoli delle chiavi esterne.
  • Indici: come per le chiavi esterne, anche gli indici presenti nel database MySQL di destinazione possono rallentare in modo significativo il caricamento iniziale. Assicurati che gli indici non vengano creati sul database di destinazione fino al completamento del caricamento iniziale.
  • Sequenze orali: MySQL supporta AUTO_INCREMENT invece delle sequenze. Assicurati che gli attributi AUTO_INCREMENT siano disabilitati durante il caricamento iniziale per evitare di sovrascrivere i valori generati dalla sequenza di Oracle. Aggiungi l'attributo AUTO_INCREMENT alla colonna della chiave primaria al termine del caricamento iniziale.
  • Connettività di rete: se utilizzi CDC, assicurati che sia l'ambiente di origine che quello di destinazione possano stabilire una connessione di rete al prodotto CDC per consentire l'acquisizione dei dati sul lato Oracle e il caricamento dei dati sul lato Cloud SQL per MySQL.

Caso d'uso di GoldenGate

Questa sezione analizza più dettagliatamente che cos'è una migrazione online a Cloud SQL basata sull'utilizzo dell'offerta CDC di Oracle, GoldenGate. Il primo passaggio consiste nel preparare l'ambiente per GoldenGate installando GoldenGate sia sui sistemi di origine che di destinazione. Sul lato sorgente, puoi installare l'applicazione sul server Oracle o su un server remoto che si connette al database Oracle tramite una connessione SQL*Net. Per eseguire l'applicazione GoldenGate, devi utilizzare una VM temporanea su Google Cloud perché non puoi installare GoldenGate direttamente sulla macchina Cloud SQL. GoldenGate viene fornito con un'utilità a riga di comando GGSCI, che consente di configurare ed eseguire vari processi di GoldenGate.

Dopo aver configurato l'ambiente, devi configurare e aggiungere il processo EXTRACT per acquisire le modifiche dei dati. Eseguiamo questa operazione prima di avviare il caricamento dei dati iniziale in modo che le modifiche transazionali in corso non vengano perse mentre il caricamento è in esecuzione. Come citato in precedenza, CDC richiede l'abilitazione del logging supplementare nel database Oracle di origine. Le transazioni impegnate vengono acquisite dai log di ripetizione, tradotte in logical change records (LCRs) e scritte in locale i file di traccia e nell'area temporanea di Google Cloud (VM di Google). Dovrai comprendere come ridimensionare i file di traccia in modo che vengano conservati per un tempo sufficiente senza consumare tutto lo spazio su disco disponibile.

Il passaggio successivo prevede la configurazione del processo di acquisizione GoldenGate noto come EXTRACT per eseguire il caricamento iniziale dei dati. Ciò include la creazione di un file di parametri che specifica un elenco di mappature tra le tabelle di origine in Oracle e le tabelle di destinazione in MySQL (ad esempio, MAP schema/table to TARGET database.table). A differenza di CDC, il carico iniziale utilizza le tabelle di origine e non i log di ripetizione per derivare i dati di origine. Eseguiamo la procedura di caricamento iniziale avviando la procedura EXTRACT e verificando i risultati. La durata del caricamento iniziale sarà un fattore del volume di dati e della velocità effettiva di rete.

Una volta completato il caricamento iniziale dei dati, devi configurare la pubblicazione delle modifiche, ovvero la procedura di applicazione di LCRs al database MySQL di destinazione. Il processo REPLICAT legge tali record dai file di traccia remoti, li converte in istruzioni DML e DDL e li applica al database MySQL di destinazione. Il processo REPLICAT prevede un proprio file di parametri, che include una sezione su come gestire le collisioni e altre eccezioni.

Il modo più semplice per determinare il funzionamento della replica dei dati è eseguire un conteggio delle righe su una tabella di origine e confrontare i risultati con la rispettiva tabella di destinazione. GGSCI dispone di un comando per rapporti e statistiche che consente di visualizzare statistiche ed errori di replica.

Criteri di successo

La migrazione dei dati (offline o online) deve essere considerata una soluzione riuscita solo se sono stati soddisfatti i seguenti criteri:

  • I trasferimenti di dati si sono verificati senza errori o procedure non riuscite.
  • Se utilizzi un caricamento una tantum, la durata del carico non ha superato la finestra di inattività consentita.
  • Se stavi utilizzando CDC, gli utenti dell'applicazione non hanno riscontrato un hit delle prestazioni durante il caricamento iniziale.
  • Se stavi utilizzando CDC, il tempo di replica è diminuito nel tempo, in modo tale che il database di destinazione alla fine abbia raggiunto il database di origine.

Verifica dell'integrità dei dati dopo la migrazione

In questa fase, dovresti identificare eventuali problemi e incoerenze con l'ambiente MySQL di destinazione in modo da poter risolvere rapidamente eventuali discrepanze tra i dati. Segui questi passaggi:

  1. Confronta il numero di righe tra le tabelle del database di origine e di destinazione per identificare eventuali lacune. Oltre a eseguire count, puoi anche eseguire sum, avg, min e max sullo stesso set di tabelle.
  2. Esegui istruzioni SQL utilizzate di frequente nell'ambiente MySQL di destinazione per assicurarti che i dati corrispondano al database Oracle di origine.
  3. Connetti l'applicazione ai database di origine e di destinazione e verifica che i risultati corrispondano.

Passaggi successivi