专项梳理ZLHIS系统升级.docx
《专项梳理ZLHIS系统升级.docx》由会员分享，可在线阅读，更多相关《专项梳理ZLHIS系统升级.docx（16页珍藏版）》请在冰豆网上搜索。
专项梳理ZLHIS系统升级
系统升级的流程
成都中联信息产业有限公司
版本信息
版本
创建时间
版本变化调整描述
完成人
主要参与人
完成时间
1.0
2015.07.03
于陈
于陈
注：
单击此处输入文字。
1进场前
1.1目标版本确认
在接收到医院的升级需求后，根据医院当前待实施的项目等因素来确认升级的目标版本。
对于应用比较深、客户价值比较高的医院，在升级至低版本的SP版本时应该慎重考虑。
因为低版本的SP版本往往还存在较多的BUG。
1.2升级团队成员确认
项目进场前，由部门经理指定本次升级团队的各个成员，以明确各自的职责。
升级负责人：
全面负责整个升级项目，与院方协调沟通升级事宜
升级协助人：
协助升级及测试工作
对应服务经理：
协助升级及测试工作、配合升级负责人与院方沟通
DBA:
全面负责升级期间数据库事宜
程序备勤：
负责升级期间BUG、需求处理
1.3数据库环境确认
由升级负责人向院方确认，正式库的数据库环境。
如服务器操作系统是LINUX还是WINDOWS，是否实施了RAC、DG，日常的备份方式是逻辑备份、数据泵还是RMAN，目前的数据量是多大，主库的硬件环境如何。
1.4模块接口使用情况确认
与院方负责人确认目前医院正在使用的模块是哪些，以便于功能点测试工作的开展。
确认医院接口的使用情况，并登记到《部件接口清单》表中，明确接口名称、接口服务器ip地址，接口部件名称、接口类型、中联接口负责人及联系方式、接口方负责人及联系方式。
只有在准确的知晓医院接口使用情况后，才能在项目进场后迅速的开展接口测试工作，并且下FTP自动升级时，才有处理ZLFILEUPGRADE表的依据。
部件接口清单见图1。
图1部件接口清单
1.5测试服务器准备确认
进场前与院方确认，测试服务器是否已经准备到位，硬件环境是否满足（针对数据量较大而测试库硬件性能较差的情况下，应该及时与院方协调更换测试服务器硬件），如：
磁盘空间，CPU、内存、网络等。
在测试服务器已经准备到位的情况下，可以提前远程恢复数据，搭建测试库，针对数据量大并且实施了RAC的情况，应该将DG切换至MANT状态导出备份集，以免恢复后测试库出现ORA-00600错误。
针对数据量较小的医院，备份和恢复的方式比较灵活，可以视实际情况而定。
1.6测试客户机准备确认
进场前与院方确认，测试客户机是否准备到位，客户机只要求能正常运行ZLHIS程序即可，并且能连接测试库。
要求每个升级团队的测试人员都应该有独立的测试客户机，最好与院方站点实际使用的操作系统相同，这样在测试期间就能提前发现部分与操作系统相关的问题。
1.7注册码申请
邮件申请待升级医院的注册码，以便测试升级后及时更换。
1.8梳理重大修改说明
依据重大产品调整、专项产品说明、升级说明、实际测试等来源，整理重大修改说明，明确来源、修改模块、修改内容、影响部门、重要程度。
以便后续交予院方负责人，也便于后续升级培训工作的开展，根据医院实际使用的模块不同，重大修改说明的侧重点也不相同。
重大修改说明见图2。
图2重大修改说明
1.9梳理BUG、需求列表
从BH上汇总待升级医院的BUG及需求列表，如果进场前有相应升级版本的测试库的话，应该在测试库上验证BUG、需求是否在升级版本上解决，并填写验证人及验证情况。
针对需求类问题，应该仔细查看原始需求的提出背景或者直接与需求提出人沟通，了解需求的详细轻内容。
BUG及需求列表见图3。
图3BUG及需求列表
1.10重大问题通告
梳理产品重大问题通告，梳理来源如下：
此链接，筛选对应版本的存在的重大问题，并注意处理方式和是否解决。
如果存在需要手工调整或执行脚本的问题，务必在测试升级和正式升级后及时处理。
1.11待升级处理问题列表
为了让院方了解本次升级处理的问题，也便于测试期间的测试，应该从BH导出所有问题状态为待升级的问题。
2测试期
2.1项目启动会议
在项目进场后，开展测试工作之前，应该开项目启动会议，并做好会议记录邮件发出。
与会者包括：
升级团队成员，信息科全体成员。
具体情况视医院而定。
会议要点：
通报整个升级的详细计划和安排，明确需要院方配合的工作；通报升级团队成员，明确升级负责人；重大修改说明通报；目前准备工作简单通报；确定升级期间每周汇总问题机制，指定院方负责人。
项目启动会议能让院方了解升级的计划安排，有助与升级期间医院配合我们升级工作的开展；其次明确了升级团队各成员的职责，让信息科的成员与升级团队成员之间很好的配合。
2.2测试服务器搭建
利用近期的备份数据，搭建测试服务器。
注意调整数据库参数（PGA、SGA、LOGBUFFER等）来对数据库进行优化；在恢复完成之后，应该做一次完整的表分析，以确保测试升级的顺利进行，并安装好原始版本的HIS程序，完成基本的流程测试，确保测试库的正常。
对于使用新版电子病历、新版LIS等新产品，并且独立安装时，也应该同步搭建对应系统的测试库，并确保测试库的正常使用。
2.3测试客户机及环境准备
应保障每个测试人员均有独立的测试PC机，对于测试PC级需要满足以下条件：
1）正常运行HIS程序；2）最好是与医院站点使用的多数操作系统版本相同（部分程序问题只存在特定的操作系统版本上）3）身份证读卡器、语音报价器、就诊卡读卡器（含就诊卡）等外设应尽量配备
2.4测试升级
利用搭建好的测试库进行测试升级操作。
测试升级前请尽量确保电源及网络环境的稳定性。
可以考虑采用笔记本来升级或者接机房的ups来供电。
以避免不确定因素导致的升级异常中断。
测试升级期间需要注意：
1）完全模拟正式升级时的操作，先进行预升级，然后正常升级；2）注意记录升级时间，及时处理升级期间的报错；3）升级期间的的报错，应仔细检查后处理并详细记录报错提示、报错SQL、处理方式、处理脚本。
以便于正式升级时迅速的解决问题；4）升级完成后注意执行总公司的特殊sp脚本，编译无效对象、更换注册码等操作；5）测试升级完成后，应该及时整理计算升级耗时，连同升级日志、问题处理记录一并邮件发出，主送升级负责人及部门经理，抄送升级团队成员。
测试升级次数视实际情况而定，一般情况下测试升级2次。
2.5FTP升级
测试升级完成后应及时替换总公司FTP上升级版本所有的特殊部件，并处理zlfileupgrade表，删除部件记录（如ZLLISDEV等），新增部件记录（如：
医保部件、银医卡部件、zlplugin部件等），注意检查检查存放路径、文件类型、是否注册等字段是否正确。
确认zlfileupgrade表正确无误，部件替换完成之后，进入管理工具进行FTP收集（收集所有），将部件收集并上传至升级FTP。
测试客户机应该安装医院当前版本的HIS程序，然后通过自动升级程序还升级。
（这样可以发现FTP升级存在的问题）
如果医院没有备用FTP的情况下，应该在测试期间就搭建好FTP，FTP数量视医院的站点数量，网络划分而定。
详细的FTP搭建方法这里就不一一赘述了。
FTP升级后常见的问题：
1）非ZLHIS用户登陆，自动升级进度条完成后，又回到登陆界面。
处理方式：
利用跟踪工具跟踪，会发现报错：
表或试图不存在，在PL/SQL授予相应即可
2）在登录导航台时，输入完用户名和密码后导航台自动消失
处理方式：
将客服端升级程序（zlHisCrust）复制到APPSOFT目录下即可。
这里只简单的举例，如果需要详细了解，可以参考何懿写的《Zlhis客户端自动升级原理和部分问题分享》一文。
2.6个性化对比
首先利用管理工具自带的过程管理工具或者其他文本对比工具找出个性化修改的过程，然后逐个检查个性化修改内容，并将个性化调整至测试库。
关于管理工具的自定义过程管理工具，需要注意，在进行变动过程收集之前，应该对本地安装脚本进行处理（类似于32版本之前升级的调整），否则会导致收集的时候提示系统版本号不符，即：
以32.40版本为例，在升级脚本目录新建10.32.0文件，并将32.40sp版本的升级脚本复制至文件夹内，复制其他升级脚本文件夹内的配置文件至此目录，修改系统版本号为32.40，并且将应用脚本的版本号修改为32.40。
管理工具过程管理见图4。
图4管理工具自定义过程管理
自定义过程管理工具可以用正式库登陆，选择当前数据库，来对比医院在用版本与标准过程的差异；也可以用测试库登陆，然后选择其他数据库，配置正式库的数据连接来对比。
其原理都是拿医院在用的数据库中的过程与安装脚本中的过程进行对比，找出有差异的过程。
在完成个性化对比后，若测试无误，则将个性化调整的所有过程汇总至一个脚本，待正式升级时使用。
2.7功能点测试
功能点测试即按《检查点报告》，逐步完成测试检查点，《检查点报告》目前还不是很完善，所以部分流程可能没有涉及，所以在测试的时候，应该尽可能的考虑医院操作人员实际使用上的问题，如果院方有条件的话，可以由信息科成员参与功能测试，尽可能发现程序上的问题。
在每次升级的过程中，应该将《检查点报告》并整理归档。
功能点测试完成后，需要将《检查点报告》邮件发出归档。
测试点报告中，涉及票据、执行单等问题，应该用打印机实际打印出来，交财务科、护理部等相关部门确认。
测试发现问题后，仔细验证后，及时记录并确认处理方式，如果需要修改程序，那么按正常的Bug处理流程登记BH，在研发接收后及时申请特殊部件。
《检查点报告》见图5。
图5检查点报告
2.8院方操作人员测试
程序上的部分问题，往往只有实际的操作者才能发现，如易用性问题等，所以很有必要组织院方的操作人员来进行测试。
而涉及重大修改的模块，如34版本血库流程变动，应该组织护士、医生、血库人员来进行测试，及时发现流程上的问题。
在组织操作人员测试前，应该先准备好测试环境，如客户机、网络等。
2.9重大修改培训
涉及重大修改部分，如34版本的门诊收费、血库、医嘱单打印、医嘱界面等，应该整理好培训文档及操作手册，准备培训环境，与院方协商培训时间，进行重大修改的培训。
按实际情况，可以只进行小范围的培训，以提高效率。
培训过程注意对比原始版本的流程进行讲解，并准备好培训签到表，培训完成后，签到表需要整理归档。
2.10接口测试
因接口的差异性，重要性，所以单独将接口测试单独列出。
依据进场前准备的接口列表，逐项的完成接口测试工作。
在大版本升级后，医保等接口往往会涉及变更和调整，所以接口测试工作是测试的重点。
在接口测试过程中的问题，如果对应接口负责人未在现场的情况下，应该整理好问题现象并邮件通报与对应负责人。
接口修改完成后，注意将最终版的接口部件、脚本整理归档。
2.11每周问题汇总
在测试期间发现的问题，及时记录并整理为问题汇总。
每周将测试问题汇总列表交院方负责人核对确认。
每周问题汇总机制是确保医院及时了解项目进度的前提，能加强与院方的沟通，重点难点问题，或者重大的流程问题应该及时讨论解决方案，以免延误项目工期。
3正式升级前准备
3.1最新安装包、特殊部件准备
正式升级前一天，应该从总公司FTP上下载最新的对应版本安装包特殊部件。
下载最新安装包是因为产品出现重大问题后，总公司会临时更换安装包。
下载特殊部件后，应该仔细核对部件处理的问题，是否涉及特殊脚本，以及部件正确的放置路径（务必核对安装路径，并按路径分文件夹整理归档）。
此时，不要再对测试库做恢复等操作，并重新安装最新的安装包，替换所有最新特殊部件，替换最近的接口部件，然后整理检查zlfileuograde表，在测试库配置正式升级用的FTP，然后收集部件（收集所有），并上传至FTP。
3.2升级PC机、网络、电源环境准备
为排除升级时的突发情况给升级带来的风险（断网、停电），也为了保障升级有效和顺利的进行，因此，在正式升级过程中，需要院方配合，准备升级的PC机以及网络电源环境。
共需要2台普通PC机，一台用作升级操作，一台用作测试库的FTP部件收集和上传。
（便于提前用测试库收集部件并上传FTP）
【升级操作电脑】：
普通PC机1台
操作系统：
XP或者WIN7旗舰版32位
硬件配置：
满足HIS系统运行即可，无特殊要求
其他要求：
1）100G以上空余磁盘空间
2）重新安装操作系统，或者卸载多余的软件并且安装杀毒软件彻底杀毒
网络及电源：
要求UPS供电或者能保证升级期间不会断电的电源环境（如：
接机房电源或者使用笔记本）
要求可靠的有线网络环境（如：
直接连通机房交换机）
其他设置：
建议设置远程桌面，以便于升级时远程操作（可选）。
【部件收集电脑】：
普通PC机1台
操作系统：
XP或者WIN7旗舰版32位
硬件配置：
满足HIS系统运行即可，无特殊要求
其他要求：
1）100G以上空余磁盘空间
2）重新安装操作系统，或者卸载多余的软件并且安装杀毒软件彻底杀毒
网络及电源：
无特殊要求、要求有线网络畅通即可。
其他设置：
无
3.3升级问题汇总及脚本整理
最后一次汇总升级测试期间的所有问题，交院方确认。
并且依据此文档整理升级问题处理脚本；检查核对个性化调整脚本；检查核对升级脚本；检查核对总公司的特殊sp脚本。
确认无误后，应将所有脚本归档备用。
3.4升级方案整理签字
整理并填写好《升级方案》，邮件发出，待审核通过后打印一式两份，交医院签字盖章。
升级完成后将文档待会公司归档。
3.5升级确认书整理签字
整理并填写好《升级确认书》，邮件发出，待审核通过后打印一式两份，交医院签字盖章。
升级完成后将文档待会公司归档。
3.6预升级
与医院沟通预升级时间（尽量避开业务高峰期），并与预升级当天发出通知，要求操作员尽量提前将业务工作完成，因为在预升级期间可能会存在顿卡、无法操作等现象。
预升级之前，需要仔细核对预升级脚本（升级脚本中后缀为before的），注意调整部分影响业务操作的部分。
如：
32版本→34版本的预升级，涉及病人信息表增加主页id字段、病案主页表增加病人姓名字段，调整就诊登记记录的过程等，这些都会影响预升级之后的系统使用，应该将这些脚本剪切出来不执行，在正式升级前再执行。
预升级完成后，需要手工编译无效对象，以免影响系统正常使用。
4正式升级
4.1中联及院方人员工作分配
在正式升级当天，应依据医院实际情况划分升级当晚的人员安排，以确保重点科室能顺利完成流程。
整理好的安排应该及时打印分发各方人员知晓。
并且开一个简短的会议，通报人员分配情况，注意通报自动升级失败后手工安装的方法、安装包及特殊部件放置的位置。
（建议将所有的特殊部件整合在一起做一个批处理，方便安装）。
4.2科室钥匙收集及全院通知
正式升级当前，提前收集门诊诊室、库房等夜间不上班的科室房间钥匙，以便于下午下班之后就连接测试库将这一部分站点升级上来。
（站点数量不多的情况下可以不用进行此操作）。
建议医院发出全院通知，告知停机时间，并且在醒目位置张贴公告，告知病员医院因系统升级导致信息系统暂时无法使用。
夜间急诊收费人员应该做好手工划价流程，提前准备连接测试库的电脑供收费员划价使用。
（也可以将系统的收费价目表打印出来）。
医院有应急预案的情况下，应该告知医院做好启动应急预案的准备，以防止不可测原因导致的升级失败带来的不良影响。
4.3数据备份
提前预估数据备份的时间，并提前做好数据备份，导出最新的备份集。
尽量不要在主库上做导出操作，以免业务高峰期影响系统运行速度。
（可以从DG库上面导出备份集）备份完成后，注意校验备份集的有效性。
4.4门诊诊室等相关站点FTP部件升级
在升级当日门诊诊室下班后，通过修改oracle监听，指向测试库，对所有的门诊诊室、库房等站点进行FTP升级。
自动升级完成后切记要将测试库的监听配置删除，以免影响次日正常使用。
4.5正式升级操作
正式升级操作按以下顺序逐步完成，并及时记录执行情况。
（正式升级的时间尽量与医院协商为周四，错开业务高峰）
【第一步】特殊SP检查准备（注：
总公司FTP及本次测试特殊SP）
部件列表：
（注：
注意设置存放路径）
脚本列表：
（注：
归类升级待用）
【第二步】升级部件准备，调整zlfilesupgrade表：
（注：
需要最终检查一次总公司特殊SP）
select*fromzlfilesupgradewwherew.文件名like'ZL9PEISRPT%'forupdate
清除部件例表为：
（注：
一般为LIS接口部件、医保部件、其它接口类部件）
增加下放部件为：
（注：
一般为医保部件、配置文件等）
测试库配置收集完成并上传FTP，并备份zlfilesupgrade表至正式库待用；
注意检查存放路径、文件类型、是否注册；
配置正式库、测试库FTP站点分配触发器；
完成后可通报先操作站点升级；
【第三步】数据库备份准备（注：
全库备份）
执行人：
执行时间：
执行脚本：
run
{
allocatechannelt1typedisk;
allocatechannelt2typedisk;
sql'altersystemarchivelogcurrent';
backupdatabasetag'dbfullbackup'format-'E:
\backup\db_%d_%U_%T';
backupcurrentcontrolfileformat-'E:
\backup\ct_%d_%U_%T';
backupspfileformat-'E:
\backup\sp_%d_%U_%T';
releasechannelt1;
releasechannelt2;
}
--备份路径：
RAC1号节点，\backup下
--完成时间：
【第四步】临时收费划价准备到位（注：
注意分院）
执行人：
------------------------------------
--【第五步】通知全院业务暂停
--执行人：
------------------------------------
--【第六步】锁定用户（注：
注意检查接口用户，上机人员表中不全）
--[ZLHIS下]SQL>
select'alteruser'||用户名||'accountlock;'from上机人员表where用户名<>'ZLHIS'
--拷贝执行；
--执行人：
------------------------------------
--【第七步】中断所有会话：
--[ZLHIS下]SQL>
SELECTusername,'altersystemkillsession'||CHR（39）||SID||','||SERIAL#||CHR（39）||';'FROMGV$session
whereprogramin（'Zl9LISComm.exe','ZLHIS+.exe','zlSvrStudio.exe','ZLNewQuery.exe','zlWizardStart.exe','zlSvrNotice.exe'）
--拷贝执行；
--执行人：
--【补充】重启数据库
--重启执行；
--执行人：
--【补充】重启后数据库环境检查（有可能存在磁盘未设置自动挂载）
--检查执行；
--执行人：
------------------------------------
--【第八步】查看用户进程结束情况：
（检查是否全部断开，10.32需要所有用户连接中断列换plb）
--[ZLHIS下]SQL>
select*fromgv$sessionawherea.status<>'KILLED';
--[ZLHIS下]SQL>
selecta.inst_id,a.username,a.status,count（a.program）fromgv$sessionagroupbya.inst_id,a.username,a.status;
------------------------------------
--【第九步】关闭Standby及多余RAC节点；
--执行人：
--执行时间：
--执行命令：
------------------------------------
--【第十步】[升级32选项]执行注册更新文件：
tools下Zlregist.plb;（执行要求：
全部用户断开，才能更新）
--执行方式：
SQL>@路径\zlregist.plb;
------------------------------------
--【第十一步】管理工具升级0版本（注：
先升级到0版本）
--按测试升级操作内容进行答复；
--选择：
记录错误语句
--选择：
选择重新授权
--可不选择表信息收集；
--执行过程修正记录：
--完成时间：
------------------------------------
--【第十二步】数据整理
--对象检查
--序列修正
--无效对象编译
--执行人：
--执行时间：
------------------------------------
--【第十三步】SP版本升级
--按测试升级操作内容进行答复；
--选择：
记录错误语句
--选择：
选择重新授权
--可不选择表信息收集；
--执行过程修正记录：
--完成时间：
------------------------------------
--【第十四步】特殊SP脚本执行
注意：
先执行总公司的特殊sp脚本（spnew.sql），再执行个性化脚本，再执行问题处理脚本
--执行过程修正记录：
--完成时间：
------------------------------------
--【第十五步】数据整理
--编译无效对象并处理；
--序列修正；
--核实权限；
------------------------------------
--【第十六步】更换注册码及授权码；（注：
接口注册、产品授权码注册）
--执行人：
------------------------------------
--【第十七步】配置正式库FTP（按测试库恢复正式库zlfilesupgrade）
--执行人：
------------------------------------
--【第十八步】还原个性化调整过程
--执行人：
------------------------------------
--【第十九步】解锁用户
--[ZLHIS下]SQL>
select'alteruser'||用户名||'accountunlock;'from上机人员表where用户名<>'ZLHIS'
--拷贝执行；
------------------------------------
--【第二十步】恢复RAC节点、DG节点
--执行人：
------------------------------------
--【第二十一步】数据安全检查
--执行人：
--检查时间：
--检查情况：
--------------------------
升级会员 