建设高可靠高稳定的医院信息集成平台，
，，，保障各科室数据、、应用之间的高效交互，，并为医院后续的智慧应用建设提供稳定的底层平台，，，，发挥医院数据枢纽的重要作用。。。

医院未来将依托集成平台开展辅助决策，，从而使医院医疗服务工作达到理想状态：就医流程最优化、、、、医疗质量最佳化
、、工作效率最高化、、
、病历实现电子化、、
、、决策实现科学化、、、办公实现自动化、、、、网络实现区域化、、
、软件实现标准化
。
。。因此要求底层承载平台具备延展性与兼容性，
，能够承载后续的相关应用。
。。。

根据国家卫生健康委统计信息中心印发《医院信息互联互通标准化成熟度测评方案（2020年版）》要求明确提出关于容灾备份能力、、、、容灾恢复时间（四级甲等要求四小时内）
、
、、使用虚拟化或云计算技术等多维度要求。。。因此本次建设方案需要同步建设集成平台的容灾平台，，
，满足对应的容灾恢复时间要求。。

拓客猫软件根据医院业务的整体发展需求，，对医院底层IT架构进行统一规划，
，，构建符合集成平台业务与互联互通成熟度合规性需求的整体架构。
。。。首先，，，，在主机房采用9台拓客猫软件超融合一体机，，承载医院信息集成平台与相关应用，，为医院各个科室应用之间的互联互通提供稳定
、、高效、
、、、敏捷的底层IT平台
；另外，，灾备机房采用5台拓客猫软件超融合一体机为主机房集成平台提供容灾环境，
，确保数据不丢失、、、
、业务不中断。。。。

医院集成平台由杭州联众负责整体建设，，
，，CDR部分采用Oracle Rac数据库，
，
，
，底层采用拓客猫软件超融合架构承载
，，，本次实测采用Oracle自带的AWR数据库报告对实际运行承载效果做对应分析。。

数据库版本：Oracle RAC 19.0.0（19C）；

报告时间：上午9：00-11：00，
，属于业务高峰期，，选取时间比较适合；

数据库配置：24个核心CPU，，，Oracle建议每个Core有1-10个会话
，
，也就是说最好有24-240个会话能保证有比较好的性能
，，这里有2000+；

快照监控时间
：本次为2小时。。。。

①. Buffer Nowait 100%：说明在从内存取数据的时候
，，，等待时间为0；

②. Buffer Hit 100%
：说明从内存取数据的时候，，，buffer的全程能够从内存中读取
；

③. Library Hit 95.9%：说明sql在Shared Pool的命中率，，最佳值是100%；

④. Parse CPU to Parse Elapsd 90.44%；说明在解析sql语句过程中
，，，，cpu占整个的解析时间比例，，，期望值是100%
，，，说明没有产生等待；

⑤. Redo NoWait 100%：说明在产生日志的时候，，，没有产生等待，，，期望值是100%
；

⑥. Latch Hit 99.98%：说明latch的命中率，，期望值是100%
，
，，，latch类似锁，，，，是一种内存锁，，但只会产生等待，，，不会产生阻塞
，，，，和lock还是有区别的，，，latch是在并发的情况下产生的；

⑦. Non-Parse CPU 76.77%:说明非解析cpu的比例，，越高越好，，，，用100减去这个比例，，，可以看出解析sql所花费的cpu，，100-76.77=23.23，，说明花费在解析SQL上的cpu较高。。。

①.DB time per second 0.6
：是每秒的CPU time(即下面的DB CPU)+ wait time（不包括后台进程消耗的时间）；

②.DB CPUs per second 0.5：该示例是0.5个，，而共有24个core，，说明24个CPU，，每秒钟平均才使用0.5个
，，目前CPU整体较为空闲
；

③.DB time Per Second - DB CPU Per Second 为0.1：即是每秒的等待时间
，
，，，目前该数值较低，，，说明CPU等待时间短
，
，，有能力应对医院后续集成平台上线更多业务
；

④.Logons 5.1：表示每秒/每事务登录的次数；

⑤.Har parses(SQL) 12.8:硬解析。。。。硬解析低说明SQL代码重用率高，，每秒最好低于20；

⑥.Rollbacks 0.1：每秒事务的回滚数，，，，回滚率低说明数据库无效操作少，，对性能消耗更小
，，
，该数值最好低于2；

⑦.Transactions 7.2：每秒事务数，，
，，反映数据库任务繁重与否。。。。

通过以上关键测试数据，，可得出以下结论：