Procedure consigliate per la conversione dello schema da Oracle al server flessibile di Database di Azure per PostgreSQL

Questo articolo fornisce procedure consigliate e raccomandazioni per la funzionalità di conversione dello schema da Oracle ad Database di Azure per PostgreSQL in Visual Studio Code con Microsoft Foundry. Seguire queste linee guida per ottenere risultati affidabili e di alta qualità.

Pianificare la conversione dello schema

Una conversione riuscita inizia con la pianificazione. Decidi cosa convertire, come iterare e a quale destinazione di Database di Azure per PostgreSQL allinearti prima di eseguire lo strumento.

Definire l'ambito degli schemi di origine

Specificare gli schemi dell'applicazione Oracle da convertire. Il flusso di lavoro di estrazione esclude automaticamente il sistema Oracle e gli schemi predefiniti, ad esempio SYS, SYSTEMXDB, MDSYS, CTXSYS, e WMSYS.

Allineare la versione principale di PostgreSQL di destinazione

Usare nel database scratch la stessa versione major di PostgreSQL usata nel server flessibile Database di Azure per PostgreSQL di destinazione per la produzione. Lo strumento di conversione genera DDL destinato a una versione principale di PostgreSQL specifica. La conversione in una versione principale e la distribuzione in un'altra possono presentare differenze di sintassi o funzionalità durante la distribuzione.

Analizzare in anticipo gli oggetti non supportati

Esaminare Oracle per Database di Azure per PostgreSQL limitazioni di conversione dello schema del server flessibile prima di iniziare. Per ogni oggetto non supportato, decidere in anticipo se ricreare la funzionalità in modo nativo in PostgreSQL, riformularla in un servizio di Azure appropriato o eliminarla dall'ambito di migrazione.

Pianificare la correzione per gli oggetti non supportati

Per ogni oggetto non supportato identificato nel passaggio precedente, registrare il percorso di correzione scelto prima di eseguire la conversione. Traccia:

• Nome e tipo dell'oggetto Oracle.
• L'approccio scelto: ricreare, ripiattaformare o abbandonare.
• Il servizio Azure di destinazione o lo schema PostgreSQL, se si sta eseguendo il replatforming.

Scegliere dove eseguire la conversione

Per schemi di piccole dimensioni, è possibile eseguire la conversione dalla workstation locale. Per schemi di dimensioni maggiori, eseguire Visual Studio Code e lo strumento di conversione dello schema in una macchina virtuale Azure.

Una conversione di grandi dimensioni viene eseguita per molto tempo e effettua chiamate sostenute all'origine Oracle, al database scratch e Microsoft Foundry. L'esecuzione da una macchina virtuale Azure offre:

• Prossimità di rete: la macchina virtuale si trova nella stessa area Azure del server flessibile Database di Azure per PostgreSQL e della risorsa foundry Microsoft, riducendo la latenza di round trip sulle numerose chiamate effettuate da una conversione.
• Sessioni stabili e a esecuzione prolungata: la conversione non viene interrotta dalla sospensione della workstation, dai riavvii, dalle interruzioni vpn o dai timeout della rete aziendale.
• Connettività privata: è possibile posizionare la macchina virtuale nella stessa rete virtuale del server di destinazione e Microsoft endpoint privato Foundry, quindi il traffico non attraversa la rete Internet pubblica.
• Risorse prevedibili: è possibile ridimensionare CPU, memoria e disco per il carico di lavoro di conversione e mantenere gli artefatti in un disco gestito di cui si esegue il backup.

Posizionare la macchina virtuale nell'area che ospita il database scratch e concedere alla rete l'accesso alla rete al database Oracle di origine. Se si usa la modalità client spessa, installare Oracle Instant Client nella macchina virtuale. Per altre informazioni, vedere Modalità di connettività Oracle.

Preparare l'ambiente Oracle di origine

Prima di eseguire una conversione, preparare l'ambiente Oracle di origine. Concedere allo strumento di conversione i privilegi necessari per leggere i metadati dello schema e verificare che la capacità di sessione simultanea sia sufficiente in modo che lo strumento possa estrarre uno schema completo e accurato.

Privilegi Oracle obbligatori

L'utente di connessione Oracle usato dallo strumento di conversione richiede l'accesso in lettura al catalogo di metadati Oracle. Lo strumento legge i metadati dello schema dalle DBA_* viste del catalogo.

Concedere SELECT_CATALOG_ROLE o SELECT ANY DICTIONARY affinché l'utente possa leggere le viste DBA_* necessarie. Usare l'accesso con privilegi minimi in base ai criteri dell'organizzazione. L'utente non ha bisogno di privilegi per alcuna tabella dell'applicazione o per leggere i dati a livello di riga. Lo strumento non esegue mai query sui dati dell'applicazione; legge solo i metadati dello schema.

Impostare il parametro sessioni Oracle

Assicurarsi che il parametro Oracle sessions sia maggiore di 10 in modo che lo strumento possa aprire sufficienti letture simultanee di metadati. Controllare il valore corrente con:

SELECT name, value
FROM v$parameter
WHERE name = 'sessions';

Preparare il database scratch

Lo strumento di conversione dello schema usa un database scratch in Database di Azure per PostgreSQL server flessibile per convalidare gli oggetti convertiti. Effettuare il provisioning e configurare il server prima di avviare una conversione in modo che il comportamento di convalida corrisponda alla destinazione di produzione finale.

Privilegi PostgreSQL necessari

L'utente di connessione PostgreSQL usato dallo strumento di conversione richiede privilegi per creare e convalidare oggetti nel database scratch:

• L'appartenenza al ruolo azure_pg_admin, necessaria per creare le estensioni da cui dipende lo strumento.
• Privilegi CREATE e USAGE sullo schema scratch, in modo che lo strumento possa creare oggetti convertiti per la convalida.
• Privilegio CONNECT nel database scratch.

Scegliere una dimensione del database scratch appropriata

Il database scratch convalida solo DDL; non ospita il carico di lavoro dell'applicazione. Usare un livello di calcolo che fornisce capacità di connessione stabile per l'attività di conversione e convalida. Dimensionare il database scratch separatamente rispetto alla destinazione di produzione e ridimensionarlo una volta completata la conversione.

Allowlist e installare le estensioni necessarie

Lo strumento di conversione dello schema dipende da diverse estensioni PostgreSQL. Queste estensioni traducono i pacchetti integrati di Oracle, i tipi spaziali, il partizionamento e la ricerca a testo completo. Abilitano anche l'osservabilità nel database scratch. Allowlist e installare le estensioni necessarie per lo schema convertito prima della prima esecuzione della conversione.

La tabella seguente elenca le estensioni comunemente usate per le conversioni da Oracle ad Database di Azure per PostgreSQL. Includi gli elementi applicabili allo schema sorgente e aggiungi tutti gli altri richiesti dal carico di lavoro.

Lo strumento crea plpgsql_check automaticamente nel database scratch quando l'estensione è consentita. Consenti prima della prima esecuzione in modo che le routine convertite ottengano la convalida completa del corpo. Se l'estensione non è disponibile, la conversione ha comunque esito positivo, ma la convalida aggiuntiva viene ignorata automaticamente. plpgsql_check è obbligatorio solo nel database scratch. Lo schema convertito non dipende da esso in fase di esecuzione.

Aggiungere dblink solo quando lo schema di origine usa PRAGMA AUTONOMOUS_TRANSACTION. In tal caso, il codice convertito richiede dblink nel server di destinazione, non solo il database scratch.

Passaggio 1: Consenti l'elenco di estensioni

Nel portale di Azure aprire il server flessibile Database di Azure per PostgreSQL che ospita il database scratch. Selezionare Parametri del server, cercare azure.extensionse selezionare ogni estensione dall'elenco. Salvare le modifiche. Le estensioni, ad esempio pg_partman, pg_stat_statementse plpgsql_check richiedono anche voci in shared_preload_libraries. Queste voci richiedono un riavvio del server. Per altre informazioni, vedere Come usare le estensioni PostgreSQL.

Passaggio 2: Installare le estensioni nel database scratch

Connettersi al database scratch come membro del azure_pg_admin ruolo e creare ogni estensione:

CREATE EXTENSION IF NOT EXISTS orafce;
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS postgis;
CREATE EXTENSION IF NOT EXISTS postgis_topology;
CREATE EXTENSION IF NOT EXISTS postgis_tiger_geocoder;
CREATE EXTENSION IF NOT EXISTS pg_partman;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS plpgsql_check;

Passaggio 3: Configurare search_path per la compatibilità di Oracle

orafce installa pacchetti compatibili con Oracle in schemi dedicati (oracle, dbms_*, plv*, utl_file). Impostare search_path a livello di database in modo che tali schemi, insieme agli schemi PostGIS (topology, tiger) siano disponibili per ogni connessione. Un'impostazione a livello di database include anche oggetti che non possono qualificare autonomamente un riferimento, ad esempio viste, CHECK vincoli, impostazioni predefinite di colonna e colonne generate.

ALTER DATABASE <database_name> SET search_path = public, oracle, topology, tiger,
    dbms_random, dbms_alert, dbms_assert, dbms_output, dbms_pipe,
    dbms_sql, dbms_utility, plvchr, plvdate, plvlex, plvstr,
    plvsubst, plunit, utl_file;

Includere solo gli schemi per le estensioni installate. Riconnettersi dopo l'esecuzione di questa istruzione, perché il nuovo valore si applica alle sessioni che iniziano dopo la modifica. Per definire l'ambito dell'impostazione su un singolo ruolo, usare ALTER ROLE <role_name> SET search_path = ...invece .

Configurare la capacità di Microsoft Foundry

La capacità di Microsoft Foundry influisce direttamente sull'affidabilità della conversione, in particolare per schemi Oracle complessi o di grandi dimensioni. Prevedere un numero sufficiente di token al minuto (TPM) e monitorarne l'utilizzo così che le conversioni vengano completate senza interruzioni.

Prevedere un numero sufficiente di token al minuto

• Configurare la distribuzione di Microsoft Foundry con una quota di almeno 500.000 token al minuto (TPM) per ottenere prestazioni ottimali. Gli oggetti dello schema complessi utilizzano una capacità significativa del token durante la conversione.
• Monitorare il consumo nel portale Microsoft Foundry e aumentare il limite se si osserva una limitazione della velocità durante un processo di conversione.

Eseguire un progetto alla volta

Eseguire un singolo progetto di conversione dello schema alla volta. I progetti simultanei competono per la stessa quota Microsoft Foundry e possono causare limitazioni, conversioni parziali e costi di token imprevisti. Elabora i progetti in sequenza per mantenere un comportamento prevedibile e facilitarne il debug.

Proteggere il flusso di lavoro di conversione

Lo strumento di conversione viene eseguito localmente in Visual Studio Code e si connette a tre endpoint: la distribuzione Microsoft Foundry, il database Oracle di origine e il server flessibile Database di Azure per PostgreSQL di destinazione. Prima di avviare una conversione, verificare che Visual Studio Code possa raggiungere tutti e tre gli endpoint dalla workstation, quindi applicare controlli di sicurezza aziendali standard a ogni connessione.

Verificare la connettività di rete da Visual Studio Code

Verificare che la workstation in esecuzione Visual Studio Code possa raggiungere l'endpoint Microsoft Foundry, il database di origine Oracle e il server flessibile Database di Azure per PostgreSQL. Se una connessione è bloccata da un firewall aziendale, una VPN o un gruppo di sicurezza di rete, collaborare con il team di rete per consentire l'accesso in uscita prima di avviare una conversione.

Usare endpoint privati o regole del firewall per la destinazione

Limitare l'accesso di rete per il server flessibile di Database di Azure per PostgreSQL. Usa endpoint privati per le workstation integrate con la VNet o configura regole del firewall che consentano solo gli intervalli IP utilizzati dal team.

Usare l'autenticazione di Microsoft Entra ID

Connettersi al server flessibile Database di Azure per PostgreSQL con autenticazione Microsoft Entra anziché l'autenticazione della password. L'autenticazione di Microsoft Entra centralizza il controllo degli accessi, supporta i criteri di accesso condizionale e genera eventi di accesso verificabili.

Gestire le credenziali in modo sicuro

Non incorporare credenziali Oracle o PostgreSQL in testo normale e non eseguirne il commit nel controllo del codice sorgente. Archiviali in Azure Key Vault o nel gestore dei segreti della tua organizzazione e usali nella configurazione di connessione dello strumento di conversione in Visual Studio Code al momento della connessione.

Convalidare lo schema convertito

La conversione automatizzata accelera la migrazione, ma la convalida manuale è essenziale per intercettare differenze semantiche, comportamenti specifici della piattaforma e casi perimetrali che l'intelligenza artificiale o gli strumenti potrebbero perdere. Il report di conversione dello schema contrassegna gli oggetti estratti dallo strumento ma non è stato possibile convertire completamente come attività di revisione. Svolgete prima queste attività e verificate a campione gli oggetti complessi che sono stati convertiti correttamente.

Per informazioni dettagliate sugli artefatti prodotti dallo strumento e sull'ordine di revisione consigliato, vedere Report di conversione dello schema per Oracle in Database di Azure per PostgreSQL server flessibile.

Convalidare oggetti di codice complessi

Convalidare manualmente gli oggetti di codice Oracle complessi seguenti dopo la conversione:

• Stored procedure: esaminare la logica della procedura convertita, la gestione dei parametri e la gestione delle eccezioni.
• Pacchetti: convalidare la struttura dei pacchetti e la risoluzione delle dipendenze con gli schemi PostgreSQL.
• Funzioni: Verificare i tipi di ritorno, la corrispondenza dei parametri e la correttezza della logica di business.

Flusso di lavoro di convalida

1. Completare tutte le attività di revisione nel report di conversione dello schema, facoltativamente con l'assistenza della modalità agente di GitHub Copilot.
2. Esaminare ogni oggetto complesso convertito dall'intelligenza artificiale, anche quando non è stata creata alcuna attività di revisione.
3. Eseguire procedure e funzioni convertite nel database scratch con dati di test rappresentativi.
4. Verifica che la logica di business e i set di risultati corrispondano all'origine Oracle prima di promuovere lo schema nell'ambiente di produzione.

Riesegui e ripeti

Un'esecuzione di conversione è ripetibile. Rieseguire la conversione ogni volta che gli input cambiano in modo che il report e il DDL generato riflettano lo stato corrente.

Quando eseguire di nuovo una conversione

Ripeti la conversione quando:

• Modificare il database scratch di destinazione. Ad esempio, si consente di aggiungere un'estensione mancante, installare una nuova estensione o correggere search_path.
• Modificare il lato Oracle di origine. Ad esempio, si inserisce uno schema aggiuntivo nell'ambito, si rilascia un oggetto problema o si corregge il danneggiamento dei metadati in un oggetto di origine.
• Modificare la capacità di Microsoft Foundry. Ad esempio, aumentare la quota TPM dopo aver osservato la limitazione nell'esecuzione precedente.

Confronta il nuovo report di conversione con quello precedente per confermare che la modifica abbia avuto l'effetto previsto e per individuare eventuali effetti collaterali indesiderati sugli oggetti non interessati dalla modifica.

Mantenere gli artefatti di conversione

Salvare la cartella DDL PostgreSQL generata insieme a tutti i report generati dallo strumento di conversione come artefatto di controllo per il progetto di migrazione. Questi artefatti sono utili per:

• Verifiche di conformità e controllo.
• Confronto delle differenze rispetto a future riconversioni.
• Trasferimento delle informazioni ai team operativi o delle applicazioni.

Archiviare gli artefatti nel sistema di controllo del codice sorgente o di gestione dei documenti del team.

Contenuti correlati

• Che cos'è Oracle per Database di Azure per PostgreSQL conversione flessibile dello schema del server?
• Esercitazione: Conversione dello schema del server flessibile da Oracle a Database di Azure per PostgreSQL
• Esaminare le attività e le cartelle di output per Oracle per Database di Azure per PostgreSQL conversione flessibile dello schema del server
• Oracle per Database di Azure per PostgreSQL limitazioni di conversione dello schema del server flessibile