在线重定义的补充测试

    在很多时候,我们都是需要保持业务的可持续性,尽管说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;

数据初始化完成,接下来我们需要做的是在线重定义了。
其实脚本就是下面的几行内容。
exec dbms_redefinition.can_redef_table('REF_OWNER','test_online_ref',1);  
exec  DBMS_REDEFINITION.CAN_REDEF_TABLE('REF_OWNER','test_online_ref',2);  
exec  DBMS_REDEFINITION.START_REDEF_TABLE('REF_OWNER','test_online_ref','new_ref',NULL,2);  
exec  DBMS_REDEFINITION.FINISH_REDEF_TABLE('REF_OWNER','test_online_ref','new_ref');

在线重定义的过程中,我们会并发调用开始所说的3个脚本来调用。然后观察是否会存在ORA的错误。
第一个场景的脚本如下:
function test_conn
{
sqlplus -s ref_conn/oracle <<EOF
set feedback off
set time on
col systimestamp format a35
select systimestamp,count(*)from test_online_ref;
EOF
}

for i in {1..1000000}
do
test_conn
done

剩下两个场景的脚本,套路都是类似的,通过频繁的DML或者查询来完成
比如查询
select systimestamp,count(*)from test_online_ref;
比如DML
delete from test_online_ref where rownum<2;
commit;

很快就测试完毕,查看日志没有任何的ORA错误。所以我们可以得到一个肯定的测试结果就是在线重定义是可信赖的。
得到的日志类似下面的形式:
我们可以从日志看到数据在极短的时间内发生变化依旧可以保持数据的可持续访问变更。尽管会出现一定的卡顿,从日志里看大概是3秒钟,但是业务访问不会中断。
SYSTIMESTAMP                          COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.53.769959 PM +08:00    2923035

SYSTIMESTAMP                          COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.53.898239 PM +08:00    2922896

SYSTIMESTAMP                          COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.56.325261 PM +08:00    2922722

SYSTIMESTAMP                          COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.56.454042 PM +08:00    2922599

变更完成后,原来的分区表new_ref就变成了普通表。
SQL> select dbms_metadata.get_ddl('TABLE','NEW_REF','REF_OWNER') from dual;     
  CREATE TABLE "REF_OWNER"."NEW_REF"
   (    "COL1" VARCHAR2(30),
        "COL2" DATE,
         PRIMARY KEY ("COL1")
。。。。
大家有问题可以补充,有些场景下还是值得提倡的。

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。

oracle手动删除数据库 - 2016-09-21 14:09:23

有时候,无法使用图形界面时,我们需要手动删除数据库,具体操作步骤如下: 一、手动删除文件系统数据库    1.停止监听,防止有新的连接产生,同时,在数据库配置了em的,也需要停止        $ lsnrctl stop listener_name        $ emctl stop dbconsole    2.获得数据文件,日志文件及控制文件的相关信息,包含归档              $ sqlplus /as sysdba        SQLshow parameter control
  【 技巧 】如何让普通用户可以杀掉自己用户的会话   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  如何让普通用户可以杀掉自己用户的会话(重点)     Tips : ①  本文在 itpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )

聊聊Data Guard中的DG Broker - 2016-09-20 18:09:07

    DG Broker是Oracle为Data Guard维护提供的一个很不错的工具,从我的实际使用来看,早期的版本中似乎大家都还是存在一定的思维定式,认为手工维护已经足够了。这个工具就不那么需要了,我们完全可以脱离开这些工具来直观的使用命令行的方式来维护,这个观点也没错,不过从与时俱进的角度来看,本来能够让你更轻松的一个工具,如果不用实在是太可惜了。     DG Broker在数据库端需要启用一个后台进程dmon来维护,这个后台进程启动,需要设置dg_broker_start为true即可,如果要停
报名缘起   去年年底,崔老师发微信说12c OCM可以提上日程了。先不说那不菲的考试费用,单一个C(loud)就够我冷静一下了。最近几次参加线下分享活动,很多主题都离不开Cloud,听得云里雾里的。我问了一下自己,我可以吗?要不再等等吧。   过完年后,几个小伙伴蠢蠢欲动,看着朋友圈有朋友晒出的12c战袍还蛮帅的,走,报名去! 12c OCM考试号称“史上最难”   Oracle于2015年正式推出12c OCM升级考试,和以往的10g、11g OCM不同的是,12c OCM考试还要求考生每场达到最低分
  【 等待事件 】等待事件系列( 3+4 ) --System IO (控制文件) + 日志类等待   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  控制文件类等待 ② 日志类等待   2.2    相关参考文章链接 【推荐】 等待事件系列(1)--User I/O类型(下) http://blog.itpub.net/26736162/v
今儿需要部署一个Oracle环境,为了简单些,选择了Oracle提供的Linux版本介质:OracleLinux-R6-U2-Server-x86_64-dvd.iso,在安装的过程中碰见了几个常见的问题,简要记录下,便于日后查找。 问题1:无法登陆图形界面   按照正常流程安装后,默认是没有安装图形界面的,因此进入的是命令行界面,若不用静默安装或克隆安装,则必须需要图形界面。于是按照常规做如下操作:  (1) 修改/etc/inittab中id:3:initdefault的3为5。  (2) start

【函数】wm_concat包的订制 - 2016-09-20 14:09:39

  【 函数 】 wm_concat 包的订制   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  利用系统包创建 WM_CONCAT 函数 (重点) ② ORA-00904: "wm_concat":invalid identifier 错误解决 ③  订制自己的 WM_CONCAT 函数 ④  listagg 分析函数的使用 ⑤ ORA-0
数据迁移中有一种解决方案很有亮点,如果表的数据量大,迁移涉及的表不多,同时对于维护时间有要求的情况下,物化视图的prebuilt方式就是一种很不错的选择。 大体的步骤和方法如下: 假设源环境是test_source,目标环境是test_target 在源环境中test_source的操作如下: Create table test_mv as select *from all_objects  ; alter table test_mv modify(object_id primary key); creat

【MySQL】5.7新特性之六 - 2016-09-15 17:09:05

写在前面   本系列文章基于 5.7.12 版本讲述MySQL的新特性。从安装,文件结构,SQL ,优化 ,运维层面 复制,GITD等几个方面展开介绍 5.7 的新特性和功能。同时也建议大家跟踪官方blog和官方文档,以尽快知悉其新的变化。 6.1  优化(工具方面)增强   5.7 版本中如果一个会话正在执行sql,且该sql 是支持explain的,那么我们可以通过指定会话id,查看该sql的执行计划。 EXPLAIN  [ options ]   FOR  CONNECTION connection
工具用于查看指定时间内show global status指标的变化,能够帮助运维人员了解系统负载的走势 本工具在5.5 5.6 5.7中测试通过 源码我放在百度云盘了 http://pan.baidu.com/s/1mhIeKp6 源码一共5个文件 conmysql.c main.c findv.c other.c type.h 如果源码编译使用如下方法 1、建立一个MYSQL用户用于监控,不需要什么权限只要能够show global status 即可 mysql create user mmon@'l