在线重定义的补充测试(r10笔记第26天)

在很多时候,我们都是需要保持业务的可持续性,尽管说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") 。。。。 大家有问题可以补充,有些场景下还是值得提倡的。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2016-09-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

Real World Performance 经典性能优化案例-索引竞争

编辑手记:Real World Performance(RWP)团队是个天才的性能优化团队,不断的寻找和创造新的方法分析诊断当今世界业务系统的性能。在他们眼里,...

3639
来自专栏禁心尽力

会优化,你真的会优化吗?其实你可能真的缺少一份理解【数据库篇】

  其实,在写这篇博客之前,我也是感觉自己会点优化,至少知道不要使用“*”号啊,给经常查询的列创建索引啊什么的,其实都不是大家想的那样简单的,其实它们背后存在很...

1976
来自专栏友弟技术工作室

mysql优化

上篇文章是关于mysql优化的,那个内容是我大学的时候学习的笔记,最近学习发现一些比较好的内容,在这里分享给大家。 版权源于网上。 工作中使用最多的就是MySQ...

4797
来自专栏Java进阶架构师

「mysql优化专题」这大概是一篇最好的mysql优化入门文章(1)

优化,一直是面试最常问的一个问题。因为从优化的角度,优化的思路,完全可以看出一个人的技术积累。那么,关于系统优化,假设这么个场景,用户反映系统太卡(其实就是高并...

974
来自专栏杨建荣的学习笔记

数据迁移中的数据库检查和建议(r2笔记71天)

关于数据迁移,在之前也讨论过一些需要注意的地方,可能林林总总列了不少,都是在数据迁移迁移前和迁移时需要注意的。 http://blog.itpub.net/23...

3965
来自专栏蜉蝣禅修之道

oracle数据库学习之rownum

1842
来自专栏企鹅号快讯

WebGenerate 产品介绍

北京劳恩斯科技有限公司 网址: WebGenerate降本增效的代码生产工具,经过WebGenerate生产的代码适用于Spring、MyBatis、Maven...

1897
来自专栏MySQL实战分享

数据库评测报告第一期:MySQL-5.7

这一期的评测报告就着重针对MySQL-5.7在SELECT和UPDATE 中的性能,通过与MariaDB-5.5的对比,展示下新版本MySQL的性能提升。

7354
来自专栏IT派

如何用Python 编写知乎爬虫?So easy!

在爬虫系统中,待抓取 URL 队列是很重要的一部分。待抓取 URL 队列中的 URL 以什么样的顺序排列也是一个很重要的问题,因为这涉及到先抓取那个页面,后抓取...

1470
来自专栏后端技术探索

当规模到亿级,MySQL是一个更好的NoSQL!

MySQL是一个更好的NoSQL数据库。当考虑到NoSQL的使用案例,比如对Key/Value键值存储来讲,MySQL在性能、易用性和稳定性方面更有意义。MyS...

1251

扫码关注云+社区

领取腾讯云代金券