Filas (total)<\/td> ~8,800<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nLa ausencia de procedimientos almacenados y disparadores mantiene el esfuerzo de conversi\u00f3n de PL\/SQL en cero. La complejidad proviene de tres puntos: c\u00f3mo Oracle maneja las columnas IDENTITY, una columna BLOB que almacena JSON y cuatro vistas, tres de las cuales utilizan funciones SQL espec\u00edficas de Oracle que PostgreSQL no soporta.<\/p>\n\n\n\n
ora2pg califica el esquema de CO A-3<\/strong>migraci\u00f3n directa, estimada en tres horas persona. Los impulsores de costos son las tres vistas no port\u00e1tiles.<\/p>\n\n\n\nProblema 1: Las columnas de identidad no tienen secuencias expl\u00edcitas<\/h3>\n\n\n\n Usos de CO GENERADO POR DEFECTO EN NULO COMO IDENTIDAD<\/code> en cada columna de clave primaria. Oracle gestiona las secuencias subyacentes internamente \u2014 no hay CREAR SECUENCIA<\/code> declaraciones en el esquema, y no hay pares de secuencia-disparador como los utilizados en el esquema HR.<\/p>\n\n\n\nora2pg convierte la sintaxis de Oracle correctamente: GENERADO POR DEFECTO EN NULO COMO IDENTIDAD<\/code> se convierte GENERADO POR DEFECTO COMO IDENTIDAD<\/code> en PostgreSQL. Esa parte no requiere trabajo manual.<\/p>\n\n\n\nEl problema surge despu\u00e9s de la carga de datos.<\/p>\n\n\n\n
Cuando ora2pg exporta datos mediante COPY, exporta los identificadores de fila reales de Oracle: 1, 2, 3, ... hasta el ID m\u00e1s alto. El protocolo COPY de PostgreSQL acepta esos valores y los inserta directamente en las columnas IDENTITY. La secuencia IDENTITY no se llama durante una carga COPY. Despu\u00e9s de que la carga se completa, cada secuencia IDENTITY permanece en su valor inicial de 1.<\/p>\n\n\n\n
La primera inserci\u00f3n en clientes<\/code> despu\u00e9s de la migraci\u00f3n intentar\u00e1 usar customer_id = 1<\/code>. Esa fila ya existe. La inserci\u00f3n falla con la clave duplicada viola la restricci\u00f3n \u00fanica<\/code>.<\/p>\n\n\n\nLa soluci\u00f3n es adelantar cada secuencia de IDENTIDAD m\u00e1s all\u00e1 del valor m\u00e1s alto cargado:<\/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> resuelve el nombre de la secuencia a partir de los nombres de tabla y columna. Esto evita codificar de forma fija los nombres de secuencia, que var\u00edan entre versiones de ora2pg.<\/p>\n\n\n\nEjecuta este bloque inmediatamente despu\u00e9s de la carga de datos, antes de que cualquier aplicaci\u00f3n toque la base de datos migrada. En un esquema de producci\u00f3n, las secuencias omitidas causan fallos en las inserciones que son f\u00e1ciles de pasar por alto en las pruebas si el conjunto de datos de prueba utiliza identificadores diferentes a los de producci\u00f3n.<\/p>\n\n\n\n
Problema 2: Almacenar BLOB como JSON debe ser JSONB, no BYTEA<\/h3>\n\n\n\n productos.detalles_producto<\/code> se declara como BOLO<\/code> en Oracle con una Comprobar (product_details ES JSON)<\/code> restricci\u00f3n. <\/p>\n\n\n\nLas bases de datos Oracle anteriores a la 21c almacenan JSON como BLOB o CLOB; no hay un tipo JSON nativo.<\/p>\n\n\n\n
ora2pg mapea todas las columnas BLOB a BYTEA<\/code> por defecto. <\/p>\n\n\n\nPara imagen_producto<\/code> y tiendas.logotipo<\/code>, eso es correcto \u2014 almacenan datos de im\u00e1genes binarias. <\/p>\n\n\n\nPara detalles_del_producto<\/code>, est\u00e1 mal.<\/p>\n\n\n\nBYTEA<\/code> en PostgreSQL almacena bytes sin procesar. No hay operadores JSON, no hay funciones JSON, no hay validaci\u00f3n en la inserci\u00f3n. El rese\u00f1as de productos<\/code> ver consultas detalles_del_producto<\/code> como JSON usando jsonb_array_elements<\/code> despu\u00e9s de la reescritura (v\u00e9ase el Problema 5 a continuaci\u00f3n). Esa funci\u00f3n requiere un JSONB<\/code> argumento \u2014 fallar\u00e1 con function jsonb_array_elements(bytea) does not exist<\/code> si la columna es BYTEA<\/code>.<\/p>\n\n\n\nLa soluci\u00f3n es un MODIFICAR_TIPO<\/code> anular antes de ejecutar la exportaci\u00f3n de la TABLA:<\/p>\n\n\n\nMODIFY_TYPE PRODUCTS:PRODUCT_DETAILS:jsonb\n<\/pre><\/div>\n\n\nEsta es parte de una m\u00e1s larga MODIFICAR_TIPO<\/code> l\u00ednea \u2014 ver el Paso 6 a continuaci\u00f3n para la directiva completa.<\/p>\n\n\n\nJSONB<\/code> impone JSON v\u00e1lido en cada inserci\u00f3n autom\u00e1ticamente. El Comprobar (product_details ES JSON)<\/code> La restricci\u00f3n es, por lo tanto, redundante despu\u00e9s del cambio del tipo de columna. Tambi\u00e9n utiliza sintaxis de Oracle; PostgreSQL no tiene es JSON<\/code> predicado \u2014 por lo tanto, debe eliminarse del DDL exportado antes de la carga. Ver Problema 4.<\/p>\n\n\n\nProblema 3: Las columnas FK son NUMBER(38), las PK son bigint \u2014 Desajuste de tipos<\/h3>\n\n\n\n FORCE_IDENTITY_BIGINT 1<\/code> cAuses ora2pg a exportar las columnas de clave primaria de IDENTIDAD como entero largo<\/code>. PG_INTEGER_TYPE 1<\/code> convierte desnudo N\u00daMERO<\/code> columnas a entero largo<\/code>.<\/p>\n\n\n\nLas columnas FK en CO \u2014 \u00f3rdenes.cliente_id<\/code>, \u00f3rdenes.tienda_id<\/code>, order_items.order_id<\/code>, y otros \u2014 se declaran como N\u00daMERO(38)<\/code> en Oracle. Esa es la representaci\u00f3n interna de Oracle de una columna de enteros declarada sin precisi\u00f3n. Debido a que la precisi\u00f3n es expl\u00edcitamente 38<\/code>, PG_INTEGER_TYPE 1<\/code> no aplica. ora2pg los mapea a num\u00e9rico(38)<\/code>.<\/p>\n\n\n\nEl resultado: las columnas de clave primaria son entero largo<\/code>, las columnas de clave externa que hacen referencia a ellas son num\u00e9rico(38)<\/code>. PostgreSQL requiere que las columnas de FK y PK tengan el mismo tipo. La carga del DDL tiene \u00e9xito, pero la creaci\u00f3n de las restricciones FK falla:<\/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 soluci\u00f3n es a\u00f1adir todas las columnas FK y otras columnas enteras a MODIFICAR_TIPO<\/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\nMODIFICAR_TIPO<\/code> lee solo la primera l\u00ednea de la directiva. Todas las anulaciones, incluida la anulaci\u00f3n JSONB del Problema 2 y la num\u00e9rico<\/code> anulaciones desde abajo \u2014 deben estar en una sola l\u00ednea separada por comas.<\/p>\n\n\n\nTampoco: no incluir precisi\u00f3n de tipo dentro MODIFICAR_TIPO<\/code> escribir num\u00e9rico<\/code>, no num\u00e9rico(10,2)<\/code>).<\/p>\n\n\n\nLa coma dentro de los par\u00e9ntesis se trata como un delimitador y rompe el an\u00e1lisis.<\/p>\n\n\n\n
Problema 4: La restricci\u00f3n de verificaci\u00f3n IS JSON utiliza sintaxis de Oracle<\/h3>\n\n\n\n ora2pg exporta el productos_json_c<\/code> restricci\u00f3n como:<\/p>\n\n\n\nCONSTRAINT products_json_c CHECK (product_details IS JSON)\n<\/pre><\/div>\n\n\nPostgreSQL no tiene es JSON<\/code> predicado. La carga de la DDL de la tabla falla inmediatamente con un error de sintaxis.<\/p>\n\n\n\nLa restricci\u00f3n tambi\u00e9n es redundante. JSONB<\/code> en PostgreSQL valida el JSON en cada inserci\u00f3n. Cualquier fila que falle la validaci\u00f3n JSON es rechazada antes de llegar al almacenamiento. El es JSON<\/code> La restricci\u00f3n no hace nada que el tipo de columna ya no haga.<\/p>\n\n\n\nLa soluci\u00f3n: elimina la l\u00ednea de restricci\u00f3n del DDL exportado antes de cargarlo.<\/p>\n\n\n
\nsed -i '\/products_json_c\/d' \/home\/fernando\/ora2pg-co\/output\/CO_tables_fixed.sql\n<\/pre><\/div>\n\n\nVerificar<\/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\nEl informe TEST mostrar\u00e1 una DIFERENCIA DE COMPROBACI\u00d3N DE RESTRICCIONES para el productos<\/code> tabla \u2014 una restricci\u00f3n en Oracle, cero en PostgreSQL. Esto es esperado y correcto.<\/p>\n\n\n\nProblema 5: Tres vistas usan funciones SQL espec\u00edficas de Oracle<\/h3>\n\n\n\n El CO tiene cuatro vistas. Una (pedidos_productos<\/code>) usa SQL est\u00e1ndar y se convierte sin cambios. Tres usan funciones que no tienen un equivalente directo en PostgreSQL:<\/p>\n\n\n\nproductos_pedido_cliente<\/code> \u2014 LISTAGG con ON OVERFLOW<\/h4>\n\n\n\nOracle LISTAGG(expr, separador ON OVERFLOW TRUNCATE '...' WITH COUNT)<\/code> concatena valores en una cadena delimitada con manejo de desbordamiento. <\/p>\n\n\n\nPostgreSQL STRING_AGG(expr, separador ORDEN POR ...)<\/code> es la opci\u00f3n equivalente \u2014 sin desbordamiento.<\/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\npedidos_almacen<\/code> \u2014 GROUPING_ID<\/h4>\n\n\n\nOracle GROUPING_ID(col1, col2)<\/code> devuelve un vector de bits entero que codifica qu\u00e9 columnas se agregan en un GROUPING SETS<\/code> b\u00fasqueda. <\/p>\n\n\n\nPostgreSQL AGRUPAR POR(col1, col2)<\/code> hace exactamente lo mismo \u2014 el nombre de la funci\u00f3n difiere, la sem\u00e1ntica es id\u00e9ntica. <\/p>\n\n\n\nEl reemplazo es uno por uno.<\/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\nrese\u00f1as de productos<\/code> \u2014 TABLA_JSON<\/h4>\n\n\n\nOracle JSON_TABLE<\/code> expande un arreglo JSON en filas usando una proyecci\u00f3n relacional.<\/p>\n\n\n\nPostgreSQL no tiene JSON_TABLE<\/code> equivalente antes de la versi\u00f3n 15 (se a\u00f1adi\u00f3 en PostgreSQL 15 como parte del est\u00e1ndar SQL\/JSON, pero con una sintaxis diferente). <\/p>\n\n\n\nPara PostgreSQL 14 y versiones anteriores, o para un comportamiento consistente entre versiones, reescribe usando 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\nEn la versi\u00f3n de PostgreSQL, cada elemento de matriz JSON se expone como un jsonb<\/code> valor llamado fila_revision<\/code>. <\/p>\n\n\n\nLos valores de las columnas se extraen con el ->><\/code> operador Calificaci\u00f3n de review_row'<\/code> y review_row->>'review'<\/code>. <\/p>\n\n\n\nEl elenco ::ENTERO<\/code> el campo de calificaci\u00f3n es obligatorio porque ->><\/code> siempre regresa texto<\/code>.<\/p>\n\n\n\nEsta reescritura depende de detalles_del_producto<\/code> ser JSONB<\/code> \u2014 si la columna es BYTEA<\/code> (El problema 2 no se solucion\u00f3), la vista falla inmediatamente.<\/p>\n\n\n\nEjecutando la Migraci\u00f3n: Cada Comando en Orden<\/h2>\n\n\n\nMedio ambiente<\/h3>\n\n\n\n Dos m\u00e1quinas virtuales en la misma red. srv1<\/code> (192.168.0.180) ejecuta Oracle 19c con el esquema CO en PDB pdb1<\/code>. srv2<\/code> (192.168.0.181) ejecuta Ubuntu con PostgreSQL 18 y ora2pg instalado. Todos los comandos a continuaci\u00f3n se ejecutan en srv2<\/code> a menos que se indique lo contrario.<\/p>\n\n\n\nPaso 1 \u2014 Recopilar estad\u00edsticas de Oracle<\/h3>\n\n\n\n Correr sobre srv1<\/code> antes de generar el informe. las estimaciones de esfuerzo de ora2pg utilizan estad\u00edsticas almacenadas de Oracle \u2014 las estad\u00edsticas obsoletas producen recuentos inexactos.<\/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\nPaso 2: cree el directorio de salida<\/h3>\n\n\n\nmkdir -p \/home\/fernando\/ora2pg-co\/output\n<\/pre><\/div>\n\n\nPaso 3: Configurar 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\nUtilice sistema<\/code>, no co<\/code> \u2014 la exportaci\u00f3n de COPIA dice v$base de datos<\/code>, que requiere privilegios de DBA.<\/p>\n\n\n\nPaso 4: Generar el informe de evaluaci\u00f3n<\/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\nAbrir el HTML en un navegador. CO deber\u00eda anotar A-3<\/strong>. Los impulsores de costos son las tres vistas no port\u00e1tiles.<\/p>\n\n\n\nPaso 5 \u2014 Analizar tipos de columna<\/h3>\n\n\n\nora2pg -t SHOW_COLUMN > \/home\/fernando\/ora2pg-co\/output\/columns-co.txt\n<\/pre><\/div>\n\n\nColumnas clave para revisar:<\/p>\n\n\n\nColumna<\/th> ora2pg predeterminado<\/th> Tipo correcto<\/th> Raz\u00f3n<\/th><\/tr><\/thead> PRODUCTOS.PRECIO_UNITARIO<\/code><\/td>doble precisi\u00f3n<\/code><\/td>num\u00e9rico<\/code><\/td>Monetario: los n\u00fameros de punto flotante causan errores de redondeo<\/td><\/tr> PRECIO_UNITARIO_PEDIDO<\/code><\/td>doble precisi\u00f3n<\/code><\/td>num\u00e9rico<\/code><\/td>