国产数据库迁移技术规范的核心要求是"结构先迁、数据后迁、应用配合改写、全程校验比对"：先把表结构、索引、约束转换到目标国产数据库，再用迁移工具做全量加增量数据同步，同时改写应用里不兼容的SQL和存储过程，每一步都用行数和业务结果做校验。在贵阳，数据库迁移是信创改造中工作量最大、风险最高的一环，按规范分步走能避免数据丢失和业务中断。

迁移前的准备工作

兼容性评估

先盘点原数据库用到了哪些特有功能：Oracle的层级查询、外连接写法、存储过程、触发器、序列、大对象类型，SQL Server的自增主键、特定分页语法。逐项列出哪些目标国产数据库支持、哪些要改写、哪些没有对应能力需要换思路，形成兼容性评估报告。

环境与容量准备

准备好目标数据库服务器，配置CPU、内存、存储，按原库数据量和未来三到五年增长预估容量，别刚迁完就满盘。字符集统一为UTF-8，排序规则、时区设置提前对齐，避免迁完才发现时间和排序对不上。

结构迁移怎么做

用迁移工具把建表语句、字段类型、主外键、索引、默认值转换到目标库。字段类型映射是重点：原库的number、varchar2、clob等类型要对应到国产库的等价类型，注意长度和精度不要丢。迁移完后要人工核对一遍关键表结构，特别是主键、非空约束和索引，这些直接影响性能和数据正确性。

数据迁移的两阶段策略

全量迁移

第一次把历史数据整体搬到目标库。大表要分批、并行搬，避免单次事务过大拖垮源库。搬完后做表行数比对和关键字段抽样比对，确认数量一致、内容正确。

增量同步与切换

全量迁移期间业务还在原库写数据，切换前要再做一次增量同步，把这段时间的新数据补齐。反复同步几轮，延迟缩小到秒级后，选业务低峰期停业务、做最后一次增量、切应用连接到新库。在贵阳项目中，这一步通常安排在周末夜间，把对业务的影响降到最小。

应用层SQL改写

应用里的SQL要逐条排查：分页写法、字符串函数、日期函数、外连接写法、大小写敏感规则都可能不同。存储过程和触发器是重灾区，复杂的业务逻辑可能要改用应用层代码实现。改写后要重新分析执行计划，为大表补索引、更新统计信息，因为迁移后优化器是全新的，原来的索引设计不一定还合适。

数据一致性校验方法

迁移是否成功，最终靠校验说话。第一层是表行数比对，每张表的记录数两边要完全一致；第二层是关键字段抽样比对，按主键随机抽取一批记录，逐字段核对内容；第三层是业务报表比对，把源库和目标库跑出的同一份统计报表结果逐项对照，数值要能对上。三层校验都过，才能认定数据迁移可靠。

大表和大字段要单独处理：含图片、附件的大对象表迁移慢，容易超时，要分批迁移；浮点型、金额型字段要注意精度不要在类型转换中丢失。在贵阳政务和金融类项目里，历史数据动辄上千万行，校验脚本要提前写好、自动跑，不能靠人工数。

性能与稳定性验证

迁移完做压力测试，对比改造前后的响应时间和资源占用，重点看报表类大查询是否变慢。建立慢SQL监控，把耗时长的语句逐条优化。上线前做72小时稳定性测试，确认没有连接泄漏、锁等待、数据不一致等问题。在贵阳政务类项目里，报表和历史查询性能往往是验收的关键，必须提前压测、提前优化。

回滚与收尾

切换后原库要保留一段时间，既能回滚也方便业务人员核对数据。备份策略要重新建立：全量备份周期、日志归档、恢复演练都要按国产数据库的特性重新配置。数据库迁移不是搬完数据就结束，而是要把运维体系一起迁过来，后续才能长期稳定跑。

还要注意字符集和排序规则带来的隐性差异。原库和目标库对中文的排序、大小写敏感、空白字符处理可能不同，迁移后历史数据按某个字段排序结果和原来不一致，业务人员会以为数据错了。这类问题要在测试阶段用真实报表对比出来，必要时调整字段 collation 设置或在查询里显式指定排序规则，不要等上线后被业务部门提出来才解释。