oracle 如何使用AWS SCT和DMS将SDO_GEOMETERY类型的表迁移到Aurora Postgres?

c2e8gylq  于 2023-11-17  发布在  Oracle
关注(0)|答案(1)|浏览(129)

我已经成功地使用AWS数据库迁移服务的模式迁移工具将数十个表从Oracle(19.20.0)迁移到Aurora Postgres
对于我使用SMT转换的大多数表,我能够随后使用数据库迁移任务在Aurora Postgres中填充数据!
SCT可以很好地将包含sdo_geometry对象的表转换为postgis geometry类型。例如:

CREATE TABLE GENERAL_SHAPES 
    ( 
        GENERAL_SHAPE_NAME    VARCHAR2(32) NOT NULL, 
        SHAPE_IDX             NUMBER NOT NULL, 
        GENERAL_SHAPE_CONTEXT VARCHAR2(32), 
        SHAPE PUBLIC.SDO_GEOMETRY NOT NULL, 
        CONSTRAINT GENERAL_SHAPES_PK PRIMARY KEY (GENERAL_SHAPE_NAME, SHAPE_IDX) 
    );

字符串
变成:

CREATE TABLE public.general_shapes
    (
        general_shape_name character varying(32),
        shape_idx numeric,
        general_shape_context character varying(32),
        shape geometry NOT NULL,
        CONSTRAINT general_shapes_pk PRIMARY KEY (general_shape_name, shape_idx)
    );


这一切看起来都是正确的,从SDO_GEOMETRY到postgis GEOMETRY对我来说是有意义的!不幸的是,当我尝试使用DMS Database Migration Tasks将表从oracle sdo_geometry填充到postgres geometry时,我得到以下错误:

2023-10-12T21:16:45 [TASK_MANAGER ]I: Start loading table 'MYDB'.'GENERAL_SHAPES' (Id = 1) by subtask 1. Start load timestamp 0006078B74F00700 (replicationtask_util.c:755)

2023-10-12T21:16:46 [SOURCE_UNLOAD   ]I:  Oracle endpoint get table definition  {tableName:GENERAL_SHAPES, schemaName:MYDB, connectionId:750}  (oracle_endpoint_imp.c:1849)

2023-10-12T21:16:46 [SOURCE_UNLOAD   ]I:  Sent unloaded record 1 to internal queue  {operation:LOAD_START_OF_TABLE (31), tableName:GENERAL_SHAPES, schemaName:MYDB, connectionId:750}  (streamcomponent.c:2933)

2023-10-12T21:16:46 [TARGET_LOAD     ]I:  Table 'public'.'general_shapes' contains LOB columns, change working mode to default mode  (odbc_endpoint_imp.c:6074)

2023-10-12T21:16:46 [TARGET_LOAD     ]I:  Table 'public'.'general_shapes' has Non-Optimized Full LOB Support  (odbc_endpoint_imp.c:6087)

2023-10-12T21:16:47 [TARGET_LOAD     ]E:  Failed (retcode -1) to execute statement [1022502]  (ar_odbc_stmt.c:2868)

2023-10-12T21:16:47 [TARGET_LOAD     ]E:  RetCode: SQL_ERROR  SqlState: XX000 NativeError: 1 Message: ERROR: unexpected end of data (at offset 0); Error while executing the query [1022502]  (ar_odbc_stmt.c:2874)

2023-10-12T21:16:47 [TASK_MANAGER    ]W:  Table 'MYDB'.'GENERAL_SHAPES' was errored/suspended (subtask 1 thread 1). Failed (retcode -1) to execute statement; RetCode: SQL_ERROR  SqlState: XX000 NativeError: 1 Message: ERROR: unexpected end of data (at offset 0); Error while executing the query  (replicationtask.c:3023)


所有具有sdo_geometry类型列的表都会发生这种情况。如果我使用任务转换规则将表插入到一个新的/不存在的表中,它将创建并填充一个表,除了它将忽略/删除shape列。所以现在它变成:

CREATE TABLE "GENERAL_SHAPES" (
    "GENERAL_SHAPE_NAME" character varying(32),
    "SHAPE_IDX" numeric(38,10),
    "GENERAL_SHAPE_CONTEXT" character varying(32),
    CONSTRAINT "GENERAL_SHAPES_pkey" PRIMARY KEY ("GENERAL_SHAPE_NAME", "SHAPE_IDX")
);


我怀疑关键可能是使用SpatialDataOptionToGeoJsonFunctionName:
使用此属性可将SDO_GEOMETRY转换为GEOJSON格式。默认情况下,DMS调用SDO 2GEOJSON自定义函数(如果存在且可访问)。或者,您可以创建自己的自定义函数来模拟SDOGEOJSON的操作,并将SpatialDataOptionToGeoJsonFunctionName设置为调用该函数。
这就是我卡住的地方。我不知道如何去构造一个SDOGEOJSON函数,它可以输出 * 东西 *,将JustWork™插入geometrey形状函数!我找不到任何关于该函数应该是什么样子的文档,或者它应该接受的输入,输出应该是什么,我在all_objects中找不到任何名为SDOGEOJSON的东西,所以如果某些工具集应该将其注入到源Oracle DB中,我没有!

pxy2qtax

pxy2qtax1#

对于任何后来遇到这个的人来说,它实际上完全按照预期工作。sdo_geometry到postgis geometery是相当光滑和完全无缝的。
我遇到的问题部分是操作员错误,部分是不熟悉,部分是模式转换工具的复杂性。关键的一点是在DSM任务中启用FULL LOB支持。
在整理出大量的数据问题、无效触发器和其他不相关的错误之后,我能够确认 * 在迁移的列中看起来是 * 的垃圾数据,实际上只是我的数据库客户端无法理解/呈现geometry列。
下面的SQL确认了我的形状转换有问题。

select ST_AsText(shape) from general_shapes;

字符串

相关问题