Lignes (total)<\/td> ~8,800<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nL'absence de proc\u00e9dures stock\u00e9es et de d\u00e9clencheurs ram\u00e8ne l'effort de conversion PL\/SQL \u00e0 z\u00e9ro. La complexit\u00e9 provient de trois points : la fa\u00e7on dont Oracle g\u00e8re les colonnes IDENTITY, une colonne BLOB qui stocke du JSON, et quatre vues \u2014 dont trois utilisent des fonctions SQL sp\u00e9cifiques \u00e0 Oracle que PostgreSQL ne prend pas en charge.<\/p>\n\n\n\n
ora2pg \u00e9value le sch\u00e9ma CO A-3<\/strong>migration directe, estim\u00e9e \u00e0 trois heures-personne. Les facteurs de co\u00fbt sont les trois vues non portables.<\/p>\n\n\n\nProbl\u00e8me 1 : Les colonnes d'identit\u00e9 n'ont pas de s\u00e9quences explicites<\/h3>\n\n\n\n CO utilise GENERATED BY DEFAULT ON NULL AS IDENTITY<\/code> sur chaque colonne de cl\u00e9 primaire. Oracle g\u00e8re les s\u00e9quences sous-jacentes en interne \u2014 il n'y a pas CR\u00c9ER S\u00c9QUENCE<\/code> instructions dans le sch\u00e9ma, et aucune paire s\u00e9quence-d\u00e9clencheur comme celles utilis\u00e9es par le sch\u00e9ma HR.<\/p>\n\n\n\nora2pg convertit correctement la syntaxe Oracle : GENERATED BY DEFAULT ON NULL AS IDENTITY<\/code> devient G\u00c9N\u00c9R\u00c9 PAR D\u00c9FAUT COMME IDENTIT\u00c9<\/code> dans PostgreSQL. Cette partie ne n\u00e9cessite aucun travail manuel.<\/p>\n\n\n\nLe probl\u00e8me survient apr\u00e8s le chargement des donn\u00e9es.<\/p>\n\n\n\n
Lorsque ora2pg exporte des donn\u00e9es via COPY, il exporte les identifiants de ligne r\u00e9els d'Oracle \u2014 1, 2, 3, \u2026 jusqu'\u00e0 l'ID le plus \u00e9lev\u00e9. Le protocole COPY de PostgreSQL accepte ces valeurs et les ins\u00e8re directement dans les colonnes IDENTITY. La s\u00e9quence IDENTITY n'est pas appel\u00e9e lors d'un chargement COPY. Une fois le chargement termin\u00e9, chaque s\u00e9quence IDENTITY reste \u00e0 sa valeur initiale de 1.<\/p>\n\n\n\n
La premi\u00e8re INSERT dans clients<\/code> apr\u00e8s la migration tentera d'utiliser id_client = 1<\/code>. Cette ligne existe d\u00e9j\u00e0. L'insertion \u00e9choue avec la violation de la contrainte unique de la valeur de la cl\u00e9 dupliqu\u00e9e<\/code>.<\/p>\n\n\n\nLa correction consiste \u00e0 faire progresser chaque s\u00e9quence IDENTITY au-del\u00e0 de la valeur charg\u00e9e la plus \u00e9lev\u00e9e :<\/p>\n\n\n
\nSET search_path = co, public;\nSELECT setval(pg_get_serial_sequence('co.customers', 'customer_id'), (SELECT MAX(customer_id) FROM co.customers));\nSELECT setval(pg_get_serial_sequence('co.orders', 'order_id'), (SELECT MAX(order_id) FROM co.orders));\nSELECT setval(pg_get_serial_sequence('co.shipments', 'shipment_id'), (SELECT MAX(shipment_id) FROM co.shipments));\nSELECT setval(pg_get_serial_sequence('co.stores', 'store_id'), (SELECT MAX(store_id) FROM co.stores));\nSELECT setval(pg_get_serial_sequence('co.products', 'product_id'), (SELECT MAX(product_id) FROM co.products));\n<\/pre><\/div>\n\n\npg_get_serial_sequence<\/code> r\u00e9sout le nom de la s\u00e9quence \u00e0 partir des noms de table et de colonne. Cela \u00e9vite de coder en dur les noms de s\u00e9quence, qui varient entre les versions d'ora2pg.<\/p>\n\n\n\nEx\u00e9cutez ce bloc imm\u00e9diatement apr\u00e8s le chargement des donn\u00e9es, avant que toute application n'acc\u00e8de \u00e0 la base de donn\u00e9es migr\u00e9e. Sur un sch\u00e9ma de production, les s\u00e9quences manqu\u00e9es entra\u00eenent des \u00e9checs d'INSERT qui sont faciles \u00e0 manquer lors des tests si l'ensemble de donn\u00e9es de test utilise des identifiants diff\u00e9rents de ceux de production.<\/p>\n\n\n\n
Probl\u00e8me 2 : Stocker du JSON en BLOB doit devenir JSONB, pas BYTEA<\/h3>\n\n\n\n produits.d\u00e9tails_produit<\/code> est d\u00e9clar\u00e9 comme BLOB<\/code> dans Oracle avec un V\u00c9RIFIER (product_details IS JSON)<\/code> contrainte. <\/p>\n\n\n\nLes bases de donn\u00e9es Oracle avant la version 21c stockent le JSON sous forme de BLOB ou de CLOB \u2014 il n'y a pas de type de donn\u00e9es JSON natif.<\/p>\n\n\n\n
ora2pg mappe toutes les colonnes BLOB vers BYTEA<\/code> par d\u00e9faut. <\/p>\n\n\n\nPour image_produit<\/code> et magasins.logo<\/code>, c'est exact \u2014 ils stockent des donn\u00e9es d'image binaires. <\/p>\n\n\n\nPour d\u00e9tails du produit<\/code>, c'est faux.<\/p>\n\n\n\nBYTEA<\/code> dans PostgreSQL stocke des octets bruts. Il n'y a pas d'op\u00e9rateurs JSON, pas de fonctions JSON, pas de validation \u00e0 l'insertion. Le avis_produits<\/code> voir les requ\u00eates d\u00e9tails du produit<\/code> en JSON en utilisant jsonb_array_elements<\/code> apr\u00e8s la r\u00e9\u00e9criture (voir Probl\u00e8me 5 ci-dessous). Cette fonction n\u00e9cessite une JSONB<\/code> argument \u2014 il \u00e9chouera avec function jsonb_array_elements(bytea) does not exist<\/code> si la colonne est BYTEA<\/code>.<\/p>\n\n\n\nLa correction est un MODIFICATION_TYPE<\/code> remplacer avant d'ex\u00e9cuter l'exportation TABLE :<\/p>\n\n\n\nMODIFY_TYPE PRODUCTS:PRODUCT_DETAILS:jsonb\n<\/pre><\/div>\n\n\nCeci fait partie d'une plus longue MODIFICATION_TYPE<\/code> ligne \u2014 voir l'\u00e9tape 6 ci-dessous pour la directive compl\u00e8te.<\/p>\n\n\n\nJSONB<\/code> applique automatiquement un JSON valide \u00e0 chaque insertion. Le V\u00c9RIFIER (product_details IS JSON)<\/code> La contrainte est donc redondante apr\u00e8s le changement de type de colonne. Elle utilise \u00e9galement la syntaxe Oracle \u2014 PostgreSQL n'a pas de EST-CE DU JSON<\/code> pr\u00e9dicat \u2014 il doit donc \u00eatre supprim\u00e9 du DDL export\u00e9 avant le chargement. Voir Probl\u00e8me 4.<\/p>\n\n\n\nProbl\u00e8me 3 : Les colonnes FK sont NUMBER(38), les PK sont bigint \u2014 Inad\u00e9quation de type<\/h3>\n\n\n\n FORCE_IDENTIT\u00c9_BIGINT 1<\/code> causes ora2pg \u00e0 exporter les colonnes de cl\u00e9 primaire IDENTITY comme grand entier<\/code>. PG_INTEGER_TYPE 1<\/code> couvre brut NOMBRE<\/code> colonnes \u00e0 grand entier<\/code>.<\/p>\n\n\n\nLes colonnes FK dans CO \u2014 commandes.client_id<\/code>, commandes.id_magasin<\/code>, orderens.commande_id<\/code>, et d'autres \u2014 sont d\u00e9clar\u00e9s comme NOMBRE(38)<\/code> Dans Oracle. C'est la repr\u00e9sentation interne d'Oracle d'une colonne d'entiers d\u00e9clar\u00e9e sans pr\u00e9cision. Parce que la pr\u00e9cision est explicitement 38<\/code>, PG_INTEGER_TYPE 1<\/code> ne s'applique pas. ora2pg les mappe \u00e0 num\u00e9rique(38)<\/code>.<\/p>\n\n\n\nLe r\u00e9sultat : les colonnes de cl\u00e9 primaire sont grand entier<\/code>, les colonnes de cl\u00e9 \u00e9trang\u00e8re qui y font r\u00e9f\u00e9rence sont num\u00e9rique(38)<\/code>. PostgreSQL exige que les colonnes de cl\u00e9 \u00e9trang\u00e8re (FK) et de cl\u00e9 primaire (PK) aient le m\u00eame type. Le chargement du DDL r\u00e9ussit, mais la cr\u00e9ation des contraintes de cl\u00e9 \u00e9trang\u00e8re \u00e9choue :<\/p>\n\n\n\nERROR: foreign key constraint "orders_customer_id_fk" cannot be implemented\nDETAIL: Key columns "customer_id" and "customer_id" are of incompatible types: numeric and bigint.\n<\/pre><\/div>\n\n\nLa correction consiste \u00e0 ajouter toutes les colonnes FK et les autres colonnes enti\u00e8res \u00e0 MODIFICATION_TYPE<\/code>:<\/p>\n\n\n\nMODIFY_TYPE INVENTORY:STORE_ID:bigint,INVENTORY:PRODUCT_ID:bigint,INVENTORY:PRODUCT_INVENTORY:integer,ORDERS:CUSTOMER_ID:bigint,ORDERS:STORE_ID:bigint,ORDER_ITEMS:ORDER_ID:bigint,ORDER_ITEMS:LINE_ITEM_ID:integer,ORDER_ITEMS:PRODUCT_ID:bigint,ORDER_ITEMS:QUANTITY:integer,ORDER_ITEMS:SHIPMENT_ID:bigint,SHIPMENTS:STORE_ID:bigint,SHIPMENTS:CUSTOMER_ID:bigint\n<\/pre><\/div>\n\n\nMODIFICATION_TYPE<\/code> lit seulement la premi\u00e8re ligne de la directive. Toutes les substitutions, y compris la substitution JSONB du probl\u00e8me 2 et la num\u00e9rique<\/code> substitutions depuis le bas \u2014 doivent \u00eatre sur une seule ligne s\u00e9par\u00e9e par des virgules.<\/p>\n\n\n\nAussi : n'incluez pas la pr\u00e9cision du type \u00e0 l'int\u00e9rieur MODIFICATION_TYPE<\/code> \u00e9crire num\u00e9rique<\/code>, pas num\u00e9rique(10,2)<\/code>).<\/p>\n\n\n\nLa virgule entre parenth\u00e8ses est trait\u00e9e comme un d\u00e9limiteur et interrompt l'analyse.<\/p>\n\n\n\n
Probl\u00e8me 4 : La contrainte de v\u00e9rification IS JSON utilise la syntaxe Oracle<\/h3>\n\n\n\n ora2pg exporte les produits_json_c<\/code> contrainte comme :<\/p>\n\n\n\nCONSTRAINT products_json_c CHECK (product_details IS JSON)\n<\/pre><\/div>\n\n\nPostgreSQL n'a pas EST-CE DU JSON<\/code> pr\u00e9dicat. Le chargement du DDL de la table \u00e9choue imm\u00e9diatement avec une erreur de syntaxe.<\/p>\n\n\n\nLa contrainte est \u00e9galement redondante. JSONB<\/code> dans PostgreSQL valide le JSON \u00e0 chaque insertion. Toute ligne qui \u00e9choue \u00e0 la validation JSON est rejet\u00e9e avant d'atteindre le stockage. Le EST-CE DU JSON<\/code> la contrainte ne fait rien que le type de colonne ne fasse pas d\u00e9j\u00e0.<\/p>\n\n\n\nLa solution : supprimer la ligne de contrainte du DDL export\u00e9 avant le chargement.<\/p>\n\n\n
\nsed -i '\/products_json_c\/d' \/home\/fernando\/ora2pg-co\/output\/CO_tables_fixed.sql\n<\/pre><\/div>\n\n\nV\u00e9rifier :<\/p>\n\n\n
\ngrep 'products_json_c' \/home\/fernando\/ora2pg-co\/output\/CO_tables_fixed.sql\n# Expected: no output\n<\/pre><\/div>\n\n\nLe rapport TEST affichera une DIFF\u00c9RENCE DE CONTRAINTES DE V\u00c9RIFICATION pour le produits<\/code> table \u2014 une contrainte dans Oracle, z\u00e9ro dans PostgreSQL. C'est attendu et correct.<\/p>\n\n\n\nProbl\u00e8me 5 : Trois vues utilisent des fonctions SQL sp\u00e9cifiques \u00e0 Oracle<\/h3>\n\n\n\n CO a quatre vues. Une (commandes_produits<\/code>) utilise le SQL standard et se convertit sans modification. Trois utilisent des fonctions qui n'ont pas d'\u00e9quivalent direct dans PostgreSQL :<\/p>\n\n\n\nproduits_commande_client<\/code> \u2014 LISTAGG avec SURFLUX<\/h4>\n\n\n\nOracle's LISTAGG(expr, s\u00e9parateur ON OVERFLOW TRUNCATE '...' WITH COUNT)<\/code> concat\u00e8ne les valeurs dans une cha\u00eene d\u00e9limit\u00e9e avec gestion des d\u00e9passements. <\/p>\n\n\n\nPostgreSQL STRING_AGG(expr, s\u00e9parateur ORDER BY ...)<\/code> est l'\u00e9quivalent \u2014 aucune option de d\u00e9bordement.<\/p>\n\n\n\n-- Oracle\nLISTAGG(p.product_name, ', ' ON OVERFLOW TRUNCATE '...' WITH COUNT)\n WITHIN GROUP (ORDER BY oi.line_item_id) items\n\n-- PostgreSQL\nSTRING_AGG(p.product_name, ', ' ORDER BY oi.line_item_id) items\n<\/pre><\/div>\n\n\ncommandes_magasin<\/code> \u2014 GROUPING_ID<\/h4>\n\n\n\nOracle's GROUPING_ID(col1, col2)<\/code> renvoie un vecteur de bits entier codant quelles colonnes sont agr\u00e9g\u00e9es dans un ENSEMBLES DE GROUPEMENT<\/code> requ\u00eate. <\/p>\n\n\n\nPostgreSQL GROUPEMENT(col1, col2)<\/code> fait exactement la m\u00eame chose \u2014 le nom de la fonction diff\u00e8re, la s\u00e9mantique est identique. <\/p>\n\n\n\nLe remplacement est \u00e0 l'identique.<\/p>\n\n\n
\n-- Oracle\nCASE grouping_id(store_name, order_status)\n WHEN 1 THEN 'STORE TOTAL'\n ...\n\n-- PostgreSQL\nCASE grouping(s.store_name, o.order_status)\n WHEN 1 THEN 'STORE TOTAL'\n ...\n<\/pre><\/div>\n\n\navis_produits<\/code> \u2014 JSON_TABLE<\/h4>\n\n\n\nOracle's JSON_TABLE<\/code> \u00e9tend un tableau JSON en lignes \u00e0 l'aide d'une projection relationnelle.<\/p>\n\n\n\nPostgreSQL n'a pas JSON_TABLE<\/code> l'\u00e9quivalent avant la version 15 (il a \u00e9t\u00e9 ajout\u00e9 dans PostgreSQL 15 dans le cadre de la norme SQL\/JSON, mais avec une syntaxe diff\u00e9rente). <\/p>\n\n\n\nPour PostgreSQL 14 et versions ant\u00e9rieures \u2014 ou pour un comportement coh\u00e9rent entre les versions \u2014 r\u00e9\u00e9crire en utilisant jsonb_array_elements<\/code>:<\/p>\n\n\n\n-- Oracle\nFROM products p,\n JSON_TABLE(p.product_details, '$'\n COLUMNS (NESTED PATH '$.reviews[*]'\n COLUMNS (rating INTEGER PATH '$.rating',\n review VARCHAR2(4000) PATH '$.review'))) r\n\n-- PostgreSQL\nFROM products p,\n jsonb_array_elements(p.product_details->'reviews') AS review_row\n<\/pre><\/div>\n\n\nDans la version PostgreSQL, chaque \u00e9l\u00e9ment de tableau JSON est expos\u00e9 comme un jsonb<\/code> valeur nomm\u00e9e ligne_avis<\/code>. <\/p>\n\n\n\nLes valeurs de colonne sont extraites avec ->><\/code> op\u00e9rateur : review_row->>'notation'<\/code> et review_row->>'avis'<\/code>. <\/p>\n\n\n\nLe casting ENTIER<\/code> le champ de note est obligatoire parce que ->><\/code> revient toujours texte<\/code>.<\/p>\n\n\n\nCe remaniement d\u00e9pend de d\u00e9tails du produit<\/code> \u00eatre JSONB<\/code> \u2014 si la colonne est BYTEA<\/code> (Probl\u00e8me 2 non r\u00e9solu), la vue \u00e9choue imm\u00e9diatement.<\/p>\n\n\n\nEx\u00e9cution de la migration\u00a0: chaque commande dans l'ordre<\/h2>\n\n\n\nEnvironnement<\/h3>\n\n\n\n Deux VM sur le m\u00eame r\u00e9seau. srv1<\/code> (192.168.0.180) ex\u00e9cute Oracle 19c avec le sch\u00e9ma CO dans PDB pdb1<\/code>. srv2<\/code> (192.168.0.181) ex\u00e9cute Ubuntu avec PostgreSQL 18 et ora2pg install\u00e9s. Toutes les commandes ci-dessous sont ex\u00e9cut\u00e9es sur srv2<\/code> sauf indication contraire.<\/p>\n\n\n\n\u00c9tape 1 \u2014 Collecter les statistiques Oracle<\/h3>\n\n\n\n Courir sur srv1<\/code> Avant de g\u00e9n\u00e9rer le rapport, les estimations d'effort de ora2pg utilisent les statistiques stock\u00e9es d'Oracle ; des statistiques obsol\u00e8tes produisent des comptages inexacts.<\/p>\n\n\n\n-- On Oracle (srv1)\nBEGIN\n DBMS_STATS.GATHER_SCHEMA_STATS('CO');\n DBMS_STATS.GATHER_DICTIONARY_STATS;\nEND;\n\/\n<\/pre><\/div>\n\n\n\u00c9tape 2 \u2014 Cr\u00e9ez le r\u00e9pertoire de sortie<\/h3>\n\n\n\nmkdir -p \/home\/fernando\/ora2pg-co\/output\n<\/pre><\/div>\n\n\n\u00c9tape 3 \u2014 Configuration de base ora2pg.conf<\/h3>\n\n\n\n# \/etc\/ora2pg\/ora2pg.conf\nORACLE_DSN dbi:Oracle:host=192.168.0.180;service_name=pdb1;port=1521\nORACLE_USER system\nORACLE_PWD <system password>\nSCHEMA CO\nEXPORT_SCHEMA 1\nCREATE_SCHEMA 1\nOUTPUT_DIR \/home\/fernando\/ora2pg-co\/output\n<\/pre><\/div>\n\n\nUtilisation syst\u00e8me<\/code>, pas co<\/code> \u2014 l'exportation COPY se lit v$base de donn\u00e9es<\/code>, ce qui requiert des privil\u00e8ges DBA.<\/p>\n\n\n\n\u00c9tape 4 \u2014 G\u00e9n\u00e9rer le rapport d'\u00e9valuation<\/h3>\n\n\n\nora2pg -t SHOW_REPORT --estimate_cost --dump_as_html \\\n > \/home\/fernando\/ora2pg-co\/output\/report-co.html\n<\/pre><\/div>\n\n\nOuvrir le HTML dans un navigateur. CO devrait marquer A-3<\/strong>. Les inducteurs de co\u00fbts sont les trois vues non portables.<\/p>\n\n\n\n\u00c9tape 5 \u2014 Analyser les types de colonnes<\/h3>\n\n\n\nora2pg -t SHOW_COLUMN > \/home\/fernando\/ora2pg-co\/output\/columns-co.txt\n<\/pre><\/div>\n\n\nColonnes cl\u00e9s \u00e0 v\u00e9rifier :<\/p>\n\n\n\nColonne<\/th> ora2pg par d\u00e9faut<\/th> Type correct<\/th> Raison<\/th><\/tr><\/thead> PRIX.UNITAIRE_PRODUIT<\/code><\/td>double pr\u00e9cision<\/code><\/td>num\u00e9rique<\/code><\/td>Mon\u00e9taire \u2014 les nombres \u00e0 virgule flottante provoquent des erreurs d'arrondi<\/td><\/tr> PRIX_UNITAIRE_Article_COMMANDE<\/code><\/td>double pr\u00e9cision<\/code><\/td>num\u00e9rique<\/code><\/td>