# GIS迁库不重画地图：Oracle Spatial到金仓KES的亿级图斑迁移复盘
**2TB图斑数据、12张空间要素表、迁移窗口4小时**——这是某省级自然资源项目给数据库团队下达的硬指标。原系统基于Oracle Spatial，承担着全省地类图斑、生态红线、规划用地的“一张图”管理。**换数据库不难，难的是让ArcGIS Server不调一行代码、让前端地图服务不中断**。
这套从Oracle到金仓KES的GIS数据迁移方案，如今已沉淀为可复用的全流程操作手册。
## 一、GIS迁移的特殊性：空间数据不是普通表
**普通业务表迁移关注字段映射、主键约束、数据行数；GIS表迁移多出两个致命变量**：空间字段的SRID（空间参考标识）完整性，以及**ArcGIS地理数据库的注册机制**。
直接导出再导入的方案行不通。实验室内测发现：**若未提前在KES端启动地理数据库，迁移后的要素类虽在库中，ArcMap却识别为“普通表”，无法拖拽渲染**。**GIS迁移的流程依赖关系必须遵守**：非GIS数据先走，GIS数据后走；平台注册必须在数据落地之后立即执行。
## 二、前置动作：把KES“装扮”成Oracle Spatial
迁移启动前，目标端需要完成**GIS能力的显式安装与用户规约**。这不是可选步骤，而是必须项。
```sql
-- 创建专用用户与模式（强制使用sde）
create user sde superuser;
alter user sde password 'Kingbase@2026';
create schema sde;
alter schema sde owner to sde;
-- 安装完整空间扩展
create extension postgis;
create extension postgis_raster;
create extension postgis_topology;
create extension fuzzystrmatch;
-- 针对Oracle迁移的兼容补丁
CREATE OR REPLACE FUNCTION append_srid(srid IN INTEGER,kwb IN blob)
RETURN blob AS ...
```
**sde用户、sde模式是硬性约束**。若将GIS数据迁至其他模式，ArcGIS注册脚本必定报错“ERROR 001400”。
## 三、分仓迁移：KDTS负责非GIS，ArcGIS负责GIS
**千万级图斑不能全走同一通道**。策略拆分为二：
**第一路：非GIS表（属性表、配置表、权限表）**——使用金仓KDTS迁移工具，**SHELL版配置源端Oracle与目标KES，指定表清单，批量写入阈值调至1000条/批**。亿级地类图斑测试中，KDTS完成全量迁移耗时约1小时，较传统导出导入方式效率提升4至5倍。
```yaml
# datasource-oracle.yml 配置片段（SHELL版）
sources:
- dbType: oracle
url: jdbc:oracle:thin:@源端IP:1521/ORCL
username: SDE
schemas: SDE
talbe-includes: POINT,LINE,POLYGONT
```
<"v1.p5k3.org.cn"><"s8.p5k3.org.cn"><"f0.p5k3.org.cn">
**关键约束**：源端必须使用Oracle SDE用户，目标端必须使用Kingbase SDE用户，**表级权限与模式所有者必须对齐**，否则后续注册步骤报错。
**第二路：GIS空间要素类（含SDO_GEOMETRY字段）**——**禁止用KDTS直接迁移**。正确路径是：**ArcMap连接两端数据库，右键拖拽复制数据集**，或通过`acrpyRegisterWithGeodatabase.py`脚本批量注册。
## 四、注册脚本：让ArcGIS“认”出新家
数据落地后，ArcCatalog中查看要素类可能显示为灰色。**这不是数据丢失，是地理数据库元信息未注册**。
```bash
# 执行注册脚本（务必在ArcGIS所在机器运行）
c:\Python27\ArcGIS10.8\python.exe acrpyRegisterWithGeodatabase.py
```
脚本修改要点：将`arcpy.env.workspace`值替换为ArcMap中已启动地理数据库的KES连接串。执行成功后，要素类恢复可拖拽、可发布状态。
**常见报错“ERROR 001050”均因workspace配置错位**，**将数据库连接串完整粘贴至脚本对应变量即可解决**。
## 五、性能反超：KES空间计算实测数据
该省项目迁移完成后，**2000万级图斑图层缩放响应时间降低约30%**。核心调优手段有二：
**空间索引显式重建**：Oracle迁移后空间索引需在KES端重新构建。采用GIST索引策略，覆盖高频查询字段。
```sql
CREATE INDEX idx_dltb_shape ON dltb USING GIST (shape);
```
<"z4.p5k3.org.cn"><"j6.p5k3.org.cn"><"n3.p5k3.org.cn">
**复杂空间函数下推**：KES KGIS组件提供近700个空间函数，与原Oracle Spatial语义对齐。**“缓冲区分析+属性过滤”混合查询下，KES响应时长较原库缩短约25%**，部分场景反超。
## 六、复盘：GIS迁移的三个不可逆判断
**第一，必须按“非GIS→GIS”顺序执行**。反之将触发ORA-错误与KES端对象占用冲突。
**第二，必须保留SDE用户完整性**。表所有者、模式名、数据库连接用户三者必须一致，**注册机制对用户上下文高度敏感**。
**第三，必须预留回滚机制**。GIS迁移验证不仅看记录数，还需**人工拖拽10个以上不同缩放层级的图斑，肉眼比对图形位置与属性标签是否偏移**。
**从Oracle Spatial到金仓KES，2TB图斑、4小时窗口、0应用改动**——这套流程已不是实验室假设，而是每年近2000个系统迁移工程中反复验证的标准动作。**GIS迁移的终点不是数据落地，而是地图服务仍能双击打开、右键查询**。做到这一点，才算“全流程”。