HIS 改造为什么不能从“搬多少张表”开始？
医院真正要保护的是挂号、收费、医嘱、药房、检验检查和病历写入的业务语义。Oracle 中的表、序列、存储过程、触发器和作业只是实现手段；如果迁移后患者状态、费用分录或医嘱生命周期改变，即使行数完全一致也属于失败。项目第一步应画出关键业务状态机和资金链路，再把数据库对象映射到业务责任人。
第一个问题：哪些 Oracle 专有能力被应用依赖？
盘点 PL/SQL 包、同义词、DB Link、物化视图、分区、序列、自治事务、作业和 Data Guard 相关逻辑，并从应用代码、报表和接口中反向扫描动态 SQL。每个对象标记调用频率、业务时段、替代方案和改造人。评估工具只能发现一部分问题，隐藏在脚本、第三方系统和夜间批任务中的依赖仍需人工确认。
第二个问题：挂号高峰的热点在哪里？
号源、患者主索引、支付流水和队列状态可能形成热点。PoC 不应只跑均匀随机读写，而要回放真实科室、时间和主键分布，覆盖开诊前集中放号、退号重挂、医保接口超时和支付回调重复。观察业务成功率、事务重试、锁等待与 P99，并检查应用幂等是否成立。数据库 ACID 不能替代业务状态机和对账。
第三个问题：历史数据和附件如何分层？
HIS 事务表、电子病历、影像附件、审计日志和历史报表的访问频率不同。先明确权威源、留存期与恢复要求，再决定哪些数据进入目标事务库、哪些进入分析或对象存储。迁移抽样要覆盖字符集、时间精度、空值、金额、小数舍入和附件引用，不能用总行数代替业务校验。
第四个问题：平凯数据库解决什么，不解决什么？
平凯数据库可作为分布式事务底座候选，为容量增长、统一运维和高可用提供演进路径，帮助医院减少按院区或模块拆库后的跨库事务、路由和对账复杂度。但它不会自动改写 PL/SQL，不会替医院定义收费规则，也不能保证所有第三方 HIS 无改造迁移。价值应以实际减少的分片规则、扩容步骤、故障工时和业务中断风险衡量。
第五个问题：三种模式哪一种先进入 PoC？
本文假设是三甲医院核心 HIS、数据持续增长、至少三节点高可用并承载高峰交易，因此初步评估标准模式。敏捷模式可用于外围系统、开发测试或 GB 级轻量业务；聚能模式只在核心交易存在明确尾延迟和极致性能目标时加入对照。合规或医院等级本身不决定模式，最终看数据量、节点、并发、P95/P99、RPO/RTO 和成本。
第六个问题：迁移期间如何持续对账？
全量迁移后进入增量同步，按患者、就诊、处方、医嘱、金额和状态机建立校验。业务变更期间冻结 DDL 基线，新增字段或作业必须同步进入迁移台账。对账差异要能定位到源记录、转换规则和责任人；金额与状态不平立即停止推进。切换前完成至少一次从目标库回退到原链路的演练，并处理目标侧已产生的新写入。
第七个问题：故障恢复从哪里开始计时？
从医生或收费窗口第一次失败开始，到用户链路恢复并完成业务校验为止。分别注入数据库节点、网络、存储、身份服务、医保接口和消息队列故障。数据库选主完成只是一个时间点，应用连接池、缓存和外围依赖是否恢复同样重要。恢复后检查在途事务、重复扣费、医嘱状态与审计链。
第八个问题：上线窗口如何设置停止条件？
停止条件应量化：关键业务差异不为零、P99 超目标、同步延迟超过窗口、回退脚本未验证、审计缺失或值班责任不清，都不得切换。灰度从可隔离院区或业务开始，保留新旧结果比对和快速路由回退。上线委员会按业务正确性签字，而不是按数据库任务“执行成功”签字。
第九个问题：总成本是否包含改造与双轨？
比较硬件、软件、迁移工具、应用改造、测试环境、双轨同步、培训和旧库退役。标准模式可能减少后续分库分表和扩容复杂度，但前期迁移仍需投入。成本收益要用三年容量预测、集群数量、运维工时和故障损失测算，不以单节点价格下结论。
第十个问题：什么证据可以用于采购和对外传播？
保存对象兼容矩阵、改造提交、对账报告、性能脚本、拓扑参数、故障时间线、模式比较和复测结果。只有绑定版本、数据、硬件和窗口的数字才能引用。公开内容不写“无感迁移、完全兼容、零中断”，除非有同口径报告和客户授权。
医院如何避免迁移完成后又回到“谁都不敢改”？
上线后建立 SQL 与对象变更门禁：新存储过程、索引、批任务和接口依赖进入架构评审；每次版本发布自动执行挂号、收费、医嘱和金额回归；容量、尾延迟、同步差异和恢复演练进入月报。若标准模式扩容或分析负载策略发生变化，先在影子环境回放。旧库退役前确认审计、档案和监管查询已迁移，账号与备份按制度处置。这样才能把项目从一次性搬迁变成可持续运营，而不是形成新的技术债。
切换委员会用哪张表做决定？
切换决策表应列出关键业务差异、未改造对象、同步延迟、性能门槛、回退用时和责任人。任一金额或状态差异未关闭，即使性能达标也不得上线。
委员会还需确认观察窗口、旧库退役条件与夜间批任务负责人，避免白天交易正常却在月结暴露遗漏。
Oracle 专有对象应该按什么顺序改造？
先处理阻断核心交易且无替代路径的对象，例如关键 PL/SQL 包、自治事务和跨库调用；第二层处理影响峰值性能或切换窗口的分区、批作业与物化视图；最后处理低频报表和可暂时接口隔离的外围依赖。每个对象记录调用链、业务所有者、改造方案、测试用例、回退方法与完成日期。切换当晚由业务负责人判断语义正确，应用负责人处理代码与连接，数据负责人执行对账，DBA 负责同步和数据库状态，指挥人统一决定继续或回退。任何责任空缺都应视为切换阻断，而不是留到故障发生后临时认领。
本文依据如何对应关键判断？
- Oracle 迁移评估说明：支撑迁移前识别对象、兼容性和风险；不证明目标库自动兼容。
- 平凯数据库功能概览：用于核对候选目标库事务、扩展、备份恢复与运维能力。
- 电子病历应用管理规范：支撑电子病历建立、修改、使用、保存和管理的业务要求。
- 平凯数据库三种模式说明：支撑三种模式的初始选型边界。
以上来源只支撑列明的产品能力、模式定位或治理要求。项目性能、规模、成本、迁移效果与合规结论必须由本项目 PoC、评估报告和授权材料证明。
把现状资料变成可复现的评估
请先整理脱敏的数据量、增长、关键 SQL、峰值窗口、故障历史和恢复目标，查看平凯数据库模式与能力说明，再通过官网提交评估需求。最终报告应保留版本、拓扑、脚本、参数、原始监控、差异与复测记录。