LIMS系统应急方案

1、文档编号版本号GRINM-RM-011.0有色金属研究总院测试中心实验室信息管理系统应急方案北京XX天地科技有限公司20XX年 11 月第1页共29页文档说明本文档是有色金属研究总院测试中心LIMS项目应急预案。文档控制文档作者：XX创建日期：20XX年11月确认日期：控制编码：GRINM-RM-01当前版本：1.0更改记录:日期作者版本更改参考20XX-11-11XX1.0文件归档：归档编号归档时间发给用户时间GRINM-RM-01第2页共29页目录目 录 31.1. 目的 41.2. 前提条件 42. 紧急情况的发现与应急方案的启动 42.1. 紧急情况的发现 42.2. 应急方案的启动

2、52.2.1. 启动的条件 52.2.2. 应急启动的发布 52.3.各类实验室负责人 53. 应急措施 53.1. 生产服务器发生故障 53.2. 实验室同步故障 63.3. 网络故障 63.4. 数据库故障 64. 操作系统相关维护 84.1. 数据库安装与配置 94.2. 数据库日志检查 214.3. 性能优化与配置 224.4. 数据库备份与恢复 245. 数据库备份与恢复方案 255.1.备份方案 255.2.恢复方案 28第 5 页 共 29 页总体介绍1.1. 目的有色院STARLIMS系统作为实验室信息方面的企业级管理系统，一旦因各种原因意 外中断，对有色院其他的信息系统影响重

3、大。 本文档的目的在说明如何应对系统的意外 中断以及如何在系统恢复后保证数据的完整性。另外讲明了 STARLIMS系统的基本维护 方式方法。本文主要涉及的问题如下：一旦发现不能进行系统的正常操作，最终用户首先应该如何操作？根据业务处理的连续性要求，在有色院实验室信息管理系统中断的情况下，如 何处理业务？在有色院实验室信息管理系统恢复运行以后， 最终用户应该如何操作以保证系 统中数据的准确和完整？数据库应该如何进行日常维护与备份数据采用哪种策略？1.2. 前提条件本文档所述应急方案针对有色院实验室信息管理系统因意外原因不能被最终用户 正常使用的情况，即有色院实验室信息管理系统服务器系统停机 /中

4、断或网络中断的情 况，并且该情况持续超过业务连续性所允许的范围，如超过 1 个工作日， 或者有色院实 验室信息管理系统不能顺利地支持实验室管理业务， 如不能完成实验室审核、 同步等业 务。同时，本方案也可作为计划停机情况下或意外情况持续不超过 1 个工作日时，给与 最终用户作为参考。2. 紧急情况的发现与应急方案的启动2.1. 紧急情况的发现有色院实验室信息管理系统最终用户在发现不能正常申请、 提报实验室时， 首先请 求所属单位现场技术支持人员， 由现场技术支持人员将问题进行分析整理后， 直接将问 题提报有色院实验室信息管理系统维护人员。 有色院实验室信息管理系统维护人员在确 认问题是由系统故

5、障或者是外部环境故障所引发但又不能及时解决的前提下， 应根据技 术支持人员提供的预计问题持续时间，提交启动应急申请。2.2. 应急方案的启动2.2.1. 启动的条件1) 停电造成有色院实验室信息管理系统瘫痪超过 4 个小时；2) 局域网的网络中断使有色院实验室信息管理系统瘫痪超过 4 个小时；3) 有色院实验室信息管理系统应用出现故障，使系统停运超过 4 个小时；4) 有色院测试中心STARLIMS系统应用出现故障，无法正常使用；5) 大量的实验室提报、审批业务，超越了有色院实验室信息管理系统的工作负荷，系统无法正常运行超过 4小时。6) 影响生产企业紧急提报实验室数据 1 小时以上；2.2.

6、2. 应急启动的发布由实验室管理系统项目组根据故障现象确认系统是否需要进行入应急状态，并 报实验室管理办公室，由测试所领导批准。实验室管理办公室下达应急方案启动令，业务支持人员指导整体业务应急方案 的工作部署，各相关部门无条件配合做好应急工作。各级管理组织从上到下协调一 致确保系统恢复后及时和正确地将实验室补充录到系统中。2.3. 各类实验室负责人应急方案启动后，各类实验室由专人管理，负责协调与之相关实验室的各种情 况处理。3. 应急措施本方案针对不同的情况，给出相应的应急措施，分述如下：3.1. 生产服务器发生故障当系统运行的环境出现崩溃时， 如服务器宕机， 首先应有有色院实验室信息管理系统

7、业务支持人员发出应急预警，然后针对不同的紧急事件，具体的应对策略如下：在生产服务器故障无法及时排除的情况下， 可临时利用测试系统做为临时生产服务 器。由实验室项目组将最近的备份数据恢复到测试系统， 实验室项目组检查日志服务器， 从恢复点到系统故障点发生的实验室提报、审核、同步情况。 根据日志在测试系统中恢 复相关实验室的提报。通知各所属单位启用测试做为临时生产系统，应急期间通过测试系统提报实验室。 考虑到测试系统性能问题，在通知注明，如果所属单位有大批量数据提交时，需避开系 统高峰使用期，以保证系统的稳定运行。待生产服务器恢复后，将测试系统数据导出， 并恢复到生产服务器中。同时修改测 试系统接

8、口策略，指向相关系统的测试系统。并及时通知各所属单位实验室提报人员。在准备测试系统过程中， 企业有紧急实验室需提报， 经过与最终用户沟通不能等待 情况下，由各类实验室负责人，通过手工方式在 MYLIMS系统中或EXCELS据文件将数 据进行录入，待系统正常运行后，由系统维护人员将数据同步到实验室系统中。3.2. 实验室同步故障实验室在同步过程中， 如果同步不成功， 首先由有色院实验室信息管理系统项目组 人员导出同步数据，然后将同步数据转交STARLIMS系统运维负责人，由STARLIM系统 运维人员手动导入同步数据。针对不同的目标系统，具体的应急方案如下：3.3. 网络故障当由于有色院测试中心

9、网络故障， 导致无法访问实验室管理系统时， 实验室管理系 统项目组可协调服务器管理人员， 通过服务器本机登录系统， 查询各类实验室的同步情 况，并未同步的实验室导出。当有色院实验室信息管理系统恢复后， 清理系统通过手工方式同步的实验室， 全部 将同步标记标识为已同步。3.4. 数据库故障系统管理人员要关注 Oracle 数据库经常可能发生的故障，未雨绸缪。 Oracle 经常 的故障有数据文件误删除、磁盘损坏、操作系统故障等。对于经常发生的故障，可参考 以下应急预案。1、做好数据备份2、检查数据库文件的状态DBA 要及时查看数据库中数据文件的状态(如被误删除) ，根据实际情况决 定如何进行 处

10、理 ，检 查数 据文 件的 状态的 SQL 如下 ： selectfile_name,status, fromdba_data_files;如果数据文件的STATUS不是AVAILABLE那么就要采取相应的措施，如对该数据文件进行恢复操作，或重建该数据文件所在的表空间。3、数据库坏块的处理当 Oracle 数据库出现坏块时， Oracle 会在警告日志文件( alert_SID.log )中记 录坏块的信息：ORA-01578: ORACLEdata block corrupted (file # 7, block # )ORA-01110: data file : /oracle1/orad

11、ata/V920XXradata/V816/users01.dbf其中，VAFN代表坏块所在数据文件的绝对文件号，vBLOCK代表坏块是数据文件 上的第几个数据块出现这种情况时，应该首先检查是否是硬件及操作系统上的故障导致 Oracle 数据 库出现坏块。在排除了数据库以外的原因后，再对发生坏块的数据库对象进行处理。确定发生坏块的数据库对象SELECT tablespace_name,segment_type,owner,segment_nameFROMdba_extentsWHERE file_id = AND between block_id AND block_id+blocks-1;决

12、定修复方法：如果发生坏块的对象是一个索引，那么可以直接把索引DROP掉后，再根据表里的记录进行重建；如果发生坏块的表的记录可以根据其它表的记录生成的话， 那么可以直接把这个表 DROP掉后重建；如果有数据库的备份，则恢复数据库的方法来进行修复；如果表里的记录没有其它办法恢复， 那么坏块上的记录就丢失了， 只能把表中其它 数据块上的记录取出来，然后对这个表进行重建。用Oracle提供的DBMS_REPA包标记出坏块exec DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(,);使用 Create table as select 命令将表中其它块上的记录保存到另一张表上create

13、 table corrupt_table_bakasselect * from corrupt_table;用DROP TABL命令删除有坏块的表drop table corrupt_table;用 alter table rename 命令恢复原来的表alter table corrupt_table_bakrename to corrupt_table;如果表上存在索引，则要重建表上的索引4. 操作系统相关维护第 8 页 共 29 页4.1. 数据库安装与配置oracle 数据库的安装，首先要安装服务端在这里一般不勾选创建启动数据库，而在后面的DBCA!再创建数据库选择安装路径，建议安装在

14、 C盘根目录下，这样做了 ghost以后，能够很快的恢复 回来。然后选择安装版本，默认选择安装企业版，安装全部组件。第26页共29页检查安装信息，确认无误后点击确定，安装过程略过，进度条100%U安装成功安装完成以后，在程序菜单下有 Oracle的菜单，找到并打开配置 DBCA按照安装提示，下一步S D itbbair C osfi ignrfi.1 i an Aeei st hjlIj.步9E Cft 12 护）.矗ft诸蠢圧艳誓鼻刁店喩他f貝理樂据减世顶昭娄遅库f网慣梳TSE目或存怖建-iqi选择一般用途，下一步给数据库起一个全局数据库名，SID号和全局数据库名保持一致，下一步选择管理数据

15、库的方法，默认即可设置默认的账号和密码默认使用文件系统来作为存储机制虚If憲川k芒惰耳肌用昨矶割，桁用KIT郭肾E詡幕才矗用*自初惴昔耀二呵自功界(#忱f 简险餐醫军緒着岛土牝蛊堆串刑品-：|一才谨0曲要仙Jilt项.&JB鞋 - OEfi J曲U -f A9IW国您Y现萌巨延乙询卩；r.需圧帰把星世吊也轉旦曲忖営电#且M足工祎tAT f肝1嚨.。二吃涉疋5 i!-nHA spilt inn I dunra (HAE)也翊理扣砸煦露琵甲拠轴中糧丘期工件和日匚.工忡建丁 Ifttta-出W紀建店技屜跻朋上韦闻 ：j-W讨 育砸)指定创建数据库的位置，即是存放你数据库文件的物理路径。下一步选择数据

16、库的恢复选项，也是默认就可以，不指定快速恢复区选择是否需要安装实例方案，不需要，所以不用勾选，下一步是初始化参数。在这注意 一点，内存选择自定义，共享内存管理也是自动，这样它就能根据物理上的内存容量， 自行分配，不需手动修改，后面三个页签就不用修改参数，全部都是默认即可。检查数据文件存放路径，没问题后下一步确认之前配置的各种参数，确认无误后点击确定下面oracle开始创建数据库，进度条100%后安装完毕。安装完毕后，在程序下 Oracle的菜单下，可见到NETCA勺选项，点击进入里面四个选项，上面三个是需要配置的，首先从监听程序配置开始，为Oracle配置一个监听。添加一个监听，然后为监听起一

17、个名字。下一步通过 TCP协议来配置监听，选择此协议到右边的窗口谒此拓听舞庠ETF沢IBM 配畫炖莘暉的沪占&焊甘且可鑼葡瑁茁配可用协谀tcp a:IPCNMPTCP上一步程下一歩配置TCP协议的端口号，默认即可，标准的 1521。配置完成一个监听即可，不需要在 配置另外的监听，监听程序配置完成之后，继续配置命名方法OrmIb Bttkisiatut: iStiJPWJHxj堆1絳血于鮮析曲标谀苻的名方锻好 直礙童蚌KN抽顺薛.已经列惊段遶了慣草的 命名方法.可醴侖名方法NIS外郃命乞二DCE CCS書地命名迭忘旷曲呂吁注聪帝粘肋 I 至Or*clt *1 匸dth(tzffciii tl a

18、ntsanOracle竝阵輩耳地瞿务，语底用N&lJR2OracleNetConrjur和卯Ass i slant尤许使用由本堆命笛解析的祠唏弓負SiRiMM 的工惟：*雨加厂菟新配査广期除广重命宕广刮试眼厲上-步迟下一步凹为Oracle数据库配置一个服务名，这个就是你在建立数据库（DBCA时设置的那个全局数据库的名字，一般使这两者一样。选择与数据库通信使用的协议，通过 TCP协议。填写数据库的主机名，可以写入 IP ,也可以写入主机名，建议是写入ip，端口用默认的1521即可OrBet Cuiif i curati on 匚x|貶需删ft述TCfwai口豊.犬实劉a况下左便用尉M口粵.节一步

19、I咚整便用TC刪P谢以与數JE理連範瘵锲用斟露暉计章机的工机名诸卷入謝居库確庄俨亘机屁王机名-192 160100上一歩罂可以测试一下刚刚配置的数据库，是否已经连通，按照提示进行测试操作。如果之前给system这些用户设置过统一密码（DBCA里），记得用那个口令进行测试，否则会显示连接不成功，更改口令之后再试试。为此Net服务输入名称，建议也是和之前的一样，与全局数据库名起一样0亡1屯 C aikf 1 gTirati oillt 錚名配舌$ ” JE曙生i aitt mib务名辅入名熟Oracle NetContiguraiicn Assistant 默认 环用晅堀辐入的E务若最后就是配置完

20、成上_博（曲卞一步於）下面是很重要的一步，就是为了保证数据库是在正常状态，并且站点能够顺利的访问到 数据库，需要在每台工作站做了如上配置之后，打开cmd窗口，键入“tnspingorci ”，后面就是你的全局数据库名称，如果出现下图表示连接正常，否则会有报错信息，可以看到具体是哪部分有问题。42数据库日志检查Oracle在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况：数据库的启动、关闭，启动时的非缺省参数；数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpo int)操作没有执行完成造成不能切换，会记录不能切换的原因；对数据库进

21、行的某些操作，如创建或删除表空间、增加数据文件；数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(0R2 600)DBA应该定期检查日志文件，根据日志中发现的冋题及时进行处理问题处理启动参数不对检查初始化参数文件因为检查点操作或归档操作没如果经常发生这样的情况，可以考虑增有完成造成重做日志不能切换加重做日志文件组；想办法提高检查点或归档操作的效率；有人未经授权删除了表空间检查数据库的安全冋题，是否密码太简 单；如有必要，撤消某些用户的系统权 限出现坏块检查是否是硬件冋题（如磁盘本生有坏 块），如果不是，检查是那个数据库对 象出现了坏块，对这个对象进行重建表空间不够增加数据文件到相应的表

22、空间出现 ORA-600根据日志文件的内容查看相应的 TRC文件，如果是Oracle的bug，要及时打上相应的补丁Oracle日志的查看方法：SQLselect * from v$sql倂查看最近所作的操作）SQLselect * fromv $sqlarea （#查看最近所作的操作）Oracle 数据库的所有更改都记录在日志中，从目前来看，分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner来进行，因为原始的日志信 息 我们根本无法看懂，Oracle8i后续版本中自带了 LogMiner,而LogMiner就是让 我们看懂日志信息的工具，通过这个工具可以：查明数据库的

23、逻辑更改，侦察并更正用户的误操作，执行事后审计，执行变化分析。43性能优化与配置DBA在平时的维护中，主要是监控数据表空间的使用和数据库的连接情况，对一些“挂死”的情况进行手工清理数据库表空间使用情况监控（字典管理表空间）数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片，DBA应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎 片进行整理或为表空间增加数据文件。selecttablespace_name,coun t(*) chu nks ,max(bytes/1024/1024) max_chunkfromdba_free_spacegroup b

24、y tablespace_name;上面的SQL列出了数据库中每个表空间的空闲块情况,如下所示:TABLESPACE_NAME CHUNKS MAX_CHUNKINDX1 57.9921875RBS3 490.992188RMAN_TS1 16.515625SYSTEM1 20XX296875TEMP20XX0.8046875TOOLS1 11.8359375USERS67 71.3671875其中，CHUNKS表示表空间中有多少可用的空闲块（每个空闲块是由一些连续的Oracle 数据块组成 ），如果这样的空闲块过多， 比如平均到每个数据文件上超过了 100个，那么该表空间的碎片状况就比较严重

25、了，可以尝试用以下的SQL命令进行表空间相邻碎片的接合:alter tablespace表空间名 coalesce;然后再执行查看表空间碎片的 SQL语句，看表空间的碎片有没有减少。如果没有效 果，并且表空间的碎片已经严重影响到了数据库的运行，则考虑对该表空间进行重建。MAX_CHUNK的结果是表空间上最大的可用块大小， 如果该表空间上的对象所需分 配的空间（NEXT值）大于可用块的大小的话，就会提示 ORA-1652 ORA-1653 ORA-1654 的错误信息，DBA应该及时对表空间的空间进行扩充，以避免这些错误发生。对表空间的扩充对表空间的数据文件大小进行扩展， 或向表空间增加数据文件

26、， 具 体操作见“存储管理”部份查看数据库的连接情况DBA要定时对数据库的连接情况进行检查，看与数据库建立的会话数目是不是正常，如果建立了过多的连接，会消耗数据库的资源。同时，对一些“挂死”的连接，可能会 需要DBA手工进行清理。以下的SQL语句列出当前数据库建立的会话情况：select sid,serial#,username,program,machine,statusfromv$session;输出结果为：SID SERIAL# USERNAME PROGRAM MACHINE STATUS11ORACLE.EXEWORK3ACTIVE21ORACLE.EXEWORK3ACTIVE31O

27、RACLE.EXEWORK3ACTIVE41ORACLE.EXEWORK3ACTIVE53ORACLE.EXEWORK3ACTIVE61ORACLE.EXEWORK3ACTIVE71ORACLE.EXEWORK3ACTIVE8 27 SYSSQLPLUS.EXE WORKGROUPWORK3 ACTIVE115 DBSNMP dbsnmp.exe WORKGROUPWORK3 INACTIVE其中，SID会话(session)的 ID 号；SERIAL#会话的序列号，和SID 一起用来唯一标识一个会话；USERNAME建立该会话的用户名；PROGRAM这个会话是用什么工具连接到数据库的；STA

28、TUS当前这个会话的状态，ACTIVE表示会话正在执行某些任务，INACTIVE表示当前会话没有执行任何操作；如果DBA要手工断开某个会话，则执行：alter system kill session SID,SERIAL#;注意，上例中SID为1到7(USERNAM列为空)的会话，是Oracle的后台进程，不要 对这些会话进行任何操作。4.4. 数据库备份与恢复在数据库结构发生变化时，如增加了表空间，增加了数据文件或重做日志文件这些操作，都会造成Oracle数据库控制文件的变化，DBA应及进行控制文件的备份，备 份方法是：执行SQL语句：alter database backupcontrol

29、file to /home/backup/control.bak;或：alter database backupcontrolfile to trace;这样，会在USER_DUMP_DE初始化参数文件中指定）目录下生成创建控制文件的SQL 命令。5. 数据库备份与恢复方案5.1. 备份方案数据库备份可采取逻辑备份与 ORACLE RMAN份双重备份策略。逻辑备份，即采用EXPD方式将数据库中相关用户下的对象逻辑导出到转储文件中， 需要时使用IMPDP方式导入到数据库中进行恢复；一般逻辑备份会结合操作系统计划任 务服务进行自动备份 .RMAI备份，即采用ORACLE1供的恢复管理器进行在线备份

30、。鉴于系统的数据量较 大， 可以采用周期为 7 天的经典增量差异备份策略：增量备份是指备份更低级别或相同级别最近一次备份以来变化的数据块， 增量备份 的基础是增量 0 级备份。第 29 页 共 29 页1IV1i1si1iii1iIiC11i1-ii*id11a1l1119亠11I1111111iqi11* i411i1tn1atF102212220周日周周二.周三周四JS 五_周六周E从上图我们可以看到，在周日的时候我们进行了一次0级备份，会备份数据文件中所有的已用块。周一的时候进行了一次2级增量备份，这次备份将备份周日到周一变化的数据块。周二的时候我们进行了一次2级增量备份，因为周一的时候

31、也进行了一次2级增量备份，周一跟周二的备份属于相同级别，所以周二的2级增量备份将备份周一以 来变化的数据块。周三的时候进行了一次1级增量备份，因为之前我们没有做过1级的增量备份，所以周三的1级增量备份将备份更低级别，也就是0级备份以来变化的数据块。周四的时候进行了一次2级增量备份，它将备份前面周三1级备份以来变化的数据块。周五的2级增量备份将备份周四2级增量备份以来变化的数据块。周六的2级增量备份将备份周五2级增量备份以来变化的数据块。周日的0级备份将备份上周日0级备份以来变化的数据块。-执行0级备份RMAN backup in creme ntal level 0 format=e:back

32、up%d_%s.dbf tablespace users;启动 backup 于 03-5 月-07分配的通道：ORA_DISK_1通道 ORA_DISK_1: sid=32 devtype=DISK通道ORA_DISK_1:启动增量级别0数据文件备份集通道ORA_DISK_1:正在指定备份集中的数据文件输入数据文件fno=00004name=D:0RACLEPR0DUCT10.2.00RADATA0RA10GUSERS01.DBF输入数据文件fno=00005 name=D:0RACLEPR0DUCT10.2.00RADATA0RA10GUSER02.DBF 通道ORA_DISK_1:正在启

33、动段1 于03-5月-07 通道ORA_DISK_1:已完成段1 于03-5月-07段句柄=E:BACKUPORA10G_45.DBF标记=TAG20XX0503T161414注释=NONE第26页共29页通道 ORA_DISK_1: 备份集已完成 , 经过时间 :00:00:04完成 backup 于 03-5 月 -07-执行2级增量备份，此时将备份上面0级备份以来变化的数据块RMAN backup incremental level 2 format=e:backup%d_%s.dbf tablespace users; 启动 backup 于 03-5 月 -07使用通道 ORA_DI

34、SK_1通道 ORA_DISK_1: 启动增量级别 2 数据文件备份集 通道 ORA_DISK_1: 正在指定备份集中的数据文件 输入数据文件 fno=00004name=D:ORACLEPRODUCT10.2.0ORADATAORA10GUSERS01.DBF 输入数据文件 fno=00005name=D:ORACLEPRODUCT10.2.0ORADATAORA10GUSER02.DBF 通道 ORA_DISK_1: 正在启动段 1 于 03-5 月 -07通道 ORA_DISK_1: 已完成段 1 于 03-5 月 -07段句柄=E:BACKUPORA10G_46.DBF标记=TAG20

35、XX0503T161533注释=NONE 通道 ORA_DISK_1: 备份集已完成 , 经过时间 :00:00:03完成 backup 于 03-5 月 -07-执行1级增量备份，此时将备份上面0级备份以来变化的数据块RMAN backup incremental level 1 format=e:backup%d_%s.dbf tablespace users; 启动 backup 于 03-5 月 -07使用通道 ORA_DISK_1通道 ORA_DISK_1: 启动增量级别 1 数据文件备份集 通道 ORA_DISK_1: 正在指定备份集中的数据文件 输入数据文件 fno=00004n

36、ame=D:ORACLEPRODUCT10.2.0ORADATAORA10GUSERS01.DBF 输入数据文件 fno=00005name=D:ORACLEPRODUCT10.2.0ORADATAORA10GUSER02.DBF 通道 ORA_DISK_1: 正在启动段 1 于 03-5 月 -07通道 ORA_DISK_1: 已完成段 1 于 03-5 月 -07段句柄=E:BACKUPORA10G_47.DBF标记=TAG20XX0503T161602注释=NONE第 31 页 共 29 页通道 ORA_DISK_1: 备份集已完成 , 经过时间 :00:00:03完成 backup 于 03-5 月 -075.2. 恢复方案当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计 算机系统的故障（硬件故障、软件故障、网络故障、进程故障和系统故障）影响数 据库系统的操作，影响数据库中数据