随着信息技术的发展，业务的可用性要求越来越高，在高可用的环境中，如果需要改变表的定义是比较棘手的，特别是对于7x24的系统，需要停止业务来改造表定义的代价是非常大的。ORACLE提供的基本语法可以修改表的基本属性，但对于普通表、分区表、索引组织表之间的转换，是无法完成的，那么有哪些方法可以 转换呢？笔者在此给读者一个方法。

1、 停业务，停监听等；

2、 将全表数据使用数据泵导出；

3、 DROP原表，新建分区表；

4、 将数据导入分区表中，恢复业务；

这样下来，一般需要停机几个小时，甚至需要熬夜实施。现在有一种方法，可以在线实施，并且不会影响业务，它就是在线重定义功能。（笔者已经多次成功实施）

从ORACLE 9i开始，提供了在线重定义的功能，通过调用DBMS_REDEFINITION包来实现，那它是如何实现的呢？我们先来了解下在线重定义。

在线重定义：通过调用DBMS_REDEFINITION包，在瞬间锁表的情况下，将表改造成理想的表。它使用数据同步原理，需要双倍空间（原来的表和索引 算一份），将数据全量同步到目标表，再做一次增量同步，这些过程都不会锁表，不影响业务使用，最后做一次增量数据同步和表定义对换，完成表转换，此时会锁 表，经验告诉笔者锁表时长在1s内（根据增量数据大小略有不同）。

常用场景：

1. 普通表、分区表、索引组织表之间的相互转换；

2. 将表迁移至其他表空间；

3. 修改表的存储属性；

4. 重建表以减少碎片；

优点：

1. 对业务影响非常小，锁表时间非常短，仅在结束时瞬间存在；

2. 速度较快，在实践中15G的表仅用了12min；

缺点：

1. 需要使用与原表同样大小的存储空间，包括索引、LOB字段等；

2. 需要占用一定的系统资源；

实现步骤：

1. 检查表能否进行在线重定义，通过主键或rowid两种方法；

2. 创建目标表结构，空表，索引等不用创建；

3. 开始进行在线重定义，先全量同步一次数据；

4. 同步依赖的对象，包括索引、约束、触发器、权限等；

5. 做一次增量数据同步；

6. 完成在线重定义；

7. 清理旧表，释放空间；

8. 收集统计信息，检查索引名，并行度等；

DBMS_REDEFINITION包：

1. ABSORT_REDEF_TABLE：清理重定义的错误和中止重定义；

2. CAN_REDEF_TABLE：检查表是否可以进行重定义；

3. COPY_TABLE_DEPENDENTS：同步依赖的对象，如索引、权限、约束、触发器等；

4. FINISH_REDEF_TABLE：结束在线重定义；

5. REGISTER_DEPENDENTS_OBJECTS：注册依赖的对象，如索引、约束、触发器等；

6. START_REDEF_TABLE：开始在线重定义；

7. SYNC_INITERIM_TABLE：同步增量数据；

8. UNREGISTER_DEPENDENT_OBJECT：不注册依赖的对象，如索引、约束、触发器等；

在线重定义支持两种重定义的方法，一种是基于主键，一种是基于ROWID。其中ROWID的方法是10G以后才支持，且不能用于索引组织表，而且重定义完成后会存在隐藏列M_ROW$$。默认采用主键的方式。

背景：需要将HJADM.REC_CODE_RESULT表改造成分区表HJADM. REC_CODE_RESULT_TARGET，目标表已经创建好了，原表存在主键。

第一步： 检查表能否进行在线重定义

总结：检查表通过主键可以进行重定义。如果表没有主键，那么使用rowid的方法，调用的是dbms_redefinition.cons_use_rowid。

第二步： 创建目标表

在实施前已经创建好表HJADM. REC_CODE_RESULT_TARGET。

第三步： 开始进行在线重定义

总结：开始进行重定义会比较慢，因为需要做一次全量数据同步。全量数据同步完成后，检查了一下记录数，已存在增量数据了。

第四步： 同步依赖的对象

总结：复制相关的依赖对象，完成后检查结果没有报错。若是9i的数据库，可以手工建立相关的对象。

第五步： 做一次增量数据同步

总结：结束重定义，此时会锁表，交换表涉及的数据字典中的相关数据。

第六步： 完成在线重定义

总结：结束重定义，此时会锁表，交换表涉及的数据字典中的相关数据。

第七步： 清理旧表，释放空间

总结：将旧表删除，以释放空间。

第八步： 收集表的统计信息，检查索引名、并行度等，检查无效对象，最好编译一下

PS：此步比较容易忘记。

总结：此表约有5G的数据，整个操作过程约10min完成，仅在完成重定义的时候锁了一下表，在1s内完成，对业务的影响几乎为零。

在线重定义的功能对7x24的OLTP系统有非常大的优势，在重定义的过程中，也不影响业务的使用，业务仍然可以对其访问、修改、新增、删除等操作，是实现数据库高可用的一个很实用的方法。分享就到此了，希望大家有所收获。

作者介绍：温伟灵

• 新炬网络高级技术专家

• 拥有六年的IT运维经验，从工作开始接触ORACLE数据库，精通ORACLE数据库的内 存结构、RAC、DataGuard等，在备份恢复、GoldenGate方面有深入的钻研。

• 具有30TB级的OLTP数据库运维经验，擅长故障诊断、处 理。

• 目前负责十多个客户的数据库运维工作，具有交通、金融、政府、移动、医疗等行业的运维经验。

小编精心为大家挑选了近日最受欢迎的几篇热文:

回复001，看杨志洪《【职场心路】一个老DBA的自白》；

回复002，看丁俊的《【重磅干货】看了此文，Oracle SQL优化文章不必再看！》；

回复003，看胡怡文《PG，一道横跨oltp到olap的梦想之桥》；

回复004，看陈科《memcached&redis等分布式缓存的实现原理》；

回复005，看宋日杰《Oracle后台专家解决library cache锁争用的终极武器》；

回复006，看郑晓辉《存储和数据库不得不说的故事》；

回复007，看袁伟翔《揭秘Oracle数据库truncate原理》；

回复008，看杨建荣《立等可取:工具定制让Oracle优化变得更简单快捷》；

回复009，看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》；

回复010，看徐桂林《以应用为中心的企业混合云管理》。

关于DBA+社群