V1.0
Revision |
Author/Modifier | Comments | |
No. |
Date |
||
1.0 | 2012.2 | 陈雍 | 初稿 |
一、 目的
明确临时重跑任务操作的风险及标准流程,最大限度避免临时重跑任务操作带来的故障。
二、 适用范围
l 由于任务失败或项目要求需要重跑任务
l 由于业务需要,修改原有的任务,临时执行。
三、 风险评估
l 登录到错误的schema下,运行了其他schema下名字相同的procedure。
l 重新执行的时间点错误,可能会导致任务的逻辑错误和数据错误。
l 没有和开发确认任务逻辑,导致任务执行错误或数据错误。
四、 操作流程
1. 准备工作
a) 需要开发人员ITIL提单,主管审批。
b) 开发人员需提供任务的执行脚本,开发需要确认脚本是否能够执行以,同时明确执行的风险点。
c) 开发人员提供执行的时间点,确认是否存在和执行时间有关的风险。
d) 执行前,开发和dba需要弄清楚任务的业务逻辑。如要修改业务逻辑,开发人员需要提供给dba经过严格测试后的procedure。DBA只负责执行,不对其中的任何逻辑负责。
e) 执行前检查是否有相同的任务在执行。
SELECT /*+ RULE */ * FROM DBA_JOBS_RUNNING;
(10.2前的版本加上以上的hint)
f) 任务的procedure需要在任何时候可以重复执行。
2. 执行过程
a) 用应用账户登录数据库,SHOW USER检查是否连接到正确的schema。
b) 执行任务脚本,将脚本放在后台跑:
nohup 脚本名.sh & ;
c) 查看过程若无报错,退出当前登录。若有报错,找出报错的地方,修改确认再执行,直至全部执行通过,最后退出当前登录。
3. 验证方案
a) 开发人员验证数据是否和任务的业务逻辑匹配。
b) 根据需求选择是否通知开发刷新缓存。
五、 核心对象风险
1. 定时任务对核心表的操作较少,基本是查询和更新操作。
2. 核心对象由于访问量高和数据量大,要考虑任务对核心表的更新和查询所带来的压力,执行时间尽可能避开高峰时间。
六、 回退方案
1. 执行前需准备好回退的脚本。
2. 回退时需得到开发的确认,并确认回退的时间点。
七、 历史故障及教训
略。