从 Oracle、SQL Server、DB2 或 Sybase ASE 迁往开源数据库，真正困难的通常不是“把表建出来”，而是在可控时间内证明数据、业务语义、性能和运维能力都没有失真。Percona 与 HexaCluster 的合作，正是把这段高风险路径拆开：Percona 提供开源数据库能力、发行版、Operator 与企业支持，HexaCluster 负责评估和迁移工程，让项目不必天然演变成持续数年的咨询计划。
迁移速度来自更早暴露问题
数据库迁移最常见的误判，是按表数量或数据容量估算工作量。容量决定搬运时间，却不能完整反映改造难度。真正拖慢项目的往往是隐藏在数据库内部的行为：
- PL/SQL 包、存储过程、触发器和定时任务承载了业务逻辑；
- Oracle 特有的数据类型、序列、同义词或分区策略需要重新设计；
- 应用依赖特定的事务隔离、锁等待和空值语义；
- 报表 SQL 使用了目标数据库不兼容的函数或优化提示；
- 运维团队尚未建立备份恢复、监控、扩缩容与故障切换流程。
因此，评估阶段不应只输出一份对象清单，而要把对象转换成可排期的工作包。例如，可以给每个应用建立四类分数：SQL 兼容性、数据库端代码复杂度、数据同步难度和停机敏感度。先迁移低复杂度但有代表性的服务，用真实结果修正后续估算。
下面这段 Oracle SQL 可以作为对象盘点的起点。运行前将 APP_OWNER 替换成实际 schema 名称，并使用能够读取 ALL_OBJECTS 和 ALL_TAB_COLUMNS 的账号：
-- oracle_inventory.sql
SET PAGESIZE 500
SET LINESIZE 200
SET VERIFY OFF
DEFINE owner_name = 'APP_OWNER'
PROMPT === Objects by type ===
SELECT object_type, COUNT(*) AS object_count
FROM all_objects
WHERE owner = UPPER('&owner_name')
GROUP BY object_type
ORDER BY object_count DESC;
PROMPT === Columns using types that need explicit review ===
SELECT owner, table_name, column_name, data_type, data_length
FROM all_tab_columns
WHERE owner = UPPER('&owner_name')
AND data_type IN ('NUMBER', 'DATE', 'TIMESTAMP WITH TIME ZONE',
'CLOB', 'BLOB', 'RAW', 'XMLTYPE')
ORDER BY table_name, column_id;
PROMPT === Invalid database objects ===
SELECT object_type, object_name, status
FROM all_objects
WHERE owner = UPPER('&owner_name')
AND status <> 'VALID'
ORDER BY object_type, object_name;
执行方式：
sqlplus -s 'migration_user/password@//oracle-host:1521/service' @oracle_inventory.sql
这份结果不能自动给出目标架构，但能快速发现需要人工决策的区域。目标是 PostgreSQL、MySQL，还是其他开源数据库，应在评估业务语义、兼容性和运维要求后决定，而不是先选产品再强行改造所有工作负载。
把“迁完了”改成一组明确的验收门槛
迁移项目需要区分三种正确性：结构正确、数据正确和行为正确。只比较表数量，无法发现小数精度变化、时区偏移、字符截断或触发器行为差异。
可以为每一批迁移建立如下验收门槛：
- 结构门槛：表、索引、约束及权限已映射，所有例外都有记录。
- 数据门槛：关键表行数、聚合值和抽样哈希一致。
- 行为门槛：核心 API、批处理和报表通过回归测试。
- 性能门槛：关键查询的 P95 延迟和吞吐量落在约定范围内。
- 运维门槛：备份恢复、告警、故障转移及容量扩展经过演练。
下面是一个可直接运行的最小校验器，用于比较源端和目标端导出的表级快照。生产环境中可将 row_count 扩展为分区行数、金额汇总和按主键分段计算的哈希。
先创建源端快照：
{
"customers": {"row_count": 125000, "sum_id": 7812562500},
"orders": {"row_count": 840321, "sum_id": 353070110181}
}
保存为 source.json，再以相同格式创建 target.json。随后保存并运行以下脚本：
#!/usr/bin/env python3
# validate_snapshot.py
import json
import sys
from pathlib import Path
def load(path: str) -> dict:
return json.loads(Path(path).read_text(encoding="utf-8"))
def main() -> int:
if len(sys.argv) != 3:
print("Usage: python validate_snapshot.py source.json target.json")
return 2
source = load(sys.argv[1])
target = load(sys.argv[2])
failed = False
for table in sorted(set(source) | set(target)):
if table not in source:
print(f"FAIL {table}: missing from source snapshot")
failed = True
continue
if table not in target:
print(f"FAIL {table}: missing from target snapshot")
failed = True
continue
differences = {
key: (source[table].get(key), target[table].get(key))
for key in set(source[table]) | set(target[table])
if source[table].get(key) != target[table].get(key)
}
if differences:
print(f"FAIL {table}: {differences}")
failed = True
else:
print(f"PASS {table}")
return 1 if failed else 0
if __name__ == "__main__":
raise SystemExit(main())
python validate_snapshot.py source.json target.json
脚本以非零状态码报告差异，因此可以接入 CI/CD 或割接流水线。需要注意的是，简单聚合可能发生碰撞，也不能证明每一行都相同；对于财务、订单等高价值数据，应结合分段哈希、业务对账和抽样明细检查。
割接不是一个时间点，而是一套可撤销流程
安全迁移通常需要先完成全量装载，再持续同步增量变更。应用可以按只读流量、内部流量、少量写流量和全部流量逐步切换。具体同步工具取决于最终选定的源端、目标端和迁移方案，不能在评估之前一概而论。
割接运行手册至少应写清楚：
- 何时冻结数据库结构变更；
- 如何测量复制延迟以及允许的最大值；
- 谁负责停止旧系统写入，谁负责开放新系统写入；
- 哪些测试必须在切流后立即执行；
- 出现何种错误率、延迟或数据差异时必须回滚；
- 回滚期间新产生的数据如何处理，避免双向写入造成冲突。
不要把“数据库可以连接”当作割接成功。更可靠的完成标准是：业务验收通过、监控无异常、备份已经生成并验证可恢复，而且旧环境保留到约定的观察窗口结束。
合作模式的价值在职责边界
从现有信息看，这项合作的重点并不是宣称迁移可以完全自动化，而是组合两类能力：HexaCluster 提供前期评估和迁移工程，Percona 提供开源数据库专业能力、自己的发行版、Operator 以及企业支持。这种分工有助于把一次性迁移工作与长期生产运维连接起来。
采用类似方案前，团队仍应明确几个问题：
- 目标数据库和版本是否覆盖当前使用的关键语义？
- 自动转换、人工重写和应用改造各自占多少比例？
- 性能基线、停机窗口与回滚阈值是否已经量化？
- 上线后由谁处理补丁、备份、故障和容量规划？
- 验收证据能否由内部团队复现，而不是只存在于顾问报告中？
Oracle 迁移无法靠一个转换按钮消除风险。更现实的路线，是先盘点依赖，再按批次改造，用自动化证据验证每一步，并在割接前证明可以恢复和回滚。合作伙伴能缩短学习曲线，但清晰的验收标准和业务责任仍必须掌握在迁移团队自己手中。