运维操作手册及故障处理流程.docx

运维操作手册及故障处理流程.docx

《运维操作手册及故障处理流程.docx》由会员分享，可在线阅读，更多相关《运维操作手册及故障处理流程.docx（16页珍藏版）》请在冰豆网上搜索。

运维操作手册及故障处理流程

1、运行操作

1.11.1操作前检查事项

11前需对一些先决条件进行检查，检查内容包括检查归档日志目录、对应用当前状态等的检查。

先决条件都满足之后方可启动11的加载。

按照以下步骤检查：

1.1.1检查归档日志目录

使用oracle/oraclemv用户登录DEP数据库188.1.6.101，敲入命令：

df–g，检查文件系统/dev/oraarc01的使用率情况，如图3.2.1.2所示：

图3.2.1.2

如果归档日志使用率高于50%，则需要联系珠海客户方马华兵或王虎，由他们决定是否直接进行清理或由他们联系营运中心进行清理。

（除月末和年底外，正常工作日期dep一个完整的加载过程归档日志增长40%左右）

注意如遇特殊情况，如周一白天加载周六日数据或节假日后一天当中追加好几天的数据时，加载过程中注意监控归档日志的使用率，加载中如出现高于90%的情况，要马上进行处理。

1.1.2检查当前状态

在浏览器中输入使用admin用户进入11管理应用前台：

1）检查触发器状态，应为停止状态

在左边的菜单树中选择工作管理->触发器定义，查询当前触发器的状态，如图3.2.1.3-1所示：

图3.2.1.3-1

查询结果，三个触发器的状态为停止作为启动当日增量的先决条件

2）检查DEP系统工作日期

在左边的菜单树中选择系统配置->系统参数配置，查询当前工作日期，如图3.2.1.3-2所示：

图3.2.1.3-2

当前工作日期应为所加载增量数据的日期为启动增量加载的先决条件；查看当前阶段信息，当前一日数据加载完成，所有数据处理阶段运行完成后为启动当日增量加载的先决条件。

3）检查当前阶段状态

在左边的菜单树中选择监控与调度->当前工作状态，当前阶段状态循环结束、阶段状态完成，为当日启动增量加载的先决条件，如图3.2.1.3-3所示：

图3.2.1.3-3

1.21.2工作日启动所有数据源的加载操作

每个工作日下班前，应启动11增量数据加载，具体操作如下：

在浏览器中输入http:

/，使用admin用户进入数用前台：

在左边的菜单树中选择监控与调度->当前工作状态，点击启动当日增量按钮，在弹出框中点击确定，启动当日增量数据加载如图3.2.2所示：

图3.2.2

启动后，系统会自动将触发器状态置为运行，重复3.2.1.3—1）步骤，检查触发器状态，正常时三个触发器状态均为运行。

1.31.3周末及节假日单独加载CM2006（唯一数据源）操作

CM2006的数据每天都需要加载，而综合业务系统、国际结算系统、报账制系统和债券核算系统的数据只有综合业务系统跑批处理时才需要加载，当不需要加载综合业务系统、国际结算系统、报账制系统、债券系统的数据时，需要使用脚本修改11抽取元数据，对CM2006系统增量数据进行单独加载，当所有CM2006系统数据加载完成后，需要使用脚本恢复元数据，以保证在下个工作日正常加载五个源系统的数据。

具体操作步骤如下：

1.3.1当前状态检查

（1）检查触发器状态（工作管理->触发器定义），应为停止状态；如下图：

（2）检查当前工作状态（监控与调度->当前工作状态），应为循环结束。

如下所示：

（3）检查系统工作日期（系统配置->系统参数配置），确保为正确的加载日期；

1.3.2修改元数据

只启用CM2006所需元数据及禁用增量PDS指标加工工作：

登录DEP数据库（DEPDB1_188.1.6.101）

执行脚本：

UPDATEBI_TABLE_DEFTSETT.STATUS='EXPIRED';

UPDATEBI_TABLE_DEFT

SETT.STATUS='ACTIVE'

WHERET.SCHEMA_NAME='CM2006'

OR（T.DS_TYPE='UDS'ANDT.TABLE_NAMELIKE'CM_%'）

OR（T.DS_TYPE='PDS'ANDT.SOURCELIKE'UDS.CM_%'）;

updateeaf_jobsetstatus='EXPIRED'wherejob_code='INCR_PDS_GUIDE';

COMMIT;

1.3.3确认步骤2的操作执行成功

（1）在当前库执行脚本selectcount（*）frombi_table_defwherestatus='ACTIVE'，查询结果应为1853。

--20130324改造上线增加24张表1877—201308010改造上线后1977

（2）在管理前台界面选择工作管理->工作定义,则可以看到增量PDS指标加工为失效状态。

1.3.4开始加载

登录管理前台，监控与调度->当前工作状态，点击启动当日增量，开始CM2006数据的加载处理。

1.3.5加载完成

监控工作状态至循环结束即为完成一次CM2006数据的单独加载。

（如果需要，至此可进入第二个工作日期的CM2006单独加载过程，操作同步骤1.3.4）

1.3.6恢复元数据

启用所有元数据及启用增量PDS指标加工工作，

登录DEP数据库（DEPDB1_188.1.6.101）

执行脚本：

UPDATEBI_TABLE_DEFTSETT.STATUS='ACTIVE';

updateeaf_jobsetstatus='ACTIVE'wherejob_code='INCR_PDS_GUIDE';

COMMIT;

1.3.7确认步骤6的操作执行成功

（1）在当前库执行脚本selectcount（*）frombi_table_defwherestatus='ACTIVE'；查询结果应为4323；20130324改造上线增加24张表4346；20130810改造上线后44642013116改造上线后4472

（2）在管理前台界面选择工作管理->工作定义,则可以看到增量PDS指标加工为有效状态。

2、监控操作

1.42.1检查前一个工作日的加载是否正确完成

每个工作日上班后，检查DEP昨日增量加载情况，是否完成，检查方法为在浏览器中输入http:

//188.1.5.103:

7001/DEP_APP/，使用admin/adbcmv用户进入11管理应用前台，在左边的菜单树中选择监控与调度->当前工作状态，当前阶段状态循环结束、阶段状态完成，标志前一工作日的增量数据加载完成，如下图3.2.1所示：

图3.2.1

如果前一天的加载工作没有完成，则及时通知DEP维护人员进行紧急处理。

1.52.2如果加载完成，则检查各阶段具体执行情况

以sim/sim用户登录11数据库DEPDB1_188.1.6.101，执行以下查询sql，

selectPHASE_CODEas阶段,caseSTATUSwhen'COMPLETED'then'完成'when'STOPPED'then'停止'when'RUNNING'then'运行'when'FAILED'then'失败'elseSTATUSendas状态

TOTAL_JOBSas总共作数,COMPLETED_JOBSas完成工作数,START_TIMEas启动时间,END_TIMEas结束时间,

（to_number（substr（to_char（END_TIME,'yyyymmddhh24mi'）,7,2））*1440+to_number（substr（to_char（END_TIME,'yyyymmddhh24mi'）,9,2））*60+

to_number（substr（to_char（END_TIME,'yyyymmddhh24mi'）,11,2）））-

（to_number（substr（to_char（START_TIME,'yyyymmddhh24mi'）,7,2））*1440+to_number（substr（to_char（START_TIME,'yyyymmddhh24mi'）,9,2））*60+

to_number（substr（to_char（START_TIME,'yyyymmddhh24mi'）,11,2）））

as"运行时间（分）",（to_number（substr（to_char（END_TIME,'yyyymmddhh24miss'）,7,2））*86400+

to_number（substr（to_char（END_TIME,'yyyymmddhh24miss'）,9,2））*3600+

to_number（substr（to_char（END_TIME,'yyyymmddhh24miss'）,11,2））*60+to_number（substr（to_char（END_TIME,'yyyymmddhh24miss'）,13,2）））-

（to_number（substr（to_char（START_TIME,'yyyymmddhh24miss'）,7,2））*86400+

to_number（substr（to_char（START_TIME,'yyyymmddhh24miss'）,9,2））*3600+

to_number（substr（to_char（START_TIME,'yyyymmddhh24miss'）,11,2））*60+to_number（substr（to_char（START_TIME,'yyyymmddhh24miss'）,13,2）））

as"运行时间（秒）"

fromdep.eaf_phase_instancewhereto_char（business_date,'yyyymmdd'）='20140106'orderbySTART_TIME;

并将加载情况记录在《11值班记录表》

3、故障处理

每个工作日上班后，如果值班人员按照步骤2.1检查DEP没有完成前一天的加载，则马上通知dep组维护人员，由dep组维护人员进行紧急处理。

由于对报表平台的供数在加载的第二阶段，即BDS增量加载完成后的下一个阶段，所以处理时以尽快完成BDS增量加载阶段为基本原则，尽最大可能避免延误供数，甚至可以先保留日志，问题原因可以稍后分析和归档。

以下几种错误的处理均遵循这一原则。

1.63.1处理流程：

1.6.13.1.1首先判断错误类型：

查看dep日志，使用DEP用户登录11应用运行的节点服务器，进入/app/dep/dep_domain/logs下，查看dep.log文件，根据出错日志判断错误类型，若属于常见错误，由dep组维护人员进行紧急处理，但一定要记录操作步骤，修改脚本等所以表更，并在处理结束后整理为错误案例，进行归档记录，并在周报中统一汇报。

1.6.23.1.2如果不属于常见错误

则马上联系开发人员陈嘉交流问题解决方法，并同时向龚晓飞和余总上报。

两方人员尽快拿出解决方案后在生产环境实施，全力保障问题及早得到解决，并将问题处理情况及时反馈给龚晓飞和余总。

1.73.2常见错误：

1、PDS快照表出现重复数据

2、cm2006提供的晚批zip包为空

3、不能使用LOBlocators加载错ORA-22992:

cannotuseLOBloca

torsselectedfromremotetables

4、PDS临时表有重复数据ORA-30926:

unabletogetastablesetofrowsinthesourcetables

5、数据源有空字段，但是dep定义该字段不能为空：

ORA-01400:

cannotinsertNULLinto（"PDS"."DIM_PD_DP_GLDTL_CORP"."ABST_PAGE_CNT"）

6、PDS加载阶段的job失败后重试成功，但是阶段状态未更新，仍是失败。

7、PDS加载违反唯一约束ORA-00001:

uniqueconstraint（PDS.SYS_C0047247）violated

8、数据源中有主键重复数据，操作标志分别为D和I。

9、源数据超长：

valuetoolargeforcolumn"PDS"."DEP_CODE_DIC"."CODE_DESC"

10、CM2006zip包里有个别txt文件里的数据重复卸载，sqlloder错误日志为重复索引

11、CM触发器未触发：

CouldnotconnecttoFTPserveron"172.31.29.7".

12、归档日志满：

ORA-00257:

archivererror.Connectinternalonly,untilfreed.

13、CM加载错，数据源有完全重复数据ORA-00001:

uniqueconstraint（CM2006.PK_LS300019）violated

14.sqlldr加载CM数据出错：

工行字段超长

15、偶尔大表merge操作时报ora-00600的错误，oracle数据库bug导致：

ORA-00600:

internalerrorcode,arguments:

[ktrexc_1],[],[],[],[],[],[],[]

16、索引失效。

ORA-01502:

index'CM2006.PK_LS300001'orpartitionofsuchindexisinunusablestate

17、元数据定义里的数据卸载格式不对，导致无法供给。

18、数据源的精度超过PDS定义精度：

ORA-01438:

valuelargerthanspecifiedprecisionallowedforthiscolumn

19、CM早批数据包命名出错导致报表平台无法取数

4、其他注意事项

1、如果dep的供数不全或不准确，需要重新跑数，这种情况要及时通过马华兵或王虎告知报表平台系统，避免他们加载不正确的数据。

2、需要释放Weblogic内存时才漂移应用，平时不需要漂，尤其是在运行状态的时候；每次漂移之前，要检查是否需要取zip压缩包，确保漂后的服务器上存在zip包后再漂，以免构造CM加载任务为0个

3、数据库归档日志，当前清理机制是：

工作日白天16点之后调度备份进程，20点左右备份完毕后开始清理，白天做dep加载的话，加载之前要检查，加载的过程中也要时刻注意查看归档日志的使用率，达到90%即告知马华兵，由他决定是否直接进行清理或由营运中心进行清理

4、修改job定义状态为有效、失效时，不要在界面直接修改，应在数据库执行SQL脚本改，（因为直接修改时可能会连带着更改其所属阶段的代码，容易出错）

5、定期清理表uds.cb_jnl_imis（IMIS临时表，每日加载时全量更新）

truncatetableuds.cb_jnl_imis;暂定为每周一

6、解决加载错误或升级更新时如涉及到数据库数据的变更，要及时做数据库备份，备份目录188.1.6.102/oraarc02/depdmp

7、改了触发器状态、工作定义、阶段定义等元数据后，前台应通过查看详细来检查，重点检查所属阶段；并在数据库查表进行验证，修改后重启应用，将更改加载到内存。