使用RMAN方式實現(xiàn)醫(yī)院信息系統(tǒng)數(shù)據(jù)庫升級實踐

伊永菊 梅 甜 李 銀

中山大學附屬第六醫(yī)院 廣東廣州 510655

電子病歷系統(tǒng)應用水平分級評價是衡量醫(yī)院信息化建設水平的一個重要方法，也是三級公立醫(yī)院績效考核的指標[1]。根據(jù)國衛(wèi)辦醫(yī)函〔2018〕1079號《電子病歷系統(tǒng)應用水平分級評價管理辦法(試行)》，5級整體要求是全院各系統(tǒng)數(shù)據(jù)能夠按統(tǒng)一的醫(yī)療數(shù)據(jù)管理機制進行信息集成。醫(yī)院信息系統(tǒng)(簡稱HIS)是醫(yī)院的核心業(yè)務系統(tǒng)[2]，隨著信息系統(tǒng)不斷增多和數(shù)據(jù)的倍數(shù)增長[3]，醫(yī)院現(xiàn)在運行的HIS不滿足信息集成要求。同時醫(yī)院HIS在2012年上線，已經運行9年，硬件和軟件都難以支撐日益增長的業(yè)務量和數(shù)據(jù)流。因此，HIS升級勢在必行?；谝陨锨闆r，醫(yī)院規(guī)劃了HIS升級為相同軟件供應商的一體化臨床信息系統(tǒng)，同時歷史數(shù)據(jù)需要遷移到一體化臨床信息系統(tǒng)。

醫(yī)院HIS已經積累了5T的數(shù)據(jù)，實現(xiàn)數(shù)據(jù)遷移和業(yè)務系統(tǒng)平穩(wěn)過度是一項比較艱巨的任務,也是核心環(huán)節(jié)[4]。HIS是醫(yī)院的核心業(yè)務系統(tǒng)，與醫(yī)院LIS、PACS、手術麻醉系統(tǒng)和移動護理等信息系統(tǒng)實時對接，在數(shù)據(jù)遷移過程中不可避免要中斷HIS系統(tǒng)[5]，同時影響與之對接的業(yè)務系統(tǒng)。醫(yī)院業(yè)務要求7×24 h運行，這就要求把業(yè)務系統(tǒng)中斷時間縮至最短[6]，并且在信息系統(tǒng)中斷過程中要啟動信息系統(tǒng)突發(fā)事件應急預案[7]，保障業(yè)務數(shù)據(jù)的連續(xù)性。

1 升級目標

本次升級包括HIS服務器配置升級、操作系統(tǒng)升級和數(shù)據(jù)庫升級，詳見表1。本次升級的難點是HIS已經積累了5T的數(shù)據(jù)量，數(shù)據(jù)需要完整地由Oracle Database 11g遷移到為Oracle Database 19c數(shù)據(jù)庫。

表1 HIS數(shù)據(jù)庫升級目標

2 選擇數(shù)據(jù)遷移方案

2.1 Exp/imp 或expdp/impdp

Oracle 10g以下版本數(shù)據(jù)庫采取Exp/imp方法[8]，速度慢。Oracle 10g以上版本可支持Expdp/impdp，速度較快。兩種方式均支持跨平臺進行數(shù)據(jù)遷移，停機時間是導出時間、數(shù)據(jù)傳輸時間和導入時間的總和。

2.2 RMAN

RMAN是用于備份、還原和恢復的 Oracle工具，能備份整個數(shù)據(jù)庫或數(shù)據(jù)庫部件。RMAN 可以實現(xiàn)數(shù)據(jù)文件、控制文件以及歸檔日志文件、數(shù)據(jù)庫服務器參數(shù)文件的備份還原，也可以執(zhí)行完全或不完全的數(shù)據(jù)庫恢復。RMAN的最大特點是支持增量備份[9]，提高了備份和還原的效率。

2.3 Data Guard

Data Guard 是Oracle的一種容災解決方案[10]，也可以實現(xiàn)數(shù)據(jù)遷移。Data Guard停機時間短，但所需硬件成本較高。

2.4 OGG

OGG 對源數(shù)據(jù)庫歸檔日志進行數(shù)據(jù)復制，實現(xiàn)源端與目標端數(shù)據(jù)拷貝。OGG是 Oracle 官方首選的數(shù)據(jù)遷移方案，能夠跨平臺、跨版本，以較低資源實現(xiàn)數(shù)據(jù)的實時復制。

以上4種方案均可以實現(xiàn)數(shù)據(jù)由Oracle Database 11g 遷移到Oracle Database 19c?？紤]到醫(yī)院要求把業(yè)務系統(tǒng)中斷時間縮至最短[11]，而RMAN支持增量備份，因此，醫(yī)院選擇使用RMAN備份和還原實現(xiàn)數(shù)據(jù)遷移。

3 升級實踐

醫(yī)院建立2個小組進行服務器及數(shù)據(jù)庫升級。數(shù)據(jù)遷移小組，成員為院方DBA和一體化臨床信息系統(tǒng)供應商DBA。業(yè)務保障小組，成員為院方HIS、EMR、LIS、PACS、手術麻醉系統(tǒng)和移動護理等信息系統(tǒng)的院方工程師，以及相應的信息系統(tǒng)供應商的工程師，還有一體化臨床信息系統(tǒng)工程師。根據(jù)《醫(yī)院信息系統(tǒng)突發(fā)事件應急預案管理制度》要求，門診、醫(yī)技及藥房信息系統(tǒng)故障30 min以上，住院信息系統(tǒng)故障1 h以上需要啟動應急預案[12]。升級的整體方案如圖1所示。

3.1 前期準備

搭建新的HIS服務器，存儲采用SSD+SAS混合模式，安裝升級版本的操作系統(tǒng)和數(shù)據(jù)庫，設置字符集為SIMPLIFIED CHINESE_CHINA.ZHS16GBK[13]，并按照以下命令優(yōu)化數(shù)據(jù)庫參數(shù)。

alter system set log_archive_format='歸檔日志文件的命名方法' scope=spfile;

alter system set session_max_open_files=20 scope=spfile;

alter system set open_cursors=1500 scope=spfile;

alter system set session_cached_cursors=1000 scope=spfile;

醫(yī)院需要遷移的數(shù)據(jù)量為5T，在新的服務器節(jié)點1上掛載7T存儲作為遷移數(shù)據(jù)的中轉存儲。

在原服務器節(jié)點1設置RMAN全備份任務，全備份任務時間設置為周五晚上18:00點開始，避開業(yè)務高峰期。

backup current controlfile format '備份控制文件';

同時業(yè)務保障組檢查HIS客戶端和接口連接串，保障數(shù)據(jù)庫升級后可兼容。針對本次升級，我們制定了了升級失敗的回退方案：如果升級失敗，則關閉新服務器數(shù)據(jù)庫，重新打開原服務器和數(shù)據(jù)庫。

3.2 升級測試

關閉新服務器節(jié)點2，在新服務器節(jié)點1數(shù)據(jù)庫上恢復控制文件，并注冊備份集，然后RMAN最新備份集進行測試，使用以下RMAN命令實現(xiàn)。

RMAN> startup force nomount;

RMAN> restore controlfile from '控制文件';

RMAN>alter database mount;

同時業(yè)務保障組測試客戶端連接新服務器，測試業(yè)務流程和接口，測試Job自動服務和Dblink。及時記錄問題及各個操作的時間節(jié)點，不斷地總結，對每個問題進行PDCA 處理，對可能出現(xiàn)的狀況制定詳細的解決方案，直至測試通過。測試過程中發(fā)現(xiàn)Oracle Database 19c不支持wm_concat函數(shù)，建立了同名稱的自定義函數(shù)解決這個問題。

圖1 HIS數(shù)據(jù)庫升級方案

3.3 正式升級

為了降低服務器和數(shù)據(jù)庫升級對業(yè)務的影響，正式升級時間選擇業(yè)務量較少的周末和夜間。正式升級分為兩個階段：第一階段是遷移數(shù)據(jù)，時間為切換生產庫的前一周星期五晚上18:00至星期日晚上18:00，以及生產庫切換的前一天，期間生產庫正常運行；第二階段是切換生產庫，切換生產庫到新服務器數(shù)據(jù)庫，時間為星期六0:00到4:00，期間須停止生產庫。

遷移數(shù)據(jù)階段，遷移數(shù)據(jù)的任務是在新服務器數(shù)據(jù)庫上恢復RMAN備份集和追歸檔，使用Restore database 實現(xiàn)。同時，該階段為了避免原數(shù)據(jù)庫全備業(yè)務沖突，需要暫停異地備份的全備策略。信息系統(tǒng)保障小組要通知LIS、PACS、手術麻醉系統(tǒng)和移動護理等信息系統(tǒng)的供應商，在生產庫切換當天需要有技術人員駐場支持。

切換生產庫的時間為星期六凌晨開始，在此之前須做一次RMA增量備份。切換生產庫預計時間為4 h，系統(tǒng)保障小組關閉HIS應用服務器和其他接口服務器，并根據(jù)《醫(yī)院信息系統(tǒng)突發(fā)事件應急預案管理制度》通知各部門啟動應急預案。

切換生產庫時，原生產庫有3個節(jié)點，切換時只保留節(jié)點1的數(shù)據(jù)庫實例僅關閉監(jiān)聽，關閉節(jié)點2和3的數(shù)據(jù)庫實例。注意原生產庫Sequence比最大號要加1，啟動備份最新Redo，備份完成后關閉原生產庫，并使用Recover database恢復歸檔至新生產庫，使用以下命令實現(xiàn)。

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination +ARCH

Oldest online log sequence 原生產庫sequence最大號

Next log sequence to archive 原生產庫sequence最大號+1

Current log sequence 原生產庫sequence最大號+1

數(shù)據(jù)遷移小組提供測試的客戶端數(shù)據(jù)庫監(jiān)聽配置，信息系統(tǒng)保障小組啟動HIS應用服務器，并由專人到各個業(yè)務點替換測試的數(shù)據(jù)庫監(jiān)聽配置進行業(yè)務測試。必須測試的業(yè)務點有門診掛號、門診醫(yī)生站、門診收費、門診發(fā)藥、住院醫(yī)生站、住院護士站、技診終端確認、新媒體掛號和繳費以及其他信息系統(tǒng)的接口功能。

測試通過后，為了保證客戶端能連接到新生產庫，數(shù)據(jù)遷移小組將新服務器集群IP、公網(wǎng)IP、VIP修改至與原服務器相同的網(wǎng)段，并且SCAN IP不變。信息系統(tǒng)保障小組下達指令解除應急預案，將應急數(shù)據(jù)庫的數(shù)據(jù)上傳至新生產庫，實現(xiàn)業(yè)務連續(xù)，并啟動異地容災備份[14]，保障信息安全。

4 性能測試

醫(yī)院于2021-02-26成功完成了HIS數(shù)據(jù)庫升級，升級的執(zhí)行結果與測試相同，并且在預估時間內完成。服務器硬件由4*英特爾至強E7-4809V3 2.0 GHz，8C/16T/4*32G升級為*英特爾至強金牌 6248 2.5GHz，20C/40T/16*32G，HIS服務器操作系統(tǒng)由Red Hat Enterprise Linux 7.8升級為Red Hat Enterprise Linux 7.9，HIS數(shù)據(jù)庫由Oracle Database 11g升級為Oracle Database 19C，統(tǒng)一了醫(yī)院 Oracle 數(shù)據(jù)庫字符集，并使用RMAN方式實現(xiàn)了5T的歷史電子病歷數(shù)據(jù)無損遷移。

全表掃描的速度影響到信息系統(tǒng)整體運行的速度[15]。升級后，我們對HIS數(shù)據(jù)庫中超過1 000萬條記錄的表在升級前后進行全表掃描速度對比。在升級前后分別執(zhí)行 select count(*) from 表名稱，對比結果見表1，由執(zhí)行結果可見，升級后數(shù)據(jù)庫性能提高。

表2 升級后數(shù)據(jù)庫性能對比

5 討論

數(shù)據(jù)庫是醫(yī)院信息系統(tǒng)的核心[16],是信息系統(tǒng)穩(wěn)定和運行速度的保障。服務器和數(shù)據(jù)庫升級必須以保障醫(yī)院業(yè)務數(shù)據(jù)連續(xù)為前提。本次升級方案成功執(zhí)行得益于以下3個方面。

5.1 制定正確的數(shù)據(jù)遷移方案

對于5T級別的歷史電子病歷數(shù)據(jù)遷移，選擇合適的數(shù)據(jù)遷移方式至關重要。RMAN支持增量備份，因此醫(yī)院選擇使用RMAN備份和還原實現(xiàn)數(shù)據(jù)遷移。本次升級實踐表明, RMAN備份和還原可實現(xiàn)大數(shù)據(jù)量遷移，Oracle數(shù)據(jù)庫升級可以選擇RMAN方式。

5.2 數(shù)據(jù)庫正式升級前期要編制細致完備的操作文檔并做充分的測試

HIS是醫(yī)院的核心業(yè)務系統(tǒng)，幾乎與醫(yī)院其他所有的信息系統(tǒng)做了接口。為了盡可能縮短業(yè)務系統(tǒng)中斷時間，本次升級實踐我們精準計算了數(shù)據(jù)遷移時間和切換生產庫的時間，編制了數(shù)據(jù)庫升級的操作文檔，包含每一個操作的時間點、操作指令和操作執(zhí)行人。在正式升級之前應該按照操作文檔做充分的測試和演練。

5.3 數(shù)據(jù)庫升級的同時要啟動信息系統(tǒng)突發(fā)事件應急預案

醫(yī)院業(yè)務要求7×24 h運行，HIS數(shù)據(jù)庫升級須啟動應急收費庫，保障業(yè)務連續(xù)。升級完成后應立即啟動異地容災備份，保障信息安全。