集约化管理的落地规划与风险防控

一、同一实例下的 Schema 规划指南

在同一数据库实例（Instance）下通过 Schema（模式/用户） 进行逻辑隔离，是实现“集约化管理”且保持系统独立性的核心手段。

1. 核心原则

逻辑隔离：每个业务域拥有独立 Schema，表名可重复（如 HIS.PATIENT 和 EMR.PATIENT）。
最小权限：应用连接时只赋予所属 Schema 权限，跨库访问需显式授权。
物理分区：为不同 Schema 指定不同 表空间（Tablespace），便于独立备份和 IO 优化。

2. 四层分级架构模型

建议按数据性质和业务紧密度划分：

层级	Schema 示例	定位	策略
公共主数据层	`MDM_COMMON`	全院共用的字典/标准	信息科统一维护，对其他 Schema 只读。
核心业务层	`HIS_CORE`	高并发核心业务 (挂号/收费)	分配高性能存储 (SSD)，资源优先级最高。
临床文档层	`EMR_DOC`	大数据量文档 (病历/报告)	配合大对象表空间，通过视图访问核心层。
运营职能层	`HRP_FIN`	低频/批量处理 (财务/OA)	限制 CPU/IO 上限，防止拖垮核心业务。

3. 关键技术落地

命名规范：强制统一，如 Schema 用 SYS_<业务>, 表空间用 TBS_<业务>_DAT。
跨库访问：使用 同义词 (Synonym) (如 CREATE SYNONYM PATIENT FOR SYS_HIS.PATIENT)，使厂商代码零修改即可访问其他 Schema 数据。
冲突解决：各 Schema 使用独立序列 (Sequence) 或统一发号器；公共数据遵循“谁产生谁负责”原则。

二、集约化管理的风险与防控

“多 Schema 单实例”模式将风险集中，必须配套相应的技术防御措施。

1. 单点故障风险 (Single Point of Failure)

风险：实例宕机导致全院瘫痪。
防控：
- 主备集群：必须部署 Oracle RAC / 达梦 DSC 或主备高可用架构，实现秒级故障切换。
- 容灾兜底：建立 ADG 实时容灾库，生产环境瘫痪时可立即切换。
- 优势：集中维护一套高配高可用环境，比分散维护多套低配环境更可靠。

2. 邻居干扰风险 (Noisy Neighbor)

风险：某非核心 Schema (如报表) 资源耗尽，拖垮核心业务。
防控：
- 资源管理器 (Resource Manager)：将 HIS_CORE 设为 VIP 组 (保底 80% CPU)，限制非核心组 CPU/IO 上限。
- 连接数限制 (Profile)：限制非核心用户的最大连接数 (SESSIONS_PER_USER) 和空闲超时 (IDLE_TIME)，防止连接泄露。
- 内存隔离 (Buffer Keep)：将核心高频表 Pin 在内存 Keep Pool 中，防止被大查询挤出缓存。
- 锁与超时：设置 SQL 执行超时阈值，自动 Kill 掉长时间占锁的异常会话。

决策建议：对于中等规模医院（<800 床），采用 “单实例 + 严格资源隔离” 是利大于弊的最佳实践。

厦门大学附属成功医院的“双实例”实践

上述方案的设计思路，来源于厦门大学附属成功医院的自身实践经验。

2023 年 12 月 8 日，厦门大学附属成功医院将包括 HIS 在内的全部业务系统正式切换到“全栈国产平台”并实现“全场景应用”，率先实现“三甲医院全面信创” 。在数据库方面，医院实现从 Oracle 数据库向达梦数据库的平稳适配和迁移。

王继伟介绍，由于厦门大学附属成功医院的日门诊量峰值在 3000-5000 人次、住院占床患者量峰值在 800-1200 人之间，属于中等业务峰值医院。在信创实践前，医院已将绝大部分业务系统集中在一个被称为泛 HIS 的 Oracle 数据库实例中。在信创实践时，临时将电子病历、手术麻醉等系统与原泛 HIS 数据库分离，从原来一个实例改为两个实例，并分别迁移至两个达梦数据库实例中，即电子病历类数据库和泛 HIS 数据库，相当于选择了业务数据库“双实例”的过渡方案。

经过超过半年的运行观察，医院信息部门发现：业务关联紧密的系统进行跨库交换数据时，较之前的单实例效率要低一些，为此于 2024 年 6 月将电子病历类数据库中的电子病历、手术麻醉等系统再回迁至泛 HIS 的达梦数据库中，原电子病历类数据库只暂时保留医学影像系统（现被称为医学影像数据库）。因此，医院在用的 102 款业务软件，除影像系统留在医学影像数据库外，其他业务系统均设置在泛 HIS 类数据库中。

从 2023 年 12 月至今，医院的业务数据库“双实例”方案从“泛 HIS、电子病历类”演变为“泛 HIS、医学影像类”。“双实例”方案已连续稳定承载医院业务 23 个月，验证了中低峰值医院采用较少数据库实例的可行性。

不仅如此，由于医学影像类数据库主要管理影像数据的索引，其数据库的性能压力并不大，后续将该医学影像系统迁移至泛 HIS 数据库实例中，也是可行的。

同时，较业务类数据库相比，医院的行政办公类数据库基本不存在性能压力，当前均设置在一个泛办公类数据库的实例中。事实证明，医院设置一个泛办公类数据库实例，同样可行。

王继伟认为：以日门诊量、住院占床患者数量等业务峰值为标准，划分医院规模，匹配数量有限的数据库实例方案，是信创环境下平衡峰值性能、管理成本自主能力的可行路径。未来，结合信创云技术，将单/多实例部署于云平台，利用云资源弹性扩展能力，更灵活地应对业务峰值波动，可进一步提升数据库管理的高效性与稳定性。

目录