背景：绕不开的几何类型

基于国产化要求，业务数据库需要去O，替换到达梦。对于通信行业来说，业务使用了大量几何类型——包含点、线、面、多点等复杂要素，存储在 Oracle里就是SDO_GEOMETRY 类型，几何类型的操作也是基于MDSYS模式下相关的方法。本次基于DM9，在windows系统环境中，模拟迁移52G几何类型数据，验证几何类型数据迁移的平稳及速度。
之前在DM8上我已经做过一轮试迁移，这次拿到DM9后第一时间用同样的数据再做对比，最直观的感受是：DTS工具在细节上成熟了很多，最大的惊喜在几何类型的落库形态上。

DTS工具：这些小改动很便捷

• Oracle 版本可自选+会话属性可配：数据源页面可以直接指定 Oracle 版本，还能以key=value形式追加会话属性，遇到老版本库或者连接行为差异时不会报错
• 非法日期格式可指定：Oracle里历史数据里的非法日期格式，DM9的DTS可以直接指定迁移格式，不再整批报错卡住
• 策略配置模板化：迁移策略可以保存为模板，演练阶段调好的并发、批载参数，正式迁移时可以一键复用
• 表空间/权限/角色可平迁：迁移模式里新增了表空间、权限、角色的资源选项，本次19760个对象连同表空间一起勾选迁移，最大程度做到平迁，尤其在国产化项目中，可以减少改造量/编译失败数。

几何类型，落库形态有差别

• DM8：之前的项目预演练，使用自带dts工具迁移时，Oracle的 SDO_GEOMETRY列迁移到DM8后，被转换成达梦自己的 SYSGEO.ST_GEOMETRY(4326, …)。ST_Geometry是OpenGIS风格的类型体系，配合DMGEO/DMGEO2系统包使用。对于项目来说，可以使用，但要进行改造，两种方案：1.做一次手工类型转换，并同步数据；2.应用侧所有按 Oracle SDO风格写的空间SQL都要改写，比如SDO_GEOMETRY的构造、SDO_UTIL系列函数、空间关系判断，全部要换成DMGEO.ST_*风格。不管哪种，对于项目来说，表越多、SQL越多，改造量越大，无疑也就在迁移的平滑性上有所下降
• DM9：同样的几何对象，使用原生DTS迁移，直接落成 SYSSDO.SDO_GEOMETRY(2002, …)。举例：2002是SDO_GTYPE 编码，表示二维线要素——和我们Oracle数据的要素类型完全对得上。也就是说，DM9在系统内提供了与Oracle同名同构的SDO类型体系，数据不是"转译"过去的，而是"原样"落进了一个兼容的容器。对于国产化替代项目来说，这个差别的价值非常明显：1.表结构零改造，字段类型、SDO_GTYPE、SRID等元信息随数据一起平移；2.应用SQL低改造，SDO_GEOMETRY(2002, …) 构造函数、SDO_ELEM_INFO_ARRAY/SDO_ORDINATE_ARRAY这些写法在达梦里语义一致，历史SQL基本只需要把模式名指过去；3.GIS前台适配成本低，ArcGIS、GeoScene等平台按SDO接口读取数据，接口形态没变。

几何类型的SQL实操

迁移只是第一步，关键是替换后SQL怎么写，是否有很大的变化，以下是在DM9进行的一些初步验证

• 建表与插入（构造函数与Oracle写法一致）

CREATE TABLE t_pipeline (
  id    NUMBER PRIMARY KEY,
  name  VARCHAR2(100),
  shape SYSSDO.SDO_GEOMETRY
);
 
INSERT INTO t_pipeline VALUES (1, '测试管线',
  SYSSDO.SDO_GEOMETRY(2002, 4326, NULL,
    SYSSDO.SDO_ELEM_INFO_ARRAY(1, 2, 1),
    SYSSDO.SDO_ORDINATE_ARRAY(121.47, 31.23, 121.48, 31.24)));

• 常用的几何读取

-- 转文本查看
SELECT SYSSDO.SDO_UTIL.TO_WKTGEOMETRY(shape) FROM t_pipeline;
-- 也可以直接查元数据结构
SELECT s.shape.SDO_GTYPE, s.shape.SDO_SRID FROM t_pipeline s;

• 空间关系与量算（判断相交、距离等）

SELECT p.name FROM t_pipeline p
 WHERE SYSSDO.<关系函数>(p.shape, :定点几何) = 'TRUE';

• 查询几何类型字典值
  这个检索可以在项目中，梳理“库里到底迁了多少张几何表”

ALL_TAB_COLUMNS.DATA_TYPE 里搜SDO_GEOMETRY是搜不到的——达梦把对象类型列显示成 CLASS<对象ID>（如 CLASS523481166）。需要拿 'CLASS'||object_id 关联ALL_OBJECTS反查：
SELECT c.owner, c.table_name, c.column_name
  FROM all_tab_columns c
  JOIN all_objects o ON c.data_type = 'CLASS' || o.object_id
 WHERE o.owner = 'SYSSDO' AND o.object_name = 'SDO_GEOMETRY';

从本次试迁移看速度

本次迁移共登记16410个对象，构成如下：表 14703 张、序列1361个、物化视图234个、包96个、自定义类型4个、表空间12个。GIS相关的S_*表共 47张。
速度上来看有很直观的规律，可以从DTS任务日志直接观察到。点要素接近普通数据的吞吐；线要素尚可；面要素最慢。
当然，以上可能并不一定是绝对性的结论，速度受机器配置、网络、坐标点数、批载参数等多种因素影响，这里只记录我们这套环境（单机测试环境、52G的几何数据）下观察到的现象，供读者参考，不构成对工具的结论。个人体感的可复用经验是：几何大表（尤其面要素）建议在演练阶段单独压测、单独估算迁移窗口，必要时安排先行迁移。

小结

• DTS 的版本选择、策略模板、表空间平迁这些改进，让"工具层"的迁移越来越顺滑
• DM9对Oracle SDO几何类型的原生兼容迁移——从ST转译到SYSSDO直落，表结构和历史SQL的改造成本都大幅下降；
• 几何大表的速度特征值得在演练阶段重点关注——点要素接近普通表吞吐，面要素明显更慢，提前识别、提前安排，迁移窗口就不会被动。

#达梦数据库 #达梦同行者征文