V1.0

一、 目的

阐述表变更的风险及其步骤，降低对应用的影响和避免故障。

二、 适用范围

l 所有在使用的表修改字段长度，具体是number型和varchar2型，只允许范围扩大。

三、 风险评估

l 相关表的长度是否一并修改

当该表某个字段长度加长后，可能有关联的表的数据来自于该表，那么那个关联的表的相应字段也应该加长。这点由应用去评估。

该表上如果有物化视图，则物化视图的基表的对应的字段长度也要加长。

该表上如果有存储过程、触发器、package，里面的代码中跟该字段有关的变量如果声明的是具体的长度，则也要加长。正确的声明方式是col%type。

l 修改字段导致依赖对象失效、sql游标失效问题。

表的DML并发很高的时候，如果表上面还有依赖对象，修改字段长度会导致依赖对象失效。默认其他DML会话会尝试去自动编译这个依赖对象，此时很可能会出现大面积的library cache pin。应用会话的连接时间会加长，进而导致出现后续应用报不能取得连接池错误。应用服务器load由此飙升。

表修改字段长度也会导致跟该表有关的SQL的游标失效，如果SQL的并发很高（查询SQL或者DML SQL），失效后SQL会重新解析，此时也可能会出现大量的library cache pin & library cache lock。

解决方法：选择在业务低峰期发布，同时在数据库级别开启trigger禁用客户端程序自动编译功能，字段加完后再禁用该trigger。

l 表的依赖对象是否要相应调整。

表上面的依赖对象如果有存储过程或触发器等，逻辑是否需要相应调整。

l 是否涉及到同步。

同步中的表需要两地都要变更。涉及到erosa的要更新一下数据字典。Erosa是否需要重启取决于erosa版本。

l 是否要通知其他关联的部门。如DW, ASC或CRM等等。

有些表很多部门都用，需要沟通约定时间一起变更。如果有同步方案，同步方案的变更也要考虑。

四、 操作流程

1. 准备工作

a) 该表的数据量以及大小，以及数据变更量（按日/时/分/秒等）

b) 该表的并发访问数，以及频率最高的几种sql的访问方式

2. 执行过程

以表T1 加字段 col2为例。T1的数据量非常大，访问频率很高。

a) 在sysdba下开启trigger禁用客户端自动编译功能。（可选）

Alter trigger SYS.ddl_trigger_for_database enable;

b) 变更字段

以下加字段同编译失效对象连着执行。编译时先编译trigger再编译存储过程或package等

@conn zzzzzz/aaa

Alter table t1 modify col2 varchar2(50);

Alter trigger trg_t1_search compile;

@conn retl/rrr

Alter trigger trg_t1_sync compile;

@conn bopsretl/bbb

Alter trigger trg_t1_sync compile;

@conn zzzzzz/aaa

Alter procedure sp_test compile;

后面3个trigger的编译可以开三个窗口同时进行。

另开一个窗口，在admin用户下查看当前失效对象

@dbcheck

c) 禁用ddl trigger

Alter trigger SYS.ddl_trigger_for_database disable;

d) 涉及到同步的表，各个节点都变更，erosa重启取决于版本

–更新erosa数据字典

./getDict.sh

–erosa重启

./erctl stop

./erctl start

3. 验证方案

a) 验证sys下的trigger已经禁用

Select owner,trigger_name,status from dba_triggers where owner in (‘SYS’) and trigger_name=upper(‘ ddl_trigger_for_database ’);

b) 验证结构正确

Desc alibaba1949.t1

c) 验证无失效依赖对象

@dbcheck

d) 跟测试库比对结构

五、 核心对象风险

核心对象风险指的是业务上重要的表，并且数据量很大或表大小很大或并发访问数很高时，变更的潜在风险。前面已经阐述。

六、 回退方案

1. 字段加长不允许回滚。

七、 历史故障及教训

略