公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2016-09-18 23:42:14 · 原文链接

    在很多时候，我们都是需要保持业务的可持续性，尽管说DDL的过程持续时间很短，但是在线业务出现，就会阻塞DML，导致业务访问中断，事务收到影响，所以在有些场景下，高可用的需求可能比性能的需求优先级还要高一些。
    比如一个分区表，突然发现分区的规则存在一些问题，如果需要重新规划分区，部署，可能对于在线业务影响较大，能不能平滑的过渡到重新规划的分区模式下。
    比如一个普通表，随着数据量的增加发现已经存在一些管理瓶颈，比如历史数据的清理比较麻烦，想改为分区表的方式
    比如一个表需要添加若干字段，数据类型也需要调整等等，这类变更如果通过DDL完成对于在线业务的影响范围较大
    比如一个表所在的分区空间不足，希望能够在业务低峰期进行数据的重构。
有了在线重定义，这些看似困难的工作就会存在可能性，当然万事皆须付出代价，那就是在线重定义本身会消耗系统资源，这个需要合理评估，找到一个合适的时间点来完成。毕竟为了完成高可用的需求而带来了严重的性能问题，那就得不偿失了。
    有些场景还是不大适合在线重定义的，比如一个数据库的表大小为50G,空间剩余不足10G,我们如果使用在线重定义的方案，那么就会存在很大的隐患。因为在线重定义本质上还是需要做一次底层的数据复制。这个就需要消耗系统资源，磁盘空间。
        在线重定义的一个亮点就是保持数据的可持续访问，基本原理是通过物化视图的prebuilt方式完成，所以这种方案本身就是高可用，物化视图的过程中对外 是始终保持可访问的连续性状态，那么对于权限的控制则是这个之外的，所以我格外关心这部分的内容。如果我们的环境存在下面这样的情况，到底在线重定义的过程中是否会很稳定呢，我们可以做对比测试来验证。
如果存在大量的连接用户，在线重定义是否依然能够保证业务的可持续进行。

    尽管我们知道从技术原理上是可以支持的，但是如果进一步验证测试，我想就需要更全面的测试环境了。
    我们分为三个场景来测试。
第一个是通过shell不断生成会话去使用SQL调用基表的数据，看看是否会有中断。
第二个是通过一个已经存在的会话窗口不断的通过SQL去调用基表的数据，查看是否中断
第三个是通过大量的DML操作，查看在线重定义的过程中，是否依然能够稳定运行。

我们初始化了一下的数据。
我们创建基表用户ref_owner,连接用户ref_conn
创建基表test_online_ref
## init
set echo on
create user ref_owner identified by oracle;
create user ref_conn identified by oracle;
grant connect,resource to ref_owner;
grant connect to ref_conn;
grant create synonym to ref_conn;

##owner account: ref_owner
conn ref_owner/oracle

CREATE TABLE test_online_ref
   (  
   col1 varchar2(30),  
   col2 DATE  
   )  ;
alter table    test_online_ref modify(col1 primary key);
生成近300万数据
insert into test_online_ref select level,sysdate+level*0.01 from dual connect by level<3000000;
commit;
grant select,delete,insert,update on ref_owner.test_online_ref to  ref_conn;
然后在连接用户创建同义词。
##connect account: ref_conn
conn ref_conn/oracle
create synonym ref_conn.test_online_ref for ref_owner.test_online_ref;
select count(*)from ref_conn.test_online_ref;
然后创建变更后的表。表结构信息可以根据需求来定义改变，比如从改一个普通表变为分区表。
conn ref_owner/oracle
CREATE TABLE new_ref  
   (  
   col1 varchar2(30),  
   col2 DATE  
   )  
   partition BY range(col2)  
   (  
   partition tab_part_1 VALUES less than (to_date(‘2016-10-01′,’yyyy-mm-dd’)),
   partition tab_part_2 VALUES less than (to_date(‘2017-10-01′,’yyyy-mm-dd’)),
   partition tab_part_3 VALUES less than (to_date(‘2018-10-01′,’yyyy-mm-dd’)),
   partition tab_part_4 VALUES less than (to_date(‘2019-10-01′,’yyyy-mm-dd’)),
   partition tab_part_maxvalue values less than (maxvalue)
   );  
grant select,delete  on ref_owner.new_ref    to ref_conn;