V1.0
|
Revision |
Author/Modifier | Comments | |
|
No. |
Date |
||
| 1.0 | 2012.2 | 陈雍 | 初稿 |
一、 目的
明确增删唯一约束操作的风险及标准流程，最大限度避免增删唯一约束操作带来的故障。
二、 适用范围
l 项目发布新建表的增删唯一约束
l 对于旧表的增删唯一约束
三、 风险评估
l 对现有表新增唯一约束的操作，会堵塞包括查询在内的所有操作，风险很大，请谨慎使用，尽量在新建表时和开发讨论后增加。
l 没有指定index,系统自动创建了index，删除约束时，自动创建的index同时删除了。
l 在高峰期创建,导致大量的library cache lock/pin的等待
l 有同步的应用，先要在源端加，后在目标端加。
l 表里有重复的数据，导致操作失败。
四、 操作流程
1. 准备工作
a) 检查唯一建字段上是否存在index。没有的话,需首先创建index( 步骤详见增加index手册)。
b) 检查唯一键上是否有重复数据，如有，需和开发讨论如何处理。
c) 根据应用的需求和数据库的负载情况，确定操作的时间点。对于数据量和访问量较大的表，变更时间点要谨慎选择.
d) 检查字段上是否已经有了约束。
e) 增加和删除唯一约束属于标准变更，需要开发在ITIL中提交事件单，应用dba提交变更单，有技术经理审批后执行。
f) 对现有表新增约束，如果使用validate这个参数，会导致该表上连查询在内的所有操作都被锁住，风险非常大；如果使用novalidate参数，这个参数会导致数据字典不一致（及导致sqlldr的时候会导入重复数据）。两者相比，故通常情况下用validate的风险更大，默认必须使用novalidate参数。
g) 约束名与所依赖索引名一致。
2. 执行过程
a) 用应用账户登录数据库，SHOW USER检查是否连接到正确的schema。
b) 执行增加或删除的命令。命令模板如下：
ALTER TABLE 表名 ADD CONSTRAINT 表名_uk unique (字段名) USING INDEX 索引名 NOVALIDATE;
ALTER TABLE 表名 DROP CONSTRAINT 约束名 KEEP INDEX;
如有otter同步，要注意执行顺序：先在源数据库端加后在目标端增加。
c) 查看过程若无报错，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。
3. 验证方案
a) 常规检查：@dbcheck
b) 检查表定义是否与测试库一致：
exec pkg_check.CompareObject(’user‘,’TABLE_NAME‘);
c) 检查约束是否加上或删除：
select * from dba_cons_columns where table_name=upper(‘table_name’)
五、 核心对象风险
1. 核心表访问量大，数据量大。增加唯一约束时会短暂出现library cache pin/lock。执行时间要订在核心表访问的低峰期。
六、 回退方案
1. 执行前需准备好回退的脚本。
2. 回退时需得到开发的确认，并确认回退的时间点。
