DONN\u00c9ES_D\u00c9MOGRAPHIQUES_SUPPL\u00c9MENTAIRES<\/td> 4,500<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nLa table SALES, avec pr\u00e8s d'un million de lignes, fait en sorte que l'exportation et le chargement COPY prennent 15 \u00e0 25 minutes.<\/p>\n\n\n\n
Planifiez cela avant de commencer.<\/p>\n\n\n\n
Probl\u00e8me 1 : Les tables partitionn\u00e9es n\u00e9cessitent deux exportations distinctes<\/h3>\n\n\n\n SALES et COSTS sont partitionn\u00e9s par plage selon TIME_ID dans Oracle.<\/p>\n\n\n\n
PostgreSQL prend en charge le partitionnement d\u00e9claratif par intervalle avec la m\u00eame s\u00e9mantique.<\/p>\n\n\n\n
Le probl\u00e8me est que ora2pg<\/code> diviser ceci en deux types d'exportation.<\/p>\n\n\n\nLe TABLE<\/code> export g\u00e9n\u00e8re le DDL de la table parente \u2014 le PARTITION BY RANGE (time_id)<\/code> d\u00e9claration \u2014 mais pas de tables de partition enfant.<\/p>\n\n\n\nSi vous chargez ceci et essayez d'ins\u00e9rer des lignes, PostgreSQL renvoie\u00a0:<\/p>\n\n\n\n
ERREUR : aucune partition de la relation \" sales \" trouv\u00e9e pour la ligne<\/code><\/pre>\n\n\n\nLes tables enfants partitionn\u00e9es proviennent d'un Partition<\/code> exporter.<\/p>\n\n\n\nVous avez besoin des deux fichiers, et vous devez charger le DDL de la table parente avant les tables filles partitionn\u00e9es.<\/p>\n\n\n\n
Ce que cela ressemble en pratique :<\/strong><\/p>\n\n\n\n-- TABLE export generates:\nCREATE TABLE sh.sales (\n prod_id bigint NOT NULL,\n cust_id bigint NOT NULL,\n time_id date NOT NULL,\n channel_id bigint NOT NULL,\n promo_id bigint NOT NULL,\n quantity_sold numeric(10,2) NOT NULL,\n amount_sold numeric(10,2) NOT NULL\n) PARTITION BY RANGE (time_id);\n\n-- PARTITION export generates:\nCREATE TABLE sales_1995 PARTITION OF sh.sales\n FOR VALUES FROM (MINVALUE) TO ('1996-01-01');\nCREATE TABLE sales_1996 PARTITION OF sh.sales\n FOR VALUES FROM ('1996-01-01') TO ('1997-01-01');\n-- ... 33 more partitions\n<\/pre><\/div>\n\n\nLe sch\u00e9ma SH a 28 partitions SALES et 9 partitions COSTS, soit 37 au total.<\/p>\n\n\n\n
V\u00e9rifiez que le compte correspond \u00e0 Oracle avant le chargement.<\/p>\n\n\n\n
Probl\u00e8me 2 : Les colonnes NUMBER(38) ne sont pas g\u00e9r\u00e9es par le type PG_INTEGER_TYPE<\/h3>\n\n\n\n Chaque colonne ID enti\u00e8re dans SH est d\u00e9clar\u00e9e comme nue NOMBRE<\/code> dans Oracle, qui stocke en interne sous forme de NOMBRE(38)<\/code>.<\/p>\n\n\n\nL'option ora2pg PG_INTEGER_TYPE 1<\/code> couvre brut NOMBRE<\/code> \u00e0 grand entier<\/code>.<\/p>\n\n\n\nMais NOMBRE(38)<\/code> poss\u00e8de une pr\u00e9cision explicite - ora2pg le traite comme un type num\u00e9rique, pas un entier, et le mappe sur num\u00e9rique(38)<\/code>.<\/p>\n\n\n\nA num\u00e9rique(38)<\/code> la colonne fonctionne mais est inappropri\u00e9e pour une colonne de cl\u00e9 primaire ou de cl\u00e9 \u00e9trang\u00e8re.<\/p>\n\n\n\nC'est 8 fois plus grand que grand entier<\/code>, plus lent \u00e0 indexer, et impossible \u00e0 utiliser avec des op\u00e9rations sp\u00e9cifiques aux entiers.<\/p>\n\n\n\nLa correction est MODIFICATION_TYPE<\/code> \u2014 une directive sur une seule ligne dans ora2pg.conf<\/code> qui force un type sp\u00e9cifique pour des colonnes sp\u00e9cifiques.<\/p>\n\n\n\nR\u00e8gle critique :<\/strong> MODIFICATION_TYPE<\/code> est une seule ligne.<\/p>\n\n\n\nToutes les substitutions se font sur une ligne, s\u00e9par\u00e9es par des virgules.<\/p>\n\n\n\n
Si vous \u00e9crivez plusieurs MODIFICATION_TYPE<\/code> lignes, ora2pg<\/code> n'utilise que le premier et ignore silencieusement le reste.<\/p>\n\n\n\nEx\u00e9cuter AFFICHER_COLONNE<\/code> le premier \u00e0 identifier tout num\u00e9rique(38)<\/code> colonne :<\/p>\n\n\n\nora2pg -t SHOW_COLUMN > \/home\/fernando\/ora2pg-sh\/output\/columns-sh.txt\ngrep 'numeric(38)' \/home\/fernando\/ora2pg-sh\/output\/columns-sh.txt\n<\/pre><\/div>\n\n\nPuis ajoutez toutes les substitutions \u00e0 ora2pg.conf<\/code> sur une seule ligne :<\/p>\n\n\n\nMODIFY_TYPE CUSTOMERS:CUST_ID:bigint,CUSTOMERS:CUST_CITY_ID:bigint,CUSTOMERS:CUST_STATE_PROVINCE_ID:bigint,CUSTOMERS:CUST_TOTAL_ID:bigint,CUSTOMERS:CUST_SRC_ID:bigint,CHANNELS:CHANNEL_ID:bigint,CHANNELS:CHANNEL_CLASS_ID:bigint,CHANNELS:CHANNEL_TOTAL_ID:bigint,COUNTRIES:COUNTRY_ID:bigint,COUNTRIES:COUNTRY_SUBREGION_ID:bigint,COUNTRIES:COUNTRY_REGION_ID:bigint,COUNTRIES:COUNTRY_TOTAL_ID:bigint,PRODUCTS:PROD_ID:bigint,PRODUCTS:PROD_SUBCATEGORY_ID:bigint,PRODUCTS:PROD_CATEGORY_ID:bigint,PRODUCTS:SUPPLIER_ID:bigint,PRODUCTS:PROD_TOTAL_ID:bigint,PRODUCTS:PROD_SRC_ID:bigint,PROMOTIONS:PROMO_ID:bigint,PROMOTIONS:PROMO_SUBCATEGORY_ID:bigint,PROMOTIONS:PROMO_CATEGORY_ID:bigint,PROMOTIONS:PROMO_TOTAL_ID:bigint,SALES:PROD_ID:bigint,SALES:CUST_ID:bigint,SALES:CHANNEL_ID:bigint,SALES:PROMO_ID:bigint,COSTS:PROD_ID:bigint,COSTS:PROMO_ID:bigint,COSTS:CHANNEL_ID:bigint\n<\/pre><\/div>\n\n\nAvant d'ex\u00e9cuter toute exportation, assurez-vous qu'il n'y a qu'un seul \u00e9l\u00e9ment actif MODIFICATION_TYPE<\/code> ligne :<\/p>\n\n\n\ngrep 'MODIFY_TYPE' \/etc\/ora2pg\/ora2pg.conf | grep -v '^\\s*#' | wc -l\n# Must be: 1\n<\/pre><\/div>\n\n\nProbl\u00e8me 3 : Index Bitmap \u2014 Conserver, Supprimer ou Remplacer<\/h3>\n\n\n\n Oracle utilise des index bitmap sur des colonnes \u00e0 faible cardinalit\u00e9 dans SH : CHANNEL_ID (5 valeurs), PROMO_ID (503 valeurs) et TIME_ID.<\/p>\n\n\n\n
PostgreSQL n'a pas de type d'index bitmap.<\/p>\n\n\n\n
Par d\u00e9faut, ora2pg convertit les index bitmap en index GIN (BITMAP_AS_GIN 1<\/code>).<\/p>\n\n\n\nC'est incorrect pour ces colonnes \u2014 GIN est con\u00e7u pour la recherche plein texte et les donn\u00e9es de tableaux, pas pour les cl\u00e9s \u00e9trang\u00e8res enti\u00e8res.<\/p>\n\n\n\n
Ensemble BITMAP_AS_GIN 0<\/code> en ora2pg.conf<\/code>.<\/p>\n\n\n\nCeci indique \u00e0 ora2pg de convertir les index bitmap en index B-tree r\u00e9guliers, que vous examinez ensuite individuellement.<\/p>\n\n\n\n
Le tableau de d\u00e9cision pour SH :<\/p>\n\n\n\nIndex bitmap Oracle<\/th> Cardinalit\u00e9 de colonne<\/th> D\u00e9cision PostgreSQL<\/th><\/tr><\/thead> canal_de_vente_bix<\/td> 5 cha\u00eenes<\/td> Chute<\/strong> \u2014 Un arbre B \u00e0 5 valeurs n'apporte aucun b\u00e9n\u00e9fice; PostgreSQL utilise un scan s\u00e9quentiel<\/td><\/tr>ventes_cust_bix<\/td> 55 500 clients<\/td> Garder comme arbre B<\/strong> \u2014 cardinalit\u00e9 \u00e9lev\u00e9e, utilis\u00e9e pour les requ\u00eates au niveau du client<\/td><\/tr>produit_vente_bix<\/td> 72\u00a0produits<\/td> Garder comme arbre B<\/strong><\/td><\/tr>bix_promo_ventes<\/td> 503 promotions<\/td> Garder comme arbre B<\/strong><\/td><\/tr>temps_de_vente_bix<\/td> 1 826 jours<\/td> Remplacez par BRIN<\/strong> \u2014 TIME_ID est ordonn\u00e9 le long d'une table partitionn\u00e9e par plage<\/td><\/tr>co\u00fbts du canal bix<\/td> 5 cha\u00eenes<\/td> Chute<\/strong><\/td><\/tr>co\u00fbts_prod_bix, co\u00fbts_promo_bix<\/td> pareil<\/td> Garder comme arbre B<\/strong><\/td><\/tr>co\u00fbts_temps_bix<\/td> dates ordonn\u00e9es<\/td> Remplacez par BRIN<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nBRIN (Block Range Index) est un index de plages de blocs qui stocke les valeurs min\/max par bloc de 128 pages.<\/p>\n\n\n\n
Pour une colonne de s\u00e9ries temporelles sur une table partitionn\u00e9e, il est beaucoup moins cher \u00e0 maintenir qu'un B-tree et tout aussi efficace pour les scans de plage.<\/p>\n\n\n\n
Modifier le fichier d'exportation TABLE avant de charger :<\/p>\n\n\n
\n-- Delete these two lines:\nCREATE INDEX sales_channel_bix ON sh.sales (channel_id);\nCREATE INDEX costs_channel_bix ON sh.costs (channel_id);\n\n-- Replace:\nCREATE INDEX sales_time_bix ON sh.sales (time_id);\n-- With:\nCREATE INDEX sales_time_bix ON sh.sales USING BRIN (time_id);\n\n-- Replace:\nCREATE INDEX costs_time_bix ON sh.costs (time_id);\n-- With:\nCREATE INDEX costs_time_bix ON sh.costs USING BRIN (time_id);\n<\/pre><\/div>\n\n\nProbl\u00e8me 4 : Le rafra\u00eechissement des vues mat\u00e9rialis\u00e9es n'est plus automatique<\/h3>\n\n\n\n Utilisations de CAL_MONTH_SALES_MV et FWEEK_PSCAT_SALES_MV par Oracle REFRESH COMPLET SUR DEMANDE<\/code>.<\/p>\n\n\n\nUn rafra\u00eechissement complet signifie que la vue est reconstruite \u00e0 partir de z\u00e9ro \u00e0 chaque rafra\u00eechissement.<\/p>\n\n\n\n
PostgreSQL ACTUALISER LA VUE MAT\u00c9RIALIS\u00c9E<\/code> fait exactement cela \u2014 aucun probl\u00e8me de traduction.<\/p>\n\n\n\nLe probl\u00e8me est la planification.<\/p>\n\n\n\n
Oracle's DBMS_MVIEW.REFRESH<\/code> et DBMS_SCHEDULER<\/code> g\u00e9rer le rafra\u00eechissement automatique.<\/p>\n\n\n\nPostgreSQL n'a pas d'\u00e9quivalent int\u00e9gr\u00e9.<\/p>\n\n\n\n
Apr\u00e8s la migration, les vues mat\u00e9rialis\u00e9es sont des instantan\u00e9s statiques jusqu'\u00e0 ce que quelqu'un ex\u00e9cute explicitement :<\/p>\n\n\n
\nREFRESH MATERIALIZED VIEW sh.cal_month_sales_mv;\nREFRESH MATERIALIZED VIEW sh.fweek_pscat_sales_mv;\n<\/pre><\/div>\n\n\nPour r\u00e9pliquer l'actualisation planifi\u00e9e, installez pg_cron (n\u00e9cessite les superutilisateurs) et cr\u00e9ez un travail apr\u00e8s la migration.<\/p>\n\n\n\n
Il y a aussi une contrainte d'ordre de chargement.<\/p>\n\n\n\n
PostgreSQL ex\u00e9cute la requ\u00eate MV SELECT imm\u00e9diatement lorsque vous lancez CR\u00c9ER UNE VUE MAT\u00c9RIALIS\u00c9E COMME SELECT<\/code>.<\/p>\n\n\n\nSi vous chargez le DDL de la MV avant les donn\u00e9es, la requ\u00eate s'ex\u00e9cute sur des tables vides et la MV est cr\u00e9\u00e9e vide.<\/p>\n\n\n\n
Chargez les donn\u00e9es d'abord, puis les MV.<\/p>\n\n\n\n
Il y a aussi un probl\u00e8me de `search_path`.<\/p>\n\n\n\n
ora2pg n'ajoute pas SET search_path<\/code> au fichier d'exportation MVIEW.<\/p>\n\n\n\nSi vous chargez SH_mviews.sql<\/code> directement, psql s'ex\u00e9cute en tant qu'utilisateur du syst\u00e8me d'exploitation postgres, dont le search_path par d\u00e9faut est public<\/code> \u2014 les MV sont cr\u00e9\u00e9s dans public<\/code>, pas le<\/h2><\/code>.<\/p>\n\n\n\nLa solution est le truc du tuyau :<\/p>\n\n\n
\n(echo "SET search_path TO sh;"; cat \/home\/fernando\/ora2pg-sh\/output\/SH_mviews.sql) | \\\n sudo -u postgres psql -d shdb\n<\/pre><\/div>\n\n\nLe \u00e9cho<\/code> pr\u00e9pole SET search_path<\/code> directive alors chaque CR\u00c9ER UNE VUE MAT\u00c9RIALIS\u00c9E<\/code> dans le fichier arrive dans le le<\/h2><\/code> sch\u00e9ma.<\/p>\n\n\n\nProbl\u00e8me 5 : Les objets dimensionnels sont silencieusement abandonn\u00e9s<\/h3>\n\n\n\n Oracle prend en charge CR\u00c9ER DIMENSION<\/code> syntaxe, qui d\u00e9finit les hi\u00e9rarchies de cumul pour le moteur de r\u00e9\u00e9criture de requ\u00eates et les op\u00e9rations OLAP d'Oracle.<\/p>\n\n\n\nPostgreSQL n'a pas d'\u00e9quivalent.<\/p>\n\n\n\n
ora2pg ignore silencieusement les objets DIMENSION.<\/p>\n\n\n\n
Il n'y a pas d'avertissement, aucune erreur, aucun DDL fragmentaire.<\/p>\n\n\n\n
Si vous ne les contr\u00f4lez pas manuellement, vous ne saurez pas qu'ils existaient jusqu'\u00e0 ce que quelqu'un vous demande pourquoi un rapport c\u00f4t\u00e9 Oracle qui utilisait la r\u00e9\u00e9criture de requ\u00eate ne fonctionne plus comme pr\u00e9vu.<\/p>\n\n\n\n
Dans le sch\u00e9ma SH, CUSTOMERS_DIM, PRODUCTS_DIM, TIMES_DIM et CHANNELS_DIM sont tous ignor\u00e9s.<\/p>\n\n\n\n
Il n'y a aucun impact fonctionnel sur les requ\u00eates SQL standard \u2014 les dimensions sont des m\u00e9tadonn\u00e9es de l'optimiseur, pas des donn\u00e9es.<\/p>\n\n\n\n
La bonne d\u00e9marche est de les documenter comme abandonn\u00e9s dans le registre des risques de migration.<\/p>\n\n\n\n
Ex\u00e9cution de la migration\u00a0: chaque commande dans l'ordre<\/h2>\n\n\n\nEnvironnement<\/strong><\/h3>\n\n\n\nDeux VM sur le m\u00eame r\u00e9seau.srv1<\/code> (192.168.0.180) ex\u00e9cute Oracle 19c avec le sch\u00e9ma SH dans PDB pdb1<\/code>.srv2<\/code> (192.168.0.181) ex\u00e9cute Ubuntu avec PostgreSQL 18 et ora2pg install\u00e9s.srv2<\/code> sauf indication contraire.<\/p>\n\n\n\n\u00c9tape 1 \u2014 Remplir les donn\u00e9es Oracle SH \u00e0 l'aide de SQLcl<\/h3>\n\n\n\n Le script d'installation SH appelle sh_populate.sql<\/code> en interne, qui utilise le SQLcl de CHARGER<\/code> commande pour lire les fichiers CSV.<\/p>\n\n\n\nSQL*Plus ne prend pas en charge CHARGER<\/code> \u2014 il saute silencieusement chaque CHARGER<\/code> appel avec SP2-0734 : commande inconnue<\/code>.<\/p>\n\n\n\nLe sch\u00e9ma est cr\u00e9\u00e9 mais chaque grande table reste \u00e0 0 ligne.<\/p>\n\n\n\n
T\u00e9l\u00e9chargez d'abord les fichiers CSV :<\/p>\n\n\n
\n# On srv1 (Oracle)\ncd \/home\/oracle\/sh\n\nfor f in costs customers promotions sales supplementary_demographics times; do\n curl -L -o ${f}.csv \\\n "https:\/\/raw.githubusercontent.com\/oracle-samples\/db-sample-schemas\/main\/sales_history\/${f}.csv"\ndone\n\nls -lh *.csv\n# Expected: 6 files; sales.csv ~74 MB, customers.csv ~13 MB\n<\/pre><\/div>\n\n\nEx\u00e9cutez l'installation avec SQLcl, pas avec SQL*Plus :<\/p>\n\n\n
\n# On srv1 (Oracle)\ncd \/home\/oracle\/sh\nsql \/ as sysdba\n<\/pre><\/div>\n\n\nDans SQLcl :<\/p>\n\n\n
\nALTER SESSION SET CONTAINER = pdb1;\n@sh_install.sql\n-- Prompts:\n-- Enter a password for the user SH: sh\n-- Enter a tablespace for SH [USERS]: (press Enter)\n-- Do you want to overwrite the schema? [YES|no]: YES\n<\/pre><\/div>\n\n\nV\u00e9rifier les d\u00e9comptes de lignes :<\/p>\n\n\n
\n# On srv1 (Oracle)\nsqlplus sh\/sh@\/\/localhost:1521\/pdb1 <<'EOF'\nSELECT 'SALES', COUNT(*) FROM sh.sales UNION ALL\nSELECT 'COSTS', COUNT(*) FROM sh.costs UNION ALL\nSELECT 'CUSTOMERS', COUNT(*) FROM sh.customers;\nEXIT;\nEOF\n# Expected: SALES 918843, COSTS 82112, CUSTOMERS 55500\n# If any large table is 0: SQLcl was not used \u2014 re-run using sql, not sqlplus\n<\/pre><\/div>\n\n\n\u00c9tape 2 \u2014 Cr\u00e9er la base de donn\u00e9es et l'utilisateur PostgreSQL<\/h3>\n\n\n\n# On srv2 (PostgreSQL)\nsudo -u postgres psql -c "CREATE USER sh WITH PASSWORD 'sh';"\nsudo -u postgres psql -c "CREATE DATABASE shdb OWNER sh;"\n\nsudo -u postgres psql -c "\\l shdb"\n# Expected: one row, owner sh, encoding UTF8\n<\/pre><\/div>\n\n\n\u00c9tape 3 \u2014 Cr\u00e9er le r\u00e9pertoire de sortie<\/h3>\n\n\n\n# On srv2 (PostgreSQL)\nmkdir -p \/home\/fernando\/ora2pg-sh\/output\n<\/pre><\/div>\n\n\n