V1.0

一、 目的

明确启停触发器、启停job操作的风险及标准流程，最大限度避免操作带来的故障。

二、 适用范围

l 启停触发器

l 启停job

三、 风险评估

l 打开触发器代码编译不通过，导致表无法做DML操作。

l 线上触发器或job代码逻辑错误，导致数据错误。

l Job执行时间或调度错误，引起数据错误。

l 代码中有SQL性能差，引起数据库压力高。

四、 操作流程

1. 准备工作

a) 熟悉要变更的触发器或JOB的代码逻辑，与应用人员沟通触发器或JOB的具体功能，在哪个数据库环境，及变更对业务的影响。

b) 线上检查触发器或JOB的逻辑是否正常。

c) 编制变更方案，需要说明操作的数据库，使用的业务帐号，及变更脚本，CHECK脚本，回滚脚本。

启停触发器变更方案示例：

–running on db(usoint,hzoint)

Select owner,trigger_name,status from dba_triggers where trigger_name in (‘xxx1’);

@conn zzzzzz/xxx

Alter trigger xxx1 enable;

Alter trigger xxx2 disable;

–check

@dbcheck

Select owner,trigger_name,status from dba_triggers where trigger_name in (‘xxx1’);

–undo

Alter trigger xxx1 disable;

Alter trigger xxx2 enable;

启停job变更方案示例：

–running on db(usoint,hzoint)

–查看当前数据库job列表及运行情况

@job

@conn zzzzzz/xxx

–关闭JOB

Exec dbms_job.broke(job_id,true);

–打开JOB

Exec dbms_job.broke(job_id,false);

–删除JOB

Exec dbms_job.remove(job_id);

–创建JOB

variable jobno number;–用于保存submit返回的job编号

Exec sys.dbms_job.submit(

job => jobno,–返回的job编号

what => ‘xxxxxx’,–job运行的脚本

next_date => to_date(‘’,’YYYY-MM-DD HH24:MI:SS’),–下次运行时间

interval => ‘xxxxx’ –运行间隔

);

select :jobno from dual;

–运行JOB

Exec dbms_job.run(job_id);

2. 执行过程

a) 使用ssh工具连接到线上库，在admin环境下，用应用账户登录数据库，SHOW USER检查是否连接到正确的schema。严禁使用sys、system做变更。

b) 执行对象变更脚本。

c) 如果是打开trigger，trigger编译错误，则直接回滚，把trigger关闭，检查错误原因，线下验证后再重新发布。

d) 所有对象发布完毕后，退出业务账户到admin环境。

3. 验证方案

a) 在admin下用@dbcheck脚本验证发布是否引起依赖对象失效，如果有对象失效，检查失效原因，重新编译失效对象，如果有依赖对象编译不能通过，则先回滚当前变更，再查找原因，重新制定变更方案。

b) 如果是启停job，用@job脚本检查job的当前状态。

c) 立即联系开发接口人进行应用测试，如果应用验证有问题，则与应用沟通是否需要回滚，变更是否成功以应用测试结果为准。对于定时执行的对象，应与应用跟踪定时执行的结果，确实变更是否成功。

五、 核心对象风险

无

六、 回退方案

检查失效对象。

七、 历史故障及教训

略。