齊齊哈爾醫(yī)學(xué)院附屬第一醫(yī)院位于具有“鶴城”之稱的齊齊哈爾市，坐落于嫩江之畔，始建于1954年9月，是一所集醫(yī)療、教學(xué)、科研、預(yù)防、保健于一體的綜合性三級(jí)甲等醫(yī)院。醫(yī)院占地面積13.3萬平方米，建筑面積11.5萬平方米。開放床位1320張，在崗職工1101人，衛(wèi)生專業(yè)技術(shù)人員894人。醫(yī)院現(xiàn)設(shè)臨床科室48個(gè)，醫(yī)技科室24個(gè)。
近年來，隨著齊齊哈爾醫(yī)學(xué)院附屬第一醫(yī)院信息化水平的迅速發(fā)展，醫(yī)院的信息系統(tǒng)越來越多，甚至達(dá)到了上百個(gè)。醫(yī)院基于對(duì)未來醫(yī)院“十四五”信息化的總體考慮，決定引入集成平臺(tái)實(shí)現(xiàn)醫(yī)院信息系統(tǒng)的統(tǒng)一集成和交互，建立和完善以電子病歷為核心的醫(yī)院信息系統(tǒng)。
齊齊哈爾醫(yī)學(xué)院附屬第一醫(yī)院--東院區(qū)（圖片來自醫(yī)院官網(wǎng)）
齊齊哈爾醫(yī)學(xué)院附屬第一醫(yī)院根據(jù)目前自身的信息化建設(shè)現(xiàn)狀以及對(duì)未來的發(fā)展需求，針對(duì)集成平臺(tái)的建設(shè)提出了詳細(xì)的建設(shè)目標(biāo)和要求：
1.穩(wěn)定承載現(xiàn)有業(yè)務(wù)
建設(shè)高可靠高穩(wěn)定的醫(yī)院信息集成平臺(tái)，保障各科室數(shù)據(jù)、應(yīng)用之間的高效交互，并為醫(yī)院后續(xù)的智慧應(yīng)用建設(shè)提供穩(wěn)定的底層平臺(tái)，發(fā)揮醫(yī)院數(shù)據(jù)樞紐的重要作用。
2.靈活滿足未來業(yè)務(wù)要求
醫(yī)院未來將依托集成平臺(tái)開展輔助決策，從而使醫(yī)院醫(yī)療服務(wù)工作達(dá)到理想狀態(tài)：就醫(yī)流程最優(yōu)化、醫(yī)療質(zhì)量最佳化、工作效率最高化、病歷實(shí)現(xiàn)電子化、決策實(shí)現(xiàn)科學(xué)化、辦公實(shí)現(xiàn)自動(dòng)化、網(wǎng)絡(luò)實(shí)現(xiàn)區(qū)域化、軟件實(shí)現(xiàn)標(biāo)準(zhǔn)化。因此要求底層承載平臺(tái)具備延展性與兼容性，能夠承載后續(xù)的相關(guān)應(yīng)用。
3.業(yè)務(wù)容災(zāi)要求
新版互聯(lián)互通測(cè)評(píng)要求明確提出關(guān)于容災(zāi)備份能力、容災(zāi)恢復(fù)時(shí)間（四級(jí)甲等要求四小時(shí)內(nèi)）、使用虛擬化或云計(jì)算技術(shù)等多維度要求。因此本次建設(shè)方案需要同步建設(shè)集成平臺(tái)的容災(zāi)平臺(tái)，滿足對(duì)應(yīng)的容災(zāi)恢復(fù)時(shí)間要求。
深信服超融合，為集成平臺(tái)打造穩(wěn)定運(yùn)行、統(tǒng)一管理的平臺(tái)底座
深信服根據(jù)醫(yī)院業(yè)務(wù)的整體發(fā)展需求，對(duì)醫(yī)院底層IT架構(gòu)進(jìn)行統(tǒng)一規(guī)劃，構(gòu)建符合集成平臺(tái)業(yè)務(wù)與互聯(lián)互通成熟度合規(guī)性需求的整體架構(gòu)。首先，在主機(jī)房采用9臺(tái)深信服超融合一體機(jī)，承載醫(yī)院信息集成平臺(tái)與相關(guān)應(yīng)用，為醫(yī)院各個(gè)科室應(yīng)用之間的互聯(lián)互通提供穩(wěn)定、高效、敏捷的底層IT平臺(tái)；另外，災(zāi)備機(jī)房采用5臺(tái)深信服超融合一體機(jī)為主機(jī)房集成平臺(tái)提供容災(zāi)環(huán)境，確保數(shù)據(jù)不丟失、業(yè)務(wù)不中斷。
齊齊哈爾醫(yī)學(xué)院附屬第一醫(yī)院實(shí)測(cè)技術(shù)參數(shù)的展示與解讀
醫(yī)院集成平臺(tái)由杭州聯(lián)眾負(fù)責(zé)整體建設(shè)，CDR部分采用Oracle Rac數(shù)據(jù)庫，底層采用深信服超融合架構(gòu)承載，本次實(shí)測(cè)采用Oracle自帶的AWR數(shù)據(jù)庫報(bào)告對(duì)實(shí)際運(yùn)行承載效果做對(duì)應(yīng)分析。
（說明：AWR報(bào)告是Oracle 10g下提供的一種性能收集和分析工具，它能提供一個(gè)時(shí)間段內(nèi)整個(gè)系統(tǒng)資源使用情況的報(bào)告，通過這個(gè)報(bào)告可以了解系統(tǒng)的整體運(yùn)行情況，類似于個(gè)人體檢報(bào)告。）
測(cè)試方案：
數(shù)據(jù)庫版本：Oracle RAC 19.0.0（19C）；
報(bào)告時(shí)間：上午9：00-11：00，屬于業(yè)務(wù)高峰期，選取時(shí)間比較適合；
數(shù)據(jù)庫配置：24個(gè)核心CPU，Oracle建議每個(gè)Core有1-10個(gè)會(huì)話，也就是說最好有24-240個(gè)會(huì)話能保證有比較好的性能，這里有2000+；
快照監(jiān)控時(shí)間：本次為2小時(shí)。
1.實(shí)時(shí)性能測(cè)試數(shù)據(jù)
①. Buffer Nowait 100%：說明在從內(nèi)存取數(shù)據(jù)的時(shí)候，等待時(shí)間為0；
②. Buffer Hit 100%：說明從內(nèi)存取數(shù)據(jù)的時(shí)候，buffer的全程能夠從內(nèi)存中讀取；
③. Library Hit 95.9%：說明sql在Shared Pool的命中率，最佳值是100%；
④. Parse CPU to Parse Elapsd 90.44%；說明在解析sql語句過程中，cpu占整個(gè)的解析時(shí)間比例，期望值是100%，說明沒有產(chǎn)生等待；
⑤. Redo NoWait 100%：說明在產(chǎn)生日志的時(shí)候，沒有產(chǎn)生等待，期望值是100%；
⑥. Latch Hit 99.98%：說明latch的命中率，期望值是100%，latch類似鎖，是一種內(nèi)存鎖，但只會(huì)產(chǎn)生等待，不會(huì)產(chǎn)生阻塞，和lock還是有區(qū)別的，latch是在并發(fā)的情況下產(chǎn)生的；
⑦. Non-Parse CPU 76.77%:說明非解析cpu的比例，越高越好，用100減去這個(gè)比例，可以看出解析sql所花費(fèi)的cpu，100-76.77=23.23，說明花費(fèi)在解析SQL上的cpu較高。
數(shù)據(jù)解讀
1. 測(cè)試數(shù)據(jù)顯示，Oracle數(shù)據(jù)庫整體性能較為穩(wěn)定，緩存命中率、latch命中率、內(nèi)存等待等數(shù)據(jù)都大于90%；
2. CPU在解析SQL上花費(fèi)的時(shí)間較多，SQL語句解析相比較而言耗費(fèi)了一定性能。
2.業(yè)務(wù)負(fù)載測(cè)試數(shù)據(jù)
①.DB time per second 0.6：是每秒的CPU time(即下面的DB CPU)+ wait time（不包括后臺(tái)進(jìn)程消耗的時(shí)間）；
②.DB CPUs per second 0.5：該示例是0.5個(gè)，而共有24個(gè)core，說明24個(gè)CPU，每秒鐘平均才使用0.5個(gè)，目前CPU整體較為空閑；
③.DB time Per Second - DB CPU Per Second 為0.1：即是每秒的等待時(shí)間，目前該數(shù)值較低，說明CPU等待時(shí)間短，有能力應(yīng)對(duì)醫(yī)院后續(xù)集成平臺(tái)上線更多業(yè)務(wù)；
④.Logons 5.1：表示每秒/每事務(wù)登錄的次數(shù)；
⑤.Har parses(SQL) 12.8:硬解析。硬解析低說明SQL代碼重用率高，每秒最好低于20；
⑥.Rollbacks 0.1：每秒事務(wù)的回滾數(shù)，回滾率低說明數(shù)據(jù)庫無效操作少，對(duì)性能消耗更小，該數(shù)值最好低于2；
⑦.Transactions 7.2：每秒事務(wù)數(shù)，反映數(shù)據(jù)庫任務(wù)繁重與否。
數(shù)據(jù)解讀
1. 數(shù)據(jù)庫負(fù)載壓力較小，運(yùn)行平穩(wěn)；
2. CPU等待時(shí)間、處理時(shí)間較短，CPU壓力較小；
3. 每秒事務(wù)數(shù)目前還不高，因?yàn)楫?dāng)下醫(yī)院處于開始啟用集成平臺(tái)的階段，后續(xù)壓力更大的情況下，也有較好的冗余保障；
4. 回滾、硬解析時(shí)間短，數(shù)據(jù)整體的無效操作與SQL的代碼重用率較好，數(shù)據(jù)庫整體運(yùn)行平穩(wěn)、架構(gòu)高效。
通過以上關(guān)鍵測(cè)試數(shù)據(jù)，可得出以下結(jié)論：
1. 超融合能夠?yàn)獒t(yī)院集成平臺(tái)提供穩(wěn)定支撐：從上述數(shù)據(jù)庫性能報(bào)告上可以看出，Oracle Rac在超融合上承載穩(wěn)定、性能富余；針對(duì)醫(yī)院后續(xù)集成平臺(tái)串聯(lián)系統(tǒng)增多、數(shù)據(jù)量逐步增加的情況，深信服超融合也能游刃有余地提供穩(wěn)定的底層支撐。
2. 超融合滿足醫(yī)院一體化容災(zāi)建設(shè)需求：醫(yī)院集成平臺(tái)基于深信服超融合平臺(tái)，直接升級(jí)構(gòu)筑容災(zāi)平臺(tái)與CDP數(shù)據(jù)備份，從而實(shí)現(xiàn)主備數(shù)中心的統(tǒng)一管理，確保RTO、RPO ≤30分鐘，滿足互聯(lián)互通四甲對(duì)醫(yī)院數(shù)據(jù)災(zāi)備的相關(guān)要求。
2019年深信服入圍Gartner全球超融合基礎(chǔ)設(shè)施魔力象限，并在2020年和2021年連續(xù)上榜Gartner全球超融合基礎(chǔ)設(shè)施軟件魔力象限，是中國(guó)地區(qū)唯一全棧自研入圍的服務(wù)商。至今，深信服基于高可靠、高性能、靈活彈性的超融合架構(gòu)，在醫(yī)療行業(yè)已幫助超過1000家用戶實(shí)現(xiàn)核心業(yè)務(wù)上云，未來超融合也會(huì)成為承載更多醫(yī)院集成平臺(tái)的穩(wěn)固底座。
