V1.0

一、 目的

明确发布存储过程、触发器、视图操作的风险及标准流程，最大限度避免发布存储过程、触发器、视图操作带来的故障。

二、 适用范围

l 创建存储过程、触发器、视图

l 删除存储过程、触发器、视图

l 修改存储过程、触发器、视图

三、 风险评估

l 登录到错误的schema下，导致代码建到错误的schema里，而应用无法访问。

l 漏发代码，导致应用无法访问。

l 提取了错误代码，导致业务逻辑错误。

l 代码编译不通过，导致脚本无法调用。

l 代码逻辑错误，导致数据不正确。

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

l 没有备份旧的代码，导致无法及时回滚。

l 变更的对象有大量并发访问，变更时出现大量library cache pin/lock，导致数据库无法提供服务。

四、 操作流程

1. 准备工作

a) 熟悉要变更对象的代码逻辑，与应用人员沟通新发布脚本的具体功能，发布到哪个数据库环境，及变更对业务的影响。

b) 整理要发布的对象脚本，保存为一个文件，如果代码较多则保存为多个文件。

c) 如果是修改或删除存储过程或视图，到线上检查是否有依赖的对象，变更后依赖对象是否能编译通过，如果有依赖对象需要在变更方案中增加依赖对象的编译脚本，如果有依赖对象不能编译通过，应与应用人员反馈，并修改代码，线下调试通过。

d) 备份本次变更线上运行的对象代码，放在变更方案的回滚脚本中，如果备份脚本较多则单独保存到文件。线上可以用@source显示对象的定义脚本。

e) 如果是删除视图或存储过程，需与应用人员确认对象可以删除，并且从v$sql中检查对象是否还有调用，如果对象还有调用则不能删除。

f) 修改或删除对象需要分析对象的调用逻辑及时间点，如果对象运行的时间很长，则需要选择一个对象没有运行的时间点操作，以免编译锁等待。

g) 如果有其它数据库核心代码（并发访问量非常大）引用变更的对象，变更方案里需增加启停ddl_trigger (ddl_trigger_for_database)的过程。

2. 执行过程

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

b) 如果有其它数据库核心代码（并发访问量非常大）引用变更的对象，先打开ddl_trigger。

c) set define off

d) 执行对象变更脚本。

e) 如果是新建存储过程或视图对象脚本编译出错，检查出错原因，修改确认再执行，如果不能找到出错原因，或者是代码本身有逻辑错误，则联系应用人员进行修改，线下验证后再重新发布。

f) 如果是变更存储过程或视图对象脚本编译出错，先回滚代码，然后检查出错原因，修改确认再执行，如果不能找到出错原因，或者是代码本身有逻辑错误，则联系应用人员进行修改，线下验证后再重新发布。

g) 11g

h) 如果是在已有表上新增或修改触发器脚本编译出错，先回滚代码，然后检查出错原因，修改确认再执行，如果不能找到出错原因，或者是代码本身有逻辑错误，则联系应用人员进行修改，线下验证后再重新发布。

i) 对象编译通过后再编译变更依赖的对象。

j) 如果打开了ddl_trigger，变更验证完成后关闭ddl_trigger。

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

3. 验证方案

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

b) 在admin下用pkg_check.CompareObject对比线上与线下库是否一致。

Execute pkg_check.CompareObject(‘schema_name’,’object_name’,’object_type’);

如果有线上与线下不一致，通知应用人员，检查不一致原因，直至线上与线下脚本一致。

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

五、 核心对象风险

变更的对象有大量访问，变更时出现大量library cache pin，导致数据库无法提供服务。

六、 回退方案

使用变更前备份的对象定义脚本回滚，对象定义的回滚脚本要放在数据库本机上，回滚时直接在sqlplus中用@文件名方法运行，最后检查失效对象。

七、 历史故障及教训

略