Eseguire la migrazione di Oracle a Database di Azure per PostgreSQL

SI APPLICA A: Database di Azure per PostgreSQL - Server singolo Database di Azure per PostgreSQL - Server flessibile

Questa guida consente di eseguire la migrazione dello schema Oracle a Database di Azure per PostgreSQL.

Per informazioni dettagliate e complete sulla migrazione, vedere le risorse della guida alla migrazione.

Prerequisiti

Per eseguire la migrazione dello schema Oracle a Database di Azure per PostgreSQL, è necessario:

• Verificare che l'ambiente di origine sia supportato.
• Scaricare la versione più recente di ora2pg.
• Avere la versione più recente del modulo DBD.

Panoramica

PostgreSQL è uno dei database open source più avanzati del mondo. Questo articolo descrive come usare lo strumento ora2pg gratuito per eseguire la migrazione di un database Oracle a PostgreSQL. È possibile usare ora2pg per eseguire la migrazione di un database Oracle o di un database MySQL a uno schema compatibile con PostgreSQL.

Lo strumento ora2pg connette il database Oracle, lo analizza automaticamente ed estrae la struttura o i dati. Ora2pg genera quindi script SQL che è possibile caricare nel database PostgreSQL. È possibile usare ora2pg per attività come la progettazione inversa di un database Oracle, la migrazione di un database aziendale enorme o semplicemente la replica di alcuni dati Oracle in un database PostgreSQL. Lo strumento è facile da usare e non richiede alcuna conoscenza del database Oracle oltre alla possibilità di fornire i parametri necessari per connettersi al database Oracle.

Nota

Per altre informazioni sull'uso della versione più recente di ora2pg, vedere la documentazione ora2pg.

Architettura tipica della migrazione ora2pg

Dopo aver effettuato il provisioning della macchina virtuale e della Database di Azure per PostgreSQL, sono necessarie due configurazioni per abilitare la connettività tra di essi: Consentire l'accesso ai servizi di Azure e Applicare la connessione SSL:

• Pannello> Sicurezza connessione Consenti l'accesso ai servizi> di AzureON

• Pannello> Sicurezza connessione >IMPOSTAZIONI>SSL Applica connessione SSLDISABILITATa

Consigli

• Per migliorare le prestazioni delle operazioni di valutazione o esportazione nel server Oracle, raccogliere statistiche:

  BEGIN
  
     DBMS_STATS.GATHER_SCHEMA_STATS
     DBMS_STATS.GATHER_DATABASE_STATS
     DBMS_STATS.GATHER_DICTIONARY_STATS
     END;
  

• Esportare i dati usando il COPY comando anziché INSERT.

• Evitare l'esportazione di tabelle con chiavi esterne (FKS), vincoli e indici. Questi elementi rallentano il processo di importazione dei dati in PostgreSQL.

• Creare viste materializzate usando la clausola no data. Aggiornare quindi le visualizzazioni in un secondo momento.

• Se possibile, usare indici univoci nelle viste materializzate. Questi indici possono velocizzare l'aggiornamento quando si usa la sintassi REFRESH MATERIALIZED VIEW CONCURRENTLY.

Pre-migrazione

Dopo aver verificato che l'ambiente di origine sia supportato e che siano stati risolti tutti i prerequisiti, è possibile avviare la fase di premigration. Per iniziare:

1. Individuazione: inventariare i database di cui è necessario eseguire la migrazione.
2. Valutazione: valutare tali database per potenziali problemi di migrazione o blocchi.
3. Convert: risolvere tutti gli elementi rilevati.

Per le migrazioni eterogene, ad esempio Oracle a Database di Azure per PostgreSQL, questa fase comporta anche la compatibilità degli schemi del database di origine con l'ambiente di destinazione.

Rilevazione

L'obiettivo della fase di individuazione è identificare le origini dati esistenti e informazioni dettagliate sulle funzionalità usate. Questa fase consente di comprendere e pianificare meglio la migrazione. Il processo comporta l'analisi della rete per identificare tutte le istanze Oracle dell'organizzazione insieme alla versione e alle funzionalità in uso.

Script di pre-valutazione Microsoft per Oracle eseguiti nel database Oracle. Gli script di valutazione preliminare eseguono una query sui metadati Oracle. Gli script forniscono:

• Inventario del database, inclusi i conteggi degli oggetti in base allo schema, al tipo e allo stato.
• Stima approssimativa dei dati non elaborati in ogni schema, in base alle statistiche.
• Dimensioni delle tabelle in ogni schema.
• Numero di righe di codice per pacchetto, funzione, routine e così via.

Scaricare gli script correlati da github.

Valutazione

Dopo aver inventariato i database Oracle, si avrà un'idea delle dimensioni e delle potenziali sfide del database. Il passaggio successivo consiste nell'eseguire la valutazione.

La stima dei costi di una migrazione da Oracle a PostgreSQL non è facile. Per valutare il costo della migrazione, ora2pg controlla tutti gli oggetti, le funzioni e le stored procedure di database per gli oggetti e il codice PL/SQL che non è in grado di convertire automaticamente.

Lo strumento ora2pg ha una modalità di analisi del contenuto che controlla il database Oracle per generare un report di testo. Il report descrive cosa contiene il database Oracle e cosa non può essere esportato.

Per attivare l'analisi e la modalità report, usare il tipo SHOW_REPORT esportato come illustrato nel comando seguente:

ora2pg -t SHOW_REPORT

Lo strumento ora2pg può convertire il codice SQL e PL/SQL dalla sintassi Oracle a PostgreSQL. Quindi, dopo l'analisi del database, ora2pg può stimare le difficoltà del codice e il tempo necessario per eseguire la migrazione di un database completo.

Per stimare il costo della migrazione in giorni umani, ora2pg consente di usare una direttiva di configurazione denominata ESTIMATE_COST. È anche possibile abilitare questa direttiva al prompt dei comandi:

ora2pg -t SHOW_REPORT --estimate_cost

L'unità di migrazione predefinita rappresenta circa cinque minuti per un esperto PostgreSQL. Se questa migrazione è la prima, è possibile aumentare l'unità di migrazione predefinita usando la direttiva COST_UNIT_VALUE di configurazione o l'opzione della --cost_unit_value riga di comando.

L'ultima riga del report mostra il codice di migrazione stimato totale in giorni umani. La stima segue il numero di unità di migrazione stimate per ogni oggetto.

Nell'esempio di codice seguente vengono visualizzate alcune variazioni di valutazione:

• Valutazione tabelle
• Valutazione colonne
• Valutazione dello schema che usa un'unità di costo predefinita di 5 minuti
• Valutazione dello schema che usa un'unità di costo di 10 minuti

ora2pg -t SHOW_TABLE -c c:\ora2pg\ora2pg_hr.conf > c:\ts303\hr_migration\reports\tables.txt 
ora2pg -t SHOW_COLUMN -c c:\ora2pg\ora2pg_hr.conf > c:\ts303\hr_migration\reports\columns.txt
ora2pg -t SHOW_REPORT -c c:\ora2pg\ora2pg_hr.conf --dump_as_html --estimate_cost > c:\ts303\hr_migration\reports\report.html
ora2pg -t SHOW_REPORT -c c:\ora2pg\ora2pg_hr.conf –-cost_unit_value 10 --dump_as_html --estimate_cost > c:\ts303\hr_migration\reports\report2.html

Ecco l'output della migrazione della valutazione dello schema B-5:

• Livelli di migrazione:

  • R - Migrazione che può essere eseguita automaticamente

  • B - Migrazione con la riscrittura del codice e un costo dei giorni umani fino a 5 giorni

  • C - Migrazione con la riscrittura del codice e un costo dei giorni umani oltre 5 giorni

• Livelli tecnici:

  • 1 = Semplice: nessuna funzione archiviata e nessun trigger

  • 2 = Facile: nessuna funzione archiviata, ma trigger; nessuna riscrittura manuale

  • 3 = Semplice: funzioni archiviate e/o trigger; nessuna riscrittura manuale

  • 4 = Manuale: nessuna funzione archiviata, ma attiva o viste con la riscrittura del codice

  • 5 = Difficile: funzioni archiviate e/o trigger con la riscrittura del codice

La valutazione è costituita da:

• Lettera (A o B) per specificare se la migrazione deve riscrivere manualmente.

• Numero compreso tra 1 e 5 per indicare la difficoltà tecnica.

Un'altra opzione, , -human_days_limitspecifica il limite di giorni umani. In questo caso, impostare il livello di migrazione su C per indicare che la migrazione richiede una grande quantità di lavoro, la gestione completa dei progetti e il supporto della migrazione. Il valore predefinito è 10 giorni umani. È possibile usare la direttiva HUMAN_DAYS_LIMIT di configurazione per modificare definitivamente questo valore predefinito.

Questa valutazione dello schema è stata sviluppata per aiutare gli utenti a decidere quale database eseguire la migrazione prima e quali team mobilizzare.

Conversione

Nelle migrazioni con tempi di inattività minimi, l'origine della migrazione cambia. Deriva dalla destinazione in termini di dati e schema dopo la migrazione una sola volta. Durante la fase di sincronizzazione dati assicurarsi che tutte le modifiche nell'origine vengano acquisite e applicate alla destinazione in tempo quasi reale. Dopo aver verificato che tutte le modifiche vengono applicate alla destinazione, è possibile passare dall'origine all'ambiente di destinazione.

In questo passaggio della migrazione, il codice Oracle e gli script DDL vengono convertiti o convertiti in PostgreSQL. Lo strumento ora2pg esporta automaticamente gli oggetti Oracle in formato PostgreSQL. Alcuni degli oggetti generati non possono essere compilati nel database PostgreSQL senza modifiche manuali.

Per comprendere quali elementi richiedono un intervento manuale, compilare prima di tutto i file generati da ora2pg nel database PostgreSQL. Controllare il log e quindi apportare modifiche necessarie fino a quando la struttura dello schema non è compatibile con la sintassi PostgreSQL.

Creare un modello di migrazione

È consigliabile usare il modello di migrazione fornito da ora2pg. Quando si usano le opzioni --project_base e --init_project, ora2pg crea un modello di progetto con un albero di lavoro, un file di configurazione e uno script per esportare tutti gli oggetti dal database Oracle. Per altre informazioni, vedere la documentazione ora2pg.

Usare il comando seguente:

ora2pg --project_base /app/migration/ --init_project test_project

Ecco l'output dell'esempio:

ora2pg --project_base /app/migration/ --init_project test_project
        Creating project test_project.
        /app/migration/test_project/
                schema/
                        dblinks/
                        directories/
                        functions/
                        grants/
                        mviews/
                        packages/
                        partitions/
                        procedures/
                        sequences/
                        synonyms/
                        tables/
                        tablespaces/
                        triggers/
                        types/
                        views/
                sources/
                        functions/
                        mviews/
                        packages/
                        partitions/
                        procedures/
                        triggers/
                        types/
                        views/
                data/
                config/
                reports/

        Generating generic configuration file
        Creating script export_schema.sh to automate all exports.
        Creating script import_all.sh to automate all imports.

La sources/ directory contiene il codice Oracle. La schema/ directory contiene il codice convertito in PostgreSQL. reports/ La directory contiene i report HTML e la valutazione dei costi di migrazione.

Dopo aver creato la struttura del progetto, viene creato un file di configurazione generico. Definire la connessione al database Oracle e i parametri di configurazione pertinenti nel file di configurazione. Per altre informazioni sul file di configurazione, vedere la documentazione ora2pg.

Esportare oggetti Oracle

Esportare quindi gli oggetti Oracle come oggetti PostgreSQL eseguendo il file export_schema.sh.

cd /app/migration/mig_project
./export_schema.sh

Eseguire manualmente il comando seguente.

SET namespace="/app/migration/mig_project"

ora2pg -p -t DBLINK -o dblink.sql -b %namespace%/schema/dblinks -c %namespace%/config/ora2pg.conf
ora2pg -p -t DIRECTORY -o directory.sql -b %namespace%/schema/directories -c %namespace%/config/ora2pg.conf
ora2pg -p -t FUNCTION -o functions2.sql -b %namespace%/schema/functions -c %namespace%/config/ora2pg.conf 
ora2pg -p -t GRANT -o grants.sql -b %namespace%/schema/grants -c %namespace%/config/ora2pg.conf 
ora2pg -p -t MVIEW -o mview.sql -b %namespace%/schema/mviews -c %namespace%/config/ora2pg.conf
ora2pg -p -t PACKAGE -o packages.sql -b %namespace%/schema/packages -c %namespace%/config/ora2pg.conf
ora2pg -p -t PARTITION -o partitions.sql -b %namespace%/schema/partitions -c %namespace%/config/ora2pg.conf
ora2pg -p -t PROCEDURE -o procs.sql -b %namespace%/schema/procedures -c %namespace%/config/ora2pg.conf
ora2pg -p -t SEQUENCE -o sequences.sql -b %namespace%/schema/sequences -c %namespace%/config/ora2pg.conf
ora2pg -p -t SYNONYM -o synonym.sql -b %namespace%/schema/synonyms -c %namespace%/config/ora2pg.conf
ora2pg -p -t TABLE -o table.sql -b %namespace%/schema/tables -c %namespace%/config/ora2pg.conf 
ora2pg -p -t TABLESPACE -o tablespaces.sql -b %namespace%/schema/tablespaces -c %namespace%/config/ora2pg.conf
ora2pg -p -t TRIGGER -o triggers.sql -b %namespace%/schema/triggers -c %namespace%/config/ora2pg.conf 
ora2pg -p -t TYPE -o types.sql -b %namespace%/schema/types -c %namespace%/config/ora2pg.conf 
ora2pg -p -t VIEW -o views.sql -b %namespace%/schema/views -c %namespace%/config/ora2pg.conf

Per estrarre i dati, usare il comando seguente.

ora2pg -t COPY -o data.sql -b %namespace%/data -c %namespace/config/ora2pg.conf

Compilare file

Infine, compilare tutti i file nel server di Database di Azure per PostgreSQL. È possibile scegliere di caricare i file DDL generati manualmente o usare il secondo script import_all.sh per importare i file in modo interattivo.

psql -f %namespace%\schema\sequences\sequence.sql -h server1-server.postgres.database.azure.com -p 5432 -U username@server1-server -d database -L %namespace%\ schema\sequences\create_sequences.log

psql -f %namespace%\schema\tables\table.sql -h server1-server.postgres.database.azure.com -p 5432 -U username@server1-server -d database -L %namespace%\schema\tables\create_table.log

Ecco il comando di importazione dei dati:

psql -f %namespace%\data\table1.sql -h server1-server.postgres.database.azure.com -p 5432 -U username@server1-server -d database -l %namespace%\data\table1.log

psql -f %namespace%\data\table2.sql -h server1-server.postgres.database.azure.com -p 5432 -U username@server1-server -d database -l %namespace%\data\table2.log

Mentre i file vengono compilati, controllare i log e correggere qualsiasi sintassi che ora2pg non è riuscito a convertire autonomamente.

Per altre informazioni, vedere Oracle per Database di Azure per PostgreSQL soluzioni alternative alla migrazione.

Migrate

Dopo aver completato i prerequisiti necessari e aver completato i passaggi di premigration, è possibile avviare lo schema e la migrazione dei dati.

Eseguire la migrazione dello schema e dei dati

Dopo aver apportato le correzioni necessarie, una compilazione stabile del database è pronta per la distribuzione. Eseguire i psql comandi di importazione, puntando ai file che contengono il codice modificato. Questa attività compila gli oggetti di database nel database PostgreSQL e importa i dati.

In questo passaggio è possibile implementare un livello di parallelismo per importare i dati.

Sincronizzare i dati e tagliare

Nelle migrazioni online (tempo di inattività minimo) l'origine della migrazione continua a cambiare. Deriva dalla destinazione in termini di dati e schema dopo la migrazione una sola volta.

Durante la fase di sincronizzazione dati assicurarsi che tutte le modifiche nell'origine vengano acquisite e applicate alla destinazione in tempo quasi reale. Dopo aver verificato che tutte le modifiche vengono applicate, è possibile passare dall'origine all'ambiente di destinazione.

Per eseguire una migrazione online, contattare AskAzureDBforPostgreSQL@service.microsoft.com il supporto tecnico.

In una migrazione delta/incrementale che usa ora2pg, per ogni tabella, usare una query che filtra (tagli) in base alla data, all'ora o a un altro parametro. Completare quindi la migrazione usando una seconda query che esegue la migrazione dei dati rimanenti.

Nella tabella dati di origine eseguire prima la migrazione di tutti i dati cronologici. Ecco un esempio:

select * from table1 where filter_data < 01/01/2019

È possibile eseguire query sulle modifiche dopo la migrazione iniziale eseguendo un comando simile al seguente:

select * from table1 where filter_data >= 01/01/2019

In questo caso, è consigliabile migliorare la convalida controllando la parità dei dati su entrambi i lati, l'origine e la destinazione.

Post-migrazione

Dopo la fase di migrazione , completare le attività post-migrazione per garantire che tutto funzioni in modo uniforme ed efficiente.

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. L'installazione a volte richiede modifiche alle applicazioni.

Test

Dopo la migrazione dei dati alla destinazione, eseguire test sui database per verificare che le applicazioni funzionino correttamente con la destinazione. Assicurarsi che l'origine e la destinazione siano migrate correttamente eseguendo gli script di convalida dei dati manuali nei database di destinazione oracle e PostgreSQL.

Idealmente, se i database di origine e di destinazione hanno un percorso di rete, ora2pg deve essere usato per la convalida dei dati. È possibile usare l'azione TEST per assicurarsi che tutti gli oggetti del database Oracle siano stati creati in PostgreSQL.

Eseguire questo comando:

ora2pg -t TEST -c config/ora2pg.conf > migration_diff.txt

Ottimizzazione

La fase post-migrazione è fondamentale per riconciliare eventuali problemi di accuratezza dei dati e verificare la completezza. In questa fase vengono inoltre risolti problemi di prestazioni con il carico di lavoro.

Risorse per la migrazione

Per altre informazioni su questo scenario di migrazione, vedere le risorse seguenti. Supportano il coinvolgimento del progetto di migrazione reale.

Risorsa	Descrizione
Oracle to Azure PostgreSQL migration cookbook	Questo documento consente agli architetti, ai consulenti, agli amministratori del database e ai ruoli correlati di eseguire rapidamente la migrazione dei carichi di lavoro da Oracle a Database di Azure per PostgreSQL usando ora2pg.
Soluzioni alternative per la migrazione di Oracle a PostgreSQL di Azure	Questo documento consente agli architetti, ai consulenti, agli amministratori del database e ai ruoli correlati di risolvere rapidamente o risolvere i problemi durante la migrazione dei carichi di lavoro da Oracle a Database di Azure per PostgreSQL.
Passaggi per installare ora2pg in Windows o Linux	Questo documento fornisce una guida di installazione rapida per la migrazione di schemi e dati da Oracle a Database di Azure per PostgreSQL usando ora2pg in Windows o Linux. Per altre informazioni, vedere la documentazione ora2pg.

Queste risorse sono state progettate dal team di progettazione dei dati di SQL. La carta principale del team consiste nel sbloccare e accelerare la modernizzazione complessa per i progetti di migrazione della piattaforma dati di Microsoft Azure alla piattaforma dati di Microsoft Azure.

Altro supporto

Per informazioni sulla migrazione oltre l'ambito dello strumento ora2pg, contattare @Ask database di Azure per PostgreSQL.

Passaggi successivi

Per una matrice di servizi e strumenti per la migrazione dei dati e del database e per le attività speciali, vedere Servizi e strumenti per la migrazione dei dati.

Documentazione:

• Documentazione del Database di Azure per PostgreSQL
• Documentazione ora2pg
• Sito Web PostgreSQL
• Supporto delle transazioni autonome in PostgreSQL