我已经成功地使用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中,我没有!
1条答案
按热度按时间pxy2qtax1#
对于任何后来遇到这个的人来说,它实际上完全按照预期工作。
sdo_geometry
到postgisgeometery
是相当光滑和完全无缝的。我遇到的问题部分是操作员错误,部分是不熟悉,部分是模式转换工具的复杂性。关键的一点是在DSM任务中启用
FULL LOB
支持。在整理出大量的数据问题、无效触发器和其他不相关的错误之后,我能够确认 * 在迁移的列中看起来是 * 的垃圾数据,实际上只是我的数据库客户端无法理解/呈现
geometry
列。下面的SQL确认了我的形状转换有问题。
字符串