V1.0

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

一、 目的

明确truncate表操作的风险及标准流程，最大限度避免truncate表操作带来的故障。本文涉及到truncate table,truncate partition两个操作。

二、 适用范围

l 数据清理

l 定时truncate表数据清理

三、 风险评估

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

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

l 其他原因truncate错了表，导致应用访问错误。

l 目前同步程序均不支持truncate表，因此被同步环境需要手工truncate。

四、 操作流程

1. 准备工作

a) Truncate操作分为两类：定时truncate，数据清理。操作之前，请明确操作类型，然后选择合适的truncate操作。

b) 定时truncate：

i. 明确告知开发部门truncate操作是不可逆操作；

ii. 确认数据是定期build生成且是可重复操作；

iii. truncate操作，必须要有exception处理，防止诸如表上有事务等，truncate不成功的情况发生。进而影响整个脚本的执行；

iv. 模板：

c) 数据清理

i. 在数据清理之前，明确如下事宜：

1. 知晓备库的延迟时间，针对所有版本数据库；

2. 确认主数据库是否开启闪回功能，针对10g以后的数据库；

3. 确认所做操作表，是否开启闪回数据归档功能，针对11g以后的数据库；

ii. 登录主库使用@size脚本，确认所truncate表的物理size，分区表则明确所truncate分区。

iii. 和应用部门协商所清理数据，是否需要备份。Truncate操作不推荐备份，因为都是临时数据或不重要数据。

1. 若需要备份：truncate表主要是为了节省空间，因此推荐使用EXP的方法导到本地，然后ZIP的方式处理。此外还可以使用create table .. as ..的方法进行备份；

2. 不需要备份，则直接处理。

d) Truncate语法说明：

i. Truncate 表：

ii. Truncate 分区：

e) Truncate操作，会把UNUSABLE的索引变成VALID。这点需要注意，目前规范中不允许把索引置为UNUSABLE。因此该风险理论上不存在，但需要注意。

f) Truncate操作，不需要维护相关依赖。

g) Truncate操作尽量安排在变更窗口执行，若是定时build数据清理，则结合应用处理时间及变更窗口，综合评估。

h) Truncate操作属于一般变更，在ITIL上提单即可。

2. 执行过程

a) 用应用账户登录数据库，SHOW USER检查是否连接到正确的schema。严禁使用sys、system等用户操作。

b) 请再次确认truncate所操作表名，分区名是否正确。

c) Truncate命令必须一条条粘贴，只有确认上一条命令执行成功后，方可执行下一条命令。

d) 查看过程若无报错，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。

3. 验证方案

a) 常规检查：@dbcheck

b) 检查表是否被truncate成功：@size

c) 同步库若建表，也需要执行 a) 和 b) 两个步骤。

五、 核心对象风险

核心对象严禁truncate操作，防止数据无法回滚。

六、 回退方案

Truncate操作回滚方案分为有备份和无备份两类：

有备份：直接从备份里恢复。

无备份：马上联系产品DBA，打开备库，然后从备库拖数据进行恢复。

七、 历史故障及教训

无