V1.0

Revision		Author/Modifier	Comments
No.	Date
1.0	2012.2	王涛	初稿

一、 目的

明确交换分区操作的风险及标准流程，最大限度避免交换分区操作带来的故障。

二、 适用范围

l 定时脚本交换分区（目的是导入数据后，新老数据交换过程对应用透明）。

三、 风险评估

l 登录到错误的schema下，导致交换分区被误执行，而应用无法访问。

l 脚本末尾缺少分号，导致该表没有被创建上，而执行DDL的过程又不会报错。

l 交换分区之前确保两边表结构，索引必须一致。

l 缺少异常判断，导致数据异常，不完整等情况的发生。

l 目前erosa和eai同步程序不支持交换分区，因此不允许把交换分区表配置成同步表，从而导致应用无法同步。

四、 操作流程

1. 准备工作

a) 交换分区适用在数据同步，数据定时build的情况；其优点就是数据交换快，前台用户几乎无影响。

b) 明确分区表不支持erosa同步，不支持trigger等方式同步。

c) 和应用部门明确交换分区时间，避免在数据未准备好的情况下，进行分区交换。

d) 分区表，被分区表两边的结构，索引必须一致。

e) 关于交换分区表的索引:

i. 推荐local index，因为local类型的索引，会随着交换分区一同交换过去;

ii. 使用global index，交换分区后索引就无效了；除非交换的时候显式的加上” update global Indexes”，但这样的话交换分区的速度就慢了；失去交换分区的意义，而且容易带来DBA手工执行忘记增加该语句的风险；

iii. 在交换分区的时候，务必加上”including indexes”选项，表示连索引一起交换过去。

f) 在交换分区的时候，统计信息是不会被交换的。因此若数据分布固定，建议采用定时分析机制或采用LOCK统计信息的方式。

g) 关于数据校验，我们在交换分区的时候，一般都采用”Without Validation” 选项，因此在交换分区之前，请检查数据的有效性。

h) 在每次交换分区之前，必须显式的用SQL判断被交换表是否有数据，若无数据，不进行交换。

i) 交换分区的表明确不允许应用写操作。

j) 交换分区不得在高峰时段做此操作。有必要和应用负责人约定交换分区时间，防止意外情况发生。在变更窗口内进行即可。

k) 交换分区操作属于标准变更，在做之前必须在ITIL中提交相应的变更申请。

2. 执行过程

a) 脚本自动运行，判断各种异常情况。发送报警给对应DBA。

3. 验证方案

a) 脚本自动运行，无需验证。

五、 核心对象风险

核心对象不允许使用交换分区。

六、 回退方案

原则上只要不是数据异常情况，一般不需要进行回滚。若需要回滚，执行上一次的交换分区方案即可。

七、 历史故障及教训

略。