企业官网建设流程全解析

简介：《KingbaseES GIS数据迁移方案》是一份面向数据库管理员、GIS开发与数据迁移实施人员的技术文档，聚焦将ArcGIS、GeoScene、SuperMap等平台的空间数据迁移至人大金仓KingbaseES V8.6。文档先介绍KingbaseES对矢量、栅格数据的存储与处理能力，再分别给出基于KDTS工具的ETL迁移流程、利用ArcGIS/GeoScene软件直接迁移的方法，以及SuperMap平台和第三方通用格式数据的入库路径，并配有迁移结果验证与常见问题汇总。资源包仅含1个PDF文件，约2.76MB，章节按平台组织，便于按目录快速定位对应方案。目前已有136人学习。读者可从中获得从源库连接、目标库配置、表字段选择到迁移后完整性核对的完整操作参考，也能借助FAQ排查迁移中的常见问题，适合作为国产数据库GIS迁移项目的落地手册。

1. 装完数据库才发现 geometry 存不进去

去年接手一个 ArcGIS 存量库的迁移，源端是 Oracle Spatial，几十个要素类、上千万条记录。当时判断很简单：装 KingbaseES V8.6，建库，用工具导过去。第一轮导完，目标库里表都在、字段也在，唯独空间字段是空的，ArcGIS 打开图层直接报错。后来才定位到 KGIS 扩展根本没装上——KingbaseES 的空间能力不是默认开关，得先装扩展、再验证 geometry 类型，然后才谈 KingbaseES GIS 数据迁移。这套环境装不好，表面看库能连、表能建，实际上空间索引、坐标系、要素类注册全是断的，返工成本比装的时候高十倍。下面把这套环境的安装、配置、迁移、验证按我实际跑过的顺序铺一遍。

2. 环境清单与安装：KingbaseES V8.6 上把 KGIS 装进实例

2.1 四个组件的版本先钉死，别边装边改

GIS 数据迁移这条链路上不止一个软件，装之前先把清单列出来，装到一半再回头改版本是最容易翻车的环节。按 V8.6 文档给出的组合，实际要落地的是四块：数据库本体、空间扩展、迁移工具、GIS 客户端。

这里有个反直觉的点：很多人的第一反应是先把 KDTS 装好，觉得迁移工具才是主角。实际上数据库和 KGIS 没装对，KDTS 迁完也只是把普通表搬过去，空间字段照样是空的。顺序应该是数据库 → 扩展 → 验证 geometry → 再装迁移工具和客户端。

2.2 初始化 V8.6 实例：目录、字符集、端口三件事

安装包解压或图形化安装完成后，真正决定后面顺不顺的是初始化参数。我习惯把软件目录和数据目录分开，数据目录单独挂盘，后面做备份、做迁移演练都方便，不用去翻安装路径。

# 建独立运行用户，数据库进程不要用 root 跑 useradd -m kingbase echo 'kingbase' | passwd --stdin kingbase # 软件目录与数据目录分离，/data 单独挂盘 mkdir -p /opt/Kingbase/ES/V8 mkdir -p /data/kingbase/data chown -R kingbase:kingbase /opt/Kingbase /data/kingbase chmod 700 /data/kingbase/data

chmod 700这步不是洁癖，初始化工具有权限校验，数据目录对同组或其他用户可读会直接拒绝初始化。做完切到 kingbase 用户执行初始化：

su - kingbase # -D 数据目录，-U 初始管理用户，-E 字符集，--locale 排序规则 /opt/Kingbase/ES/V8/Server/bin/initdb \ -D /data/kingbase/data \ -U system \ -E UTF8 \ --locale=C

-E UTF8在 GIS 场景基本是必选，要素类的属性表里中文地名、备注字段很多，字符集选错后面要么乱码要么导入截断。--locale=C是个取舍：纯空间库、不跑业务排序，用 C 最稳，索引行为可预期；如果这个库同时挂业务表、要做中文排序，那就换成--locale=zh_CN.UTF-8，代价是排序规则跟源端 Oracle 可能有细微差异，比对数据时要提前知道这一点。

初始化完改两个参数再起库：

# 端口按现场规划固定，别留默认值；listen_addresses 按需放开 sed -i "s/^#port = .*/port = 54321/" /data/kingbase/data/kingbase.conf sed -i "s/^#listen_addresses = .*/listen_addresses = '*'/" /data/kingbase/data/kingbase.conf # 启动，日志单独落文件，排错时第一时间看它 mkdir -p /data/kingbase/log /opt/Kingbase/ES/V8/Server/bin/sys_ctl \ -D /data/kingbase/data \ -l /data/kingbase/log/start.log start

port是后面最容易出问题的一个值，选 54321 只是我这边统一规划的习惯，你按现场定，但要记住这个数字，因为 ArcGIS 连接时非 5432 端口必须显式写在实例名后面，这一步漏了就是连不上。listen_addresses = '*'只适合内网迁移窗口期，迁完收紧成具体网段。启动工具在不同小版本上可能叫sys_ctl或kingbase，看 bin 目录里哪个在。

起来之后立刻连一下，确认实例可用：

ksql -U system -p 54321 -d test -c "select version();"

2.3 装 KGIS 扩展：一条 CREATE EXTENSION 前后的检查

实例起来只是空壳，空间能力要靠扩展挂上去。我不在默认库里装，单独建一个 GIS 库，字符集与实例保持一致，避免半路出现编码转换。

-- 单独建库，template0 保证字符集完全按指定值来 CREATE DATABASE gisdb WITH ENCODING 'UTF8' TEMPLATE template0; -- 切到 gisdb 再装扩展，扩展名以安装介质里的 control 文件为准 \c gisdb CREATE EXTENSION kgis; -- 验证两件事：扩展在不在、geometry 类型注册没注册 SELECT extname, extversion FROM sys_extension WHERE extname = 'kgis'; SELECT typname FROM sys_type WHERE typname IN ('geometry', 'geography');

第一条查询返回空，说明扩展压根没装进去；CREATE EXTENSION报 “is not available”，说明安装介质里的扩展文件没铺到实例的扩展目录，这种情况下先查SELECT * FROM sys_available_extensions WHERE name LIKE '%gis%';，能列出来才有得装，列不出来就是介质和实例版本不配套。第二条查询是关键，geometry类型必须在sys_type里能查到，查不到意味着后面建空间表时这个字段类型根本不存在——我那次翻车就是跳过了这一步，表建出来了但空间列是普通文本，ArcGIS 认不出来。

有些实例保留了pg_前缀的系统视图，sys_extension换成pg_extension一样能查，两个都试一下不费事。

装完扩展顺手把GIS专用模式建出来，跟业务表隔开：

CREATE SCHEMA gisdata AUTHORIZATION system; COMMENT ON SCHEMA gisdata IS 'GIS 要素类专用模式，与业务表隔离';

3. 配置 GIS 能力：空间元数据、ArcGIS 连接与库参数

3.1 空间表的落位与索引前的基础配置

扩展装好之后，空间表落在哪个模式、用什么表空间，需要在迁移之前定下来。我一般的做法是：要素类统一进gisdata模式，空间索引单独放一个表空间，跟数据文件分开。理由很实际——空间索引建起来 IO 很猛，跟数据文件抢同一块盘，大表迁移窗口里能把整个实例拖慢。

-- 空间索引独立表空间，目录提前在操作系统层建好并授权 CREATE TABLESPACE tbs_gis_idx LOCATION '/data/kingbase/gis_idx'; -- 要素类表统一放 gisdata 模式，索引指定表空间 ALTER TABLE gisdata.roads SET TABLESPACE tbs_gis_idx;

LOCATION指向的目录必须是空目录、属主是数据库运行用户，否则建表空间直接失败。这一步在迁移前做，比迁移后补救省事得多，因为表一旦有数据，再挪表空间就是一次全表重写。

空间索引本身不建议在迁移过程中边导边建。KDTS 迁的是表结构和数据，索引、主键、约束这些“非对象”可以在任务参数里控制是否一起迁。我的习惯是：先只迁结构和数据，迁完统一建空间索引，一次建完比逐表建快，出问题也好定位是数据问题还是索引问题。

3.2 ArcGIS 端连 KingbaseES：instance 写法与授权文件

客户端侧最容易错的是连接串。ArcCatalog 里添加数据库连接时，实例这一栏不是只填 IP，端口非 5432 时必须写成主机,端口的形式，比如10.10.20.30,5444。只填 IP，客户端会拿默认端口去敲，敲不通就报连接失败，看起来像网络问题，实际是写法问题。

建连接之后还有一步不能跳：在 ArcCatalog 里右键这个连接，选“启动地理数据库”，源库和目标库都要做一次。这一步是在库里写地理数据库的系统表，不做，后面迁过去的要素类在客户端里就是一堆普通表。配置时会让你指定 ArcGIS 的授权文件，这里只能用*.ecp文件，别的格式选都选不上，我第一次配的时候拿了个别的授权文件在对话框里翻了半天，纯属浪费时间。

3.3 大表迁移前要动的几个库参数

KDTS 默认会开 100 个连接跑迁移，源库目标库各算一份，加上客户端连接，max_connections给 300 是比较稳的余量。批量写入和空间运算都吃内存，下面这几项按机器规格调，别照抄：

# kingbase.conf，按物理内存比例估，不要拍脑袋写大 shared_buffers = 4GB # 约物理内存 25% work_mem = 64MB # 空间运算排序用；连接数 × work_mem 别超内存 maintenance_work_mem = 1GB # 建空间索引、重建表时用 max_connections = 300 # KDTS 默认 100 连接，留足余量 wal_buffers = 64MB

work_mem是最容易写错的一项，很多人一看空间运算慢就往上加，加到 512MB，结果 100 个并发连接一乘就是 50GB，机器直接开始换页，比不加还慢。常见做法是按物理内存 / (max_connections × 4)估一个上限，再根据实际慢查询微调。maintenance_work_mem只在维护操作时占用，可以给大一点，建空间索引的速度差别很明显。

改完参数重启实例，然后拿一条真实的空间查询压一下，确认没把库压死：

-- 用真实表压一条空间过滤，看执行计划和耗时 EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM gisdata.roads WHERE ST_Intersects(geom, ST_MakeEnvelope(116.0, 39.0, 117.0, 40.0, 4326));

这条语句里ST_MakeEnvelope的最后一个参数是 SRID，必须跟表里 geom 字段的坐标系一致，不一致查出来是 0 行——不是数据丢了，是坐标系对不上。迁移前后各跑一次，行数应当能对上，这也是后面验证环节的基础。

4. KDTS 迁移任务配置：从建连接到四步建任务

4.1 源库与目标库连接：URL 里的 SID、ServiceName 和 UnixDomainSocket

KDTS 的迁移能力靠插件动态加载数据库访问接口，所以连接信息填错，报错往往很含糊。新建连接时要填的字段是固定的：连接名称、数据库类型、数据库版本、服务器地址、端口、用户名、密码、数据库、驱动、URL、连接参数。

源库是 Oracle 时，URL 这一栏要在SID和ServiceName之间做选择，这个选择不是随便点的：

• SID是实例名，单实例、非集群环境用它，连的是具体那个实例。
• ServiceName是服务名，集群环境下各节点 SID 可能不一致但服务名统一，用它客户端配置不用跟着节点改。

选错的表现是连接测试能过、迁移时报找不到对象，或者反过来连都连不上。不确定就问源库的 DBA 要service_names参数值，别猜。

目标库是 KingbaseES 时，URL 类型在JDBC和UnixDomainSocket之间选。KDTS 和 KingbaseES 装在同一台 Linux 机器上时用 UnixDomainSocket，走本机进程间通信，省掉网络栈开销，大表写入快一截；两者不在同一台机器就只能 JDBC。我这边迁移窗口里 KDTS 一般和目标库部署在同一台，直接选前者。

连接参数那一栏可以自行增删，不是必填，但遇到编码、时区不一致时，在这里补一条比改全局配置安全。

4.2 新任务四步：选源、选模式、选对象、配参数

新建迁移任务的流程是四步，每一步都有硬性校验，跳不过去。

第一步选数据源：填任务名称（不能重名），然后指定源库连接和目标库连接，或者当场新建。任务名我习惯带上日期和库名，比如arcgis2kb_20240918，后面在任务列表里翻日志好找。

第二步选模式：勾选要迁的模式，需要系统模式就勾上“包含系统模式”复选框。这一步至少得选一种模式，一个都不选直接报错，任务建不下去。模式多的时候用左上角查询框按关键字过滤，比在长列表里翻快。

第三步选迁移对象：在已选模式下勾表。默认是这个模式下全部表，也可以改成“包含指定表”或“排除指定表”。这里有个坑——选了“包含指定表”但列表是空的，系统会报错卡在这一步，因为它认为你要迁对象但没给对象。添加方式有三种：输入框直接敲表名（多个用逗号分隔、回车确认）、“从列表选择”（支持按模式、表名关键字、数据条数限制检索）、或者下载导入模板填好再“从文件导入”。“排除指定表”操作路径一样，逻辑反过来。

第四步配参数，这一步直接决定迁移跑得快不快、迁完对不对，下一节单独说。参数配完点“保存”就是个预迁移任务，点“保存并迁移”才真正开跑。

4.3 参数怎么调：大表拆分与批量写入的取舍

KDTS 的迁移参数分两块，迁移配置和数据类型配置。下面这张表是我实际用下来最需要动的那几项，括号里是默认值：

大表拆分这块的逻辑值得说清楚：拆分阈值可以按行数、也可以按大小，还能设拆分最大块数。千万级以上的表一定要设，不然迁到 80% 网络抖一下，整个任务失败得从头来，那才叫血泪经验。拆分之后每块独立提交，失败只影响一块。含大对象的表还要单独设“含大对象表游标读取记录数”，因为这个值会覆盖全局的游标读取设置。

“表默认处理方式”有两个复选框：建表/重建表、导入数据。只想迁结构不迁数据，就把“导入数据”去掉；表已经手工建好了，就去掉“建表/重建表”只导数据。默认两个都勾着，直接跑会尝试重建表，如果目标端已经有同名表，先把数据清掉再说。

“非对象设置”里有主键、检查约束、唯一约束、外键、索引、触发器、自动转换对象名、注释，默认全选。我的做法是主键、唯一约束、注释留着，外键和触发器先不迁——外键在大批量写入时会做逐行校验，几千万条数据能拖到你怀疑人生，等数据全落地了再单独建。索引前面说过，迁完统一建。

表名和列名大小写这项默认是“不变”，源端 Oracle 的表名通常是大写，迁到 KingbaseES 后应用里如果用不加引号的小写去查，会报找不到表。这个不是迁移工具的锅，是标识符规则差异，要么迁的时候统一转小写，要么应用侧改写法。

5. 避坑记录：五条把迁移卡住的现场问题

5.1 连接与授权类问题

现象一：ArcCatalog 连接测试一直转圈，最后报连接失败，但同一台机器上用 ksql 能连上。

原因：实例那一栏只填了 IP，没带端口。客户端按默认端口去敲，实例根本不在那个端口上监听；ksql 命令行能连是因为手动指定了-p参数。

解决：实例名写成IP,端口的形式，比如10.10.20.30,5444，逗号不要用中文标点。

现象二：启动地理数据库时，指定授权文件那一步选不上文件，对话框里一片灰。

原因：只能用*.ecp格式的授权文件，其他格式客户端直接过滤掉，看着像权限问题，实际是格式问题。

解决：确认手里的授权文件后缀是.ecp，不是就把对应的那份拿出来。源库和目标库各要做一次启动地理数据库，只做目标库，迁完的要素类依然识别不了。

5.2 迁移执行与对象一致性类问题

现象三：KDTS 新建任务走到第二步就报错，任务建不下去。

原因：模式一个都没勾。或者勾了“包含指定表”，但包含列表是空的——系统认为你要迁对象却没给对象。

解决：至少勾一种模式；用“包含指定表”时，通过输入框、从列表选择、从文件导入三种方式之一把表加进去。表多的时候下载导入模板填好再导，比一条条敲快。

现象四：KDTS 状态栏显示“完成”，但 ArcGIS 里打开连接看不到迁过去的图层。

原因：迁移后的注册没做。ArcGIS/GeoScene 平台迁过去的数据，必须在客户端做一次注册，应用才能正常识别要素类。

解决：在迁移结果目录result/2021-12-02_15-15-15/SDE/AcrpyRegisterScript/下找到acrpyRegisterWithGeodatabase.py，拷到装了 ArcGIS 的机器上，放到形如c:\Python27\ArcGIS10.8的目录里，用 ArcGIS 自带的 Python 解释器执行。路径一定要对上，ArcGIS 桌面自带的解释器版本跟系统里装的那个经常不是一回事，用系统 Python 跑会缺 arcpy 模块。

现象五：千万级的大表迁到一半失败，重跑还是卡在差不多的位置。

原因：没设拆分阈值，整表作为一个事务在跑；或者连接数开太大把源库打满了，源库那边先把会话掐了。

解决：先看日志确认是超时还是被踢，被踢就把数据库连接数降到 20～30 重试；超时就把拆分阈值行数设到 500 万～1000 万，让大表分块提交。批量提交大小也往下压一档，失败代价小一些。

6. 迁移后的验证：注册脚本与三类比对怎么跑

迁移跑完状态栏显示“完成”，只说明工具没报错，不等于数据能用。我这边固定跑三件套：注册脚本、行数比对、几何有效性检查。

注册脚本前面提过，放在迁移输出目录的AcrpyRegisterScript子目录下，拷到客户端机器后用 ArcGIS 自带解释器执行：

# 用 ArcGIS 桌面的 Python 2.7 解释器，不要用系统 Python "C:\Python27\ArcGIS10.8\python.exe" acrpyRegisterWithGeodatabase.py # 参数以脚本内 usage 为准，不确定就先空跑一次看提示

执行完打开 ArcCatalog，刷新连接，要素类应该能正常显示几何类型和坐标系。这里判断的标准很直白：能看到图层、能缩放定位、属性表能翻页，三样都对才算注册成功。

第二件事是行数比对，源端和目标端逐表对，别只看总数：

-- 逐表比对目标端行数，结果跟源库同表核对 SELECT 'roads' AS tab, count(*) FROM gisdata.roads UNION ALL SELECT 'poi', count(*) FROM gisdata.poi; -- 几何有效性：无效几何在客户端表现为渲染失败或面积算成 0 SELECT count(*) FROM gisdata.roads WHERE NOT ST_IsValid(geom);

ST_IsValid返回非零就得处理，常见原因是源端本来就有自相交的面，迁移不会修它，只会原样搬过来。这类数据在源库里一直没被碰过，迁完一跑分析就露馅。

第三件事查坐标系，这个最容易漏：

-- 空间元数据里的 SRID 要和源端一致，不一致说明映射规则动过 SELECT f_table_name, f_geometry_column, srid FROM geometry_columns WHERE f_table_name = 'roads';

SRID 对不上，业务查询范围会整体偏移，而且是那种“看起来有数据、位置就是不对”的偏移，最难查。视图名各版本可能有差异，取不到就直接查扩展注册的元数据表。

这套流程我踩过一次教训之后就一直没敢省：当年图快，行数对上了就直接交付，结果客户那边做空间叠加分析，边界层整体错位，回头重导了一遍。从那以后我每次迁移完，不管多晚多急，ST_IsValid和 SRID 这两个检查都强制走一遍，跑完才敢在交付单上签字。希望帮到你。

本文还有配套的精品资源，点击获取