物化视图prebuilt和在线重定义

数据迁移中有一种解决方案很有亮点,如果表的数据量大,迁移涉及的表不多,同时对于维护时间有要求的情况下,物化视图的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);
create materialized view log on test;    这个地方需要注意是主键,with rowid的方式是不可以的

目标环境test_target的操作如下:
创建db link
然后创建表,同步表结构即可
create table test_mv as select * from test_mv@prdb where 1=2;
然后创建物化视图,和表同名
create materialized view test_mv on prebuilt table refresh fast as select * from test_mv@test_source;
第一次需要全量刷新数据,也就意味着一次全量,以后都是增量
exec dbms_mview.refresh(‘TEST_MV’,‘FAST’); -- 刷新数据
确认数据同步正常,删除物化视图即可
Drop materialized view test_mv;

需要补充的是创建快速刷新的物化视图,使用如下with rowid的方式是可行的,但是在prebuilt table的情况下,这个还无法支持。
create materialized view test_mv on prebuilt table refresh fast with rowid as select * from test_mv@test_source;
这个其实也可以理解。因为源环境和目标环境是完全不同的数据库环境,rowid无法固定,只能通过主键的方式来定位。
而如果我们进一步细想,如果是同一个数据库中要做这种类似的操作,好像实践意义不大,谁会无聊的自己复制自己的数据,然后不断刷新。
其实不然,大名鼎鼎的在线重定义就是如此。我们来捋一捋里面的一些东西。
在线重定义需要有一个检查步骤。
EXEC dbms_redefinition.can_redef_table('N1','TAB_PART_ONE_PAR',1); 
默认是需要使用PK,否则会报出错误ORA-12089: cannot online redefine table "N1"."TAB_PART_ONE_PAR" with no primary key
而一种改进思路就是使用rowid的方式,改进成为下面的形式即可。
EXEC dbms_redefinition.can_redef_table('N1','TAB_PART_ONE_PAR',dbms_redefinition.cons_use_rowid); 
在同一个数据库中,这样做是没有问题的,我们完全可以通过rowid定位到具体的一行数据。
而在线重定义为什么能够始终保持重定义的过程中,源表始终可用,其实内部就是在通过物化视图日志来得到增量的数据变化,重定义过程中DML操作依旧是在源表上进行,对于源表要说完全没有影响那是不可能的,但是能够保证数据访问,更新操作始终可进行,这个意义就大大不同了。为什么一个表可以在线修改为分区表,为什么一个表添加若干个字段始终会保持业务不受影响。因为在线重定义的本质就是物化视图的prebuilt,比如我们要把一个普通表改为分区表,那么普通表就是源表,分区表就是目标表。
在线重定义的过程中会从源表中复制数据到目标表,类似于insert into 目标表 select *from 源表,或者dbms_mview.refresh('目标表‘,'C')这种方式。
而增量的数据则会写入物化视图日志,可以在后续不断去刷新缩小数据的差异。这个过程就是无话视图的增量刷新,类似于dbms_mview.refresh('目标表‘,'F');
而在最后确认无误的情况下,能够删除和表同名的物化视图,则停止了数据的更新,这样目标表也释放出来了,这个时候需要做的就是,复制源表的数据字典信息,和目标表替换。整个过程都给完整的衔接起来了。
    如此看来,在线重定义的过程真是好玩,和物化视图prebuilt方式较大的差别就是数据字典信息的复制,而在多数据库环境中,源库,目标库的数据访问信息本就不同,所以也就无需考虑这个因素了,大道至简,其实很多思路都是相通。



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

【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
本文以双节点RAC为例,揭示了在执行select及DML操作过程中,Cache Fusion在幕后是如何对block进行锁管理的。 ###实例1上查询scott.t0820_1表 select * from scott.t0820_1;         ID ----------          2 select dbms_rowid.rowid_relative_fno(rowid) rfno,dbms_rowid.rowid_block_number(rowid) blkno from scott.
【故障处理】队列等待之 enq: US - contention 案例 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ① enq: US - contention 等待事件的解决 ② 一般等待事件的解决办法 ③ 队列等待的基本知识   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园
    在Oracle 10g的中搭建Data Guard环境真是一个纠结,目前大体都是采用两种方式,一种是rman备份,一种是duplicate的方式,但是这两个地方不够让我满意,一来是rman备份数据量不小,需要先在本地生成备份,然后拷贝到备库去,这个搭建周期略长,另外一个就是推荐的方式duplicate,在10g中有些鸡肋的味道,本地备份,然后拷贝到备库,然后动用duplicate的方式,这样的方式还不如手工rman的方式同步来得顺心顺意,所以在10g中我是不怎么喜欢duplicate方式。当然11g
【故障处理】队列等待之 TX - allocate ITL entry 引起的死锁处理 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ① enq: TX - allocate ITL entry 等待事件的解决 ② 一般等待事件的解决办法 ③ 队列等待的基本知识 ④  ITL 死锁解决 ⑤  ITL 死锁模拟 ⑥  Merge 语句的非关联形式的查
【技巧】如何使用客户端发布 BLOG+ 如何快速发布微信公众号文章   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  如何使用客户端发布 BLOG (重点) ②  如何快速发布微信公众号文章 ③  如何批量上传图片到blog ④  如何批量上传图片到微信公众号上     Tips: ① 本文在 itpub ( http://blog.itpu

降低高水位线的方法 - 2016-09-13 14:09:09

准备工作,创建一张表: CREATE TABLE TEST2 (     ID    NUMBER(10),     NAME  VARCHAR2(32) ); 1、移动表: SQL begin   2  for i in 1..10000 loop   3  insert into test2 values(i,'bbb');   4  end loop;   5  commit;   6  end;   7  / PL/SQL procedure successfully completed. SQL
预备知识: 1)row cache lock事件   --内存share pool分为library cache,dictionary cache;而row cache lock对象分布在dictionary cache中,是由于对于字典缓冲的访问造成的;   --这类属于latch类的资源竞争,相当耗CPU,如果并发量大的话,容易down机 如果发现这个等待十分高,一般来说可能由于2种原因,一是共享池太小了,需要增加共享池,另外一种情况是SQL分析过于频繁,对于共享池的并发访问量过大。对于任何一种情况,绝
【故障处理】队列等待之 TX - allocate ITL entry 案例 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ① enq: TX - allocate ITL entry 等待事件的解决 ② 一般等待事件的解决办法 ③ 队列等待的基本知识 Tips: ① 本文在 ITpub ( http://blog.itpub.net/267361