DEMOGR\u00c1FICOS_SUPLEMENTARIOS<\/td> 4,500<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nLa tabla de VENTAS con casi un mill\u00f3n de filas hace que la exportaci\u00f3n y carga de COPIAR tome entre 15 y 25 minutos.<\/p>\n\n\n\n
Planea eso antes de empezar.<\/p>\n\n\n\n
Problema 1: Las tablas particionadas requieren dos exportaciones separadas<\/h3>\n\n\n\n SALES y COSTS est\u00e1n particionados por rangos seg\u00fan TIME_ID en Oracle.<\/p>\n\n\n\n
PostgreSQL admite el particionamiento declarativo por rangos con las mismas sem\u00e1nticas.<\/p>\n\n\n\n
El problema es que ora2pg<\/code> divide esto en dos tipos de exportaci\u00f3n.<\/p>\n\n\n\nEn MESA<\/code> export genera el DDL de la tabla padre \u2014 la PARTICIONAR POR RANGO (time_id)<\/code> declaraci\u00f3n \u2014 pero sin tablas de particiones secundarias.<\/p>\n\n\n\nSi carga esto y trata de insertar filas, PostgreSQL devuelve:<\/p>\n\n\n\n
ERROR: no se encontr\u00f3 partici\u00f3n de la relaci\u00f3n \"sales\" para la fila<\/code><\/pre>\n\n\n\nLas tablas secundarias de partici\u00f3n provienen de una parte separada PARTICI\u00d3N<\/code> exportar.<\/p>\n\n\n\nNecesitas ambos archivos y debes cargar el DDL de la tabla padre antes que las tablas hijas particionadas.<\/p>\n\n\n\n
As\u00ed se ve en la pr\u00e1ctica:<\/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\nEl esquema SH tiene 28 particiones de VENTAS y 9 particiones de COSTOS \u2014 37 en total.<\/p>\n\n\n\n
Verificar que el recuento coincida con Oracle antes de cargar.<\/p>\n\n\n\n
Problema 2: Las columnas NUMBER(38) no son manejadas por PG_INTEGER_TYPE<\/h3>\n\n\n\n Cada columna de ID entera en SH se declara como desnuda N\u00daMERO<\/code> en Oracle, que almacena internamente como N\u00daMERO(38)<\/code>.<\/p>\n\n\n\nLa opci\u00f3n de ora2pg PG_INTEGER_TYPE 1<\/code> convierte desnudo N\u00daMERO<\/code> (sin precisi\u00f3n) para entero largo<\/code>.<\/p>\n\n\n\nPero N\u00daMERO(38)<\/code> tiene una precisi\u00f3n expl\u00edcita \u2014 ora2pg la trata como un tipo num\u00e9rico, no un entero, y la mapea a num\u00e9rico(38)<\/code>.<\/p>\n\n\n\nA num\u00e9rico(38)<\/code> la columna funciona pero es incorrecta para una columna de clave primaria o clave for\u00e1nea.<\/p>\n\n\n\nEs 8 veces m\u00e1s grande que entero largo<\/code>, m\u00e1s lento de indexar e imposible de usar con operaciones espec\u00edficas de enteros.<\/p>\n\n\n\nLa soluci\u00f3n es MODIFICAR_TIPO<\/code> \u2014 una directiva de una sola l\u00ednea en ora2pg.conf<\/code> que fuerza un tipo espec\u00edfico para columnas espec\u00edficas.<\/p>\n\n\n\nRegla cr\u00edtica:<\/strong> MODIFICAR_TIPO<\/code> es una sola l\u00ednea.<\/p>\n\n\n\nTodas las anulaciones van en una l\u00ednea, separadas por comas.<\/p>\n\n\n\n
Si escribes m\u00faltiples MODIFICAR_TIPO<\/code> l\u00edneas, ora2pg<\/code> usa solo el primero e ignora silenciosamente el resto.<\/p>\n\n\n\nEjecutar MOSTRAR_COLUMNA<\/code> primero en identificar cada num\u00e9rico(38)<\/code> columna<\/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\nLuego, agrega todas las anulaciones a ora2pg.conf<\/code> en una l\u00ednea:<\/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\nAntes de ejecutar cualquier exportaci\u00f3n, confirme que hay exactamente un activo MODIFICAR_TIPO<\/code> l\u00ednea:<\/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\nProblema 3: \u00cdndices de mapas de bits \u2014 Conservar, Eliminar o Reemplazar<\/h3>\n\n\n\n Oracle utiliza \u00edndices bitmap en columnas de baja cardinalidad en SH: CHANNEL_ID (5 valores), PROMO_ID (503 valores) y TIME_ID.<\/p>\n\n\n\n
PostgreSQL no tiene un tipo de \u00edndice de mapa de bits.<\/p>\n\n\n\n
Por defecto, ora2pg convierte los \u00edndices bitmap en \u00edndices GIN (BITMAP_COMO_GIN 1<\/code>).<\/p>\n\n\n\nEso est\u00e1 mal para estas columnas \u2014 GIN est\u00e1 dise\u00f1ado para b\u00fasqueda de texto completo y datos de tipo array, no para claves for\u00e1neas de tipo entero.<\/p>\n\n\n\n
Configurar BITMAP_COMO_GINEBRA 0<\/code> en ora2pg.conf<\/code>.<\/p>\n\n\n\nEsto indica a ora2pg que convierta los \u00edndices bitmap en \u00edndices B-tree regulares, los cuales revisas individualmente.<\/p>\n\n\n\n
La tabla de decisi\u00f3n para SH:<\/p>\n\n\n\nOracle \u00edndice bitmap<\/th> Cardinalidad de columna<\/th> Decisi\u00f3n PostgreSQL<\/th><\/tr><\/thead> canal_de_ventas_bix<\/td> 5 canales<\/td> Dejar<\/strong> \u2014 Un \u00e1rbol B con 5 valores no aporta ning\u00fan beneficio; PostgreSQL utiliza un escaneo secuencial<\/td><\/tr>ventas_cli_bix<\/td> 55.500 clientes<\/td> Mantener como \u00e1rbol B<\/strong> \u2014 alta cardinalidad, utilizada para consultas a nivel de cliente<\/td><\/tr>ventas_prod_bix<\/td> 72 productos<\/td> Mantener como \u00e1rbol B<\/strong><\/td><\/tr>venta_promocional_bix<\/td> 503 promociones<\/td> Mantener como \u00e1rbol B<\/strong><\/td><\/tr>tiempo_de_venta_bix<\/td> 1.826 d\u00edas<\/td> Reemplazar con BRIN<\/strong> \u2014 TIME_ID est\u00e1 ordenado monot\u00f3nicamente en una tabla particionada por rangos<\/td><\/tr>costos_canal_bix<\/td> 5 canales<\/td> Dejar<\/strong><\/td><\/tr>costos_prod_bix, costos_promo_bix<\/td> igual<\/td> Mantener como \u00e1rbol B<\/strong><\/td><\/tr>costos_tiempo_bix<\/td> fechas ordenadas<\/td> Reemplazar con BRIN<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nBRIN (Block Range Index) es un \u00edndice de rangos de bloques que almacena valores m\u00ednimos\/m\u00e1ximos por bloque de 128 p\u00e1ginas.<\/p>\n\n\n\n
Para una columna de series de tiempo en una tabla particionada, es mucho m\u00e1s barato de mantener que un B-tree y igualmente efectivo para escaneos de rangos.<\/p>\n\n\n\n
Editar el archivo de exportaci\u00f3n de la TABLA antes de cargar:<\/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\nProblema 4: La Actualizaci\u00f3n de la Vista Materializada Ya No Es Autom\u00e1tica<\/h3>\n\n\n\n Oracle CAL_MONTH_SALES_MV y FWEEK_PSCAT_SALES_MV usan REFRESCAR COMPLETAMENTE BAJO DEMANDA<\/code>.<\/p>\n\n\n\nLa actualizaci\u00f3n COMPLETA significa que la vista se reconstruye desde cero en cada actualizaci\u00f3n.<\/p>\n\n\n\n
PostgreSQL REFRESCAR VISTA MATERIALIZADA<\/code> hace exactamente esto \u2014 ning\u00fan problema de traducci\u00f3n.<\/p>\n\n\n\nEl problema es la programaci\u00f3n.<\/p>\n\n\n\n
Oracle DBMS_MVIEW.REFRESH<\/code> y DBMS_SCHEDULER<\/code> gestionar la actualizaci\u00f3n autom\u00e1tica.<\/p>\n\n\n\nPostgreSQL no tiene un equivalente incorporado.<\/p>\n\n\n\n
Despu\u00e9s de la migraci\u00f3n, las MV son instant\u00e1neas est\u00e1ticas hasta que alguien ejecuta expl\u00edcitamente:<\/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\nPara replicar la actualizaci\u00f3n programada, instala pg_cron (requiere superusuario) y crea un trabajo despu\u00e9s de la migraci\u00f3n.<\/p>\n\n\n\n
Tambi\u00e9n existe una restricci\u00f3n de orden de carga.<\/p>\n\n\n\n
PostgreSQL ejecuta la consulta MV SELECT inmediatamente cuando la ejecutas CREAR VISTA MATERIALIZADA COMO SELECCIONAR<\/code>.<\/p>\n\n\n\nSi carga el DDL de la MV antes de los datos, la consulta se ejecuta contra tablas vac\u00edas y la MV se crea vac\u00eda.<\/p>\n\n\n\n
Carga primero los datos, luego las vistas de materiales.<\/p>\n\n\n\n
Tambi\u00e9n hay un problema con search_path.<\/p>\n\n\n\n
ora2pg no a\u00f1ade SET search_path<\/code> al archivo de exportaci\u00f3n de MVIEW.<\/p>\n\n\n\nSi cargas SH_mviews.sql<\/code> directamente, psql se ejecuta como el usuario del sistema operativo postgres, cuyo search_path predeterminado es p\u00fablico<\/code> los videos musicales se crean en p\u00fablico<\/code>, no a<\/code>.<\/p>\n\n\n\nLa soluci\u00f3n es el truco de la tuber\u00eda:<\/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\nEn eco<\/code> ante pone el SET search_path<\/code> directiva as\u00ed que cada CREAR VISTA MATERIALIZADA<\/code> en el archivo aterriza en el a<\/code> esquema.<\/p>\n\n\n\nProblema 5: Los objetos DIMENSION se descartan silenciosamente<\/h3>\n\n\n\n Oracle es compatible CREAR DIMENSI\u00d3N<\/code> sintaxis, que define jerarqu\u00edas de consolidaci\u00f3n para el motor de reescritura de consultas y las operaciones OLAP de Oracle.<\/p>\n\n\n\nPostgreSQL no tiene un equivalente.<\/p>\n\n\n\n
ora2pg omite silenciosamente los objetos DIMENSION.<\/p>\n\n\n\n
No hay advertencia, ni error, ni DDL de marcador de posici\u00f3n.<\/p>\n\n\n\n
Si no los revisas manualmente, no sabr\u00e1s que exist\u00edan hasta que alguien pregunte por qu\u00e9 un informe del lado de Oracle que utilizaba la reescritura de consultas ya no funciona como se esperaba.<\/p>\n\n\n\n
En el esquema SH, se omiten CUSTOMERS_DIM, PRODUCTS_DIM, TIMES_DIM y CHANNELS_DIM.<\/p>\n\n\n\n
No hay ning\u00fan impacto funcional en las consultas SQL est\u00e1ndar: las dimensiones son metadatos del optimizador, no datos.<\/p>\n\n\n\n
La acci\u00f3n correcta es documentarlos como abandonados en el registro de riesgos de migraci\u00f3n.<\/p>\n\n\n\n
Ejecutando la Migraci\u00f3n: Cada Comando en Orden<\/h2>\n\n\n\nPaso 1: poblar los datos de Oracle SH usando SQLcl<\/h3>\n\n\n\n El script de instalaci\u00f3n de SH llama sh_populate.sql<\/code> internamente, que usa SQLcl's CARGAR<\/code> comando para leer archivos CSV.<\/p>\n\n\n\nSQL*Plus no soporta CARGAR<\/code> \u2014 salta silenciosamente cada CARGAR<\/code> llamada con SP2-0734: comando desconocido<\/code>.<\/p>\n\n\n\nEl esquema se crea pero cada tabla grande permanece con 0 filas.<\/p>\n\n\n\n
Primero descargue los archivos 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\nEjecuta la instalaci\u00f3n usando SQLcl, no SQL*Plus:<\/p>\n\n\n
\n# On srv1 (Oracle)\ncd \/home\/oracle\/sh\nsql \/ as sysdba\n<\/pre><\/div>\n\n\nDentro de 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\nVerificar recuentos de filas:<\/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\nPaso 2 \u2014 Crear la base de datos y el usuario de 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\nPaso 3 \u2013 Crea el directorio de salida<\/h3>\n\n\n\n# On srv2 (PostgreSQL)\nmkdir -p \/home\/fernando\/ora2pg-sh\/output\n<\/pre><\/div>\n\n\n