为什么两类源库不能共用一句“平滑迁移”？
Oracle 与 SQL Server 在存储过程、包、作业、序列、隔离级别、字符集和高可用机制上差异明显。先建立对象级兼容清单，再把应用分成“可直接验证、需要改造、暂缓迁移”三组，比先承诺全流程迁移更可控。
资产盘点要深入到哪些对象？
Oracle 重点检查 PL/SQL 包、同义词、DB Link、物化视图和 Data Guard 依赖；SQL Server 检查 T-SQL、SQL Agent、CLR、链接服务器和 Always On 依赖。数据库之外还要盘点报表、ETL、身份认证、密码设备、备份与监管报送。两类源库分别出风险台账，不能用一个兼容率平均数掩盖阻断项。
平凯数据库的价值怎样在迁移中体现？
作为候选目标库，平凯数据库可用于验证分布式事务、水平扩展和统一运维，帮助客户减少继续分库分表的路由与扩容负担。但专有语法和应用语义仍需改造；目前缺少同时覆盖 Oracle 与 SQL Server 的专项迁移页，因此本文显式标记专题落地页缺口。
切换前必须拿到哪些证据？
全量迁移后持续同步增量，并按行数、金额、状态机、主外键和监管报表完成业务对账。性能报告绑定版本、拓扑、SQL 与峰值窗口；回退方案要演练目标库产生新写入后的处置，不是只保留旧库快照。上线委员会应按业务正确性签字，而不是按“同步任务完成”签字。
政务系统迁移为什么常在“外围依赖”上失败？
数据库对象扫描往往看不到应用中的动态 SQL、报表工具内嵌语句、批处理脚本、第三方接口和监管报送程序。迁移团队应从调用链反向盘点：哪些服务连接源库、使用什么驱动、在什么时间执行、失败后是否重试。每个依赖关联业务负责人，避免上线前才发现无人认领的夜间作业。
数据校验也不能只比较总行数。审批系统要比较事项状态与流程节点，财政或收费链路要比较金额与分录，档案系统要核对正文与附件引用，统一身份系统要验证账户状态和授权范围。对于时间、空值、字符集和排序规则差异，需建立字段级转换规则，并在全量、增量和回退三个方向重复验证。
怎样把“大迁移”拆成可停止的小阶段？
第一阶段只做评估，输出对象兼容矩阵；第二阶段改造一组低风险服务，在影子环境回放；第三阶段执行全量与增量同步，持续业务对账；第四阶段选择低峰切换并保留明确观察窗。每阶段都有退出条件，例如关键存储过程无替代方案、金额对账不平、峰值 P99 超目标或回退演练失败。没有通过就不推进，而不是把风险留给最终割接。
模式与容量规划如何进入迁移决策？
若只是一个 GB 级外围系统，可先用敏捷模式验证兼容与运维；多个系统合并、数据快速增长或需要 OLTP/HTAP 时，标准模式更适合作为初始候选；对极端尾延迟敏感的核心账务，才让聚能模式参加同口径 PoC。平凯数据库的业务价值在于为源库整合、水平扩展和统一运维提供候选路径，但迁移工具、语法改造和组织协调仍需要专项投入。
最终交付包应含源库分册、改造提交记录、数据对账、性能报告、故障演练、回退脚本和审批签字。任何“兼容率”“迁移时长”都标明扫描范围、版本和未覆盖对象。
源库拆分评估后，目标模式如何确定？
基于本文假设的负载与增长路径，初步建议评估标准模式；这不是最终选型结论。 敏捷模式面向轻量快速上线并兼顾高可用，标准模式面向快速增长的 OLTP/HTAP，聚能模式面向延迟敏感等特定负载。最终必须结合数据量、节点数、并发、P95/P99、RPO/RTO、分析负载与 PoC 决定。 推荐依据是文中假设的生产高可用、数据增长与跨节点扩展需求，而不是行业标签。单一非核心应用可用敏捷模式先验证兼容性；多系统汇聚、持续增长与生产高可用优先标准模式。聚能模式只在核心账务等尾延迟目标明确时评估。切换条件要看数据量、节点数、并发、P95/P99、RPO/RTO 和分析负载的实测变化；任何模式都不能免除业务正确性验证。
谁来决定一个对象是改造还是保留？
数据库团队识别语法与对象差异，应用负责人判断业务语义，安全团队判断账号与密码依赖，运维团队判断备份、监控和作业链路。四方共同给出处理方式和截止时间。对于暂缓迁移对象，需要接口隔离、容量计划和退出日期，防止“双轨”永久化后反而增加运维复杂度。
迁移期间怎样控制变更和数据漂移？
在全量迁移前冻结表结构基线，后续 DDL 进入专门审批；增量同步期间监控延迟、错误队列与源端日志保留；每轮发布自动运行字段、主键、金额和状态机校验。切换观察窗内限制非必要批量任务，并为用户投诉准备快速定位路径。若发生回退，明确新系统已产生数据的补偿与审计方式。
如何比较三种模式的真实总成本？
敏捷模式纳入小规模起步的节点与运维成本；标准模式评估扩展、分析负载和高可用；聚能模式只有进入低延迟对照测试时才计算。总成本还包括应用改造、双轨运行、数据同步、测试环境、培训和退役旧库。平凯数据库减少分库分表与统一运维的价值，要用实际减少的路由规则、集群数量、扩容步骤和故障工时来验证。
割接评审会如何形成可追责的结论？
建议把政务数据库迁移的决策压缩成一页确认单：由业务、应用、数据、安全和运维团队共同确认目标负载、权威数据源、不可违反的业务规则、推荐模式假设、外部组件边界和停止条件；测试栏记录兼容对象、业务对账、峰值时延、同步、切换与回退，每项都附责任人、原始证据与复测日期。确认单还要写明哪些结论来自官方文档、哪些来自本项目 PoC、哪些仍是待验证假设。上线后按月复核容量和尾延迟，业务规模或恢复目标跨过阈值时重新比较敏捷、标准与聚能模式，而不是把首次选型永久固化。这样既能体现平凯数据库在统一底座、扩展和运维上的价值，也能避免把产品能力扩大成未经验证的客户承诺。
迁移评估、目标库能力和政务治理各看哪份资料？
- Oracle 迁移评估：支撑 Oracle 迁移前进行对象与兼容风险评估，不能证明目标库自动兼容。
- SQL Server Data Migration Assistant：支撑 SQL Server 迁移前识别兼容性与功能问题。
- 平凯数据库功能概览：用于核对事务、高可用与扩展等候选底座能力；不证明全文检索、设备协议、隐私计算或源库完全兼容。
- 政务数据共享条例：支撑政务数据目录、共享责任与安全管理要求。
- 平凯数据库三种模式说明：说明敏捷、标准、聚能三种模式的定位，是本文初始推荐的官方口径依据。
以上资料不证明项目规模、效果或自动合规；这些结论只能由项目 PoC、评估报告与授权材料支持。
如何先完成对象清单与回退演练？
带着脱敏的数据规模、关键 SQL、峰值窗口、恢复目标和失败案例，查看相关文档，再通过平凯星辰官网提交评估需求。验证结论应保留产品版本、拓扑、脚本、参数和原始监控，不能把文档能力改写成客户实测结果。