oracle 物化视图、中间表的方案

物化视图

有个项目因为有比较多的查询汇总，考虑到速度，所以使用了物化视图。简单的把用到的给整理了下。先看简单创建语句：
create materialized view mv_materialized_test refresh force on demand start with sysdate next
to_date(concat(to_char( sysdate+1,'dd-mm-yyyy'),'10:25:00'),'dd-mm-yyyy hh24:mi:ss') as
select * from user_info; --这个物化视图在每天10：25进行刷新物化视图也是种视图。Oracle的物化视图是包括一个查询结果的数据库对像，它是远程数据的的本地副本，或者用来生成基于数据表求和的汇总表。物化视图存储基于远程表的数据，也可以称为快照。
物化视图可以查询表，视图和其它的物化视图。特点：
(1) 物化视图在某种意义上说就是一个物理表(而且不仅仅是一个物理表)，这通过其可以被user_tables查询出来，而得到确认；
(2) 物化视图也是一种段(segment)，所以其有自己的物理存储属性；
(3) 物化视图会占用数据库磁盘空间，这点从user_segment的查询结果，可以得到佐证；
创建语句：create materialized view mv_name as select * from table_name
因为物化视图由于是物理真实存在的，故可以创建索引。创建时生成数据：
分为两种：build immediate 和 build deferred，
build immediate是在创建物化视图的时候就生成数据。
build deferred则在创建时不生成数据，以后根据需要在生成数据。
如果不指定，则默认为build immediate。刷新模式：
物化视图有二种刷新模式：
在创建时refresh mode是 on demand 还是 on commit。
on demand 顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新(REFRESH)，即更新物化视图，以保证和基表数据的一致性;
on commit  提交触发，一旦基表有了commit，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。一般用这种方法在操作基表时速度会比较慢。
创建物化视图时未作指定，则Oracle按 on demand 模式来创建。上面说的是刷新的模式，针对于如何刷新，则有三种刷新方法：完全刷新（COMPLETE）： 会删除表中所有的记录（如果是单表刷新，可能会采用TRUNCATE的方式），然后根据物化视图中查询语句的定义重新生成物化视图。
快速刷新（FAST）： 采用增量刷新的机制，只将自上次刷新以后对基表进行的所有操作刷新到物化视图中去。FAST必须创建基于主表的视图日志。对于增量刷新选项，如果在子查询中存在分析函数，则物化视图不起作用。
FORCE方式：这是默认的数据刷新方式。Oracle会自动判断是否满足快速刷新的条件，如果满足则进行快速刷新，否则进行完全刷新。关于快速刷新：Oracle物化视图的快速刷新机制是通过物化视图日志完成的。Oracle通过一个物化视图日志还可以支持多个物化视图的快速刷新。物化视图日志根据不同物化视图的快速刷新的需要，可以建立为ROWID或PRIMARY KEY类型的。还可以选择是否包括SEQUENCE、INCLUDING NEW VALUES以及指定列的列表。查询重写（QueryRewrite）：
包括 enable query rewrite 和 disable query rewrite 两种。
分别指出创建的物化视图是否支持查询重写。查询重写是指当对物化视图的基表进行查询时，oracle会自动判断能否通过查询物化视图来得到结果，如果可以，则避免了聚集或连接操作，而直接从已经计算好的物化视图中读取数据。
默认为disable query rewrite。语法：
create materialized view view_name
refresh [fast|complete|force]
[
on [commit|demand] |
start with (start_time) next (next_time)
]
AS subquery;具体操作创建物化视图需要的权限：
grant create materialized view to user_name; 在源表建立物化视图日志：
create materialized view log on test_table
tablespace test_space -- 日志空间
with primary key;     -- 指定为主键类型在目标数据库上创建MATERIALIZED VIEW：
create materialized view mv_materialized_test refresh force on demand start with sysdate next
to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),'10:25:00'),'dd-mm-yyyy hh24:mi:ss') as
select * from user_info; --这个物化视图在每天10：25进行刷新 修改刷新时间：
alter materialized view mv_materialized_test refresh force on demand start with sysdate
next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 23:00:00'),'dd-mm-yyyy hh24:mi:ss');
或
alter materialized view mv_materialized_test refresh force on demand start with sysdate
next trunc(sysdate,'dd')+1+1/24; -- 每天1点刷新 建立索引：
create index IDX_MMT_IU_TEST
on mv_materialized_test(ID,UNAME)
tablespace test_space; 删除物化视图及日志：
drop materialized view log on test_table;    --删除物化视图日志：
drop materialized view mv_materialized_test; --删除物化视图
---------------------------------------------------------------------
物化视图的刷新有二类，分别是：on commit ；on demand。刷新方法有三种分别是：快速（FAST），完全（COMPLETE），强制（FORCE）；ON COMMIT 与DEMAND 在应用中的问题
ON COMMIT
如果选择on commit ，则在对主表应用上会造成速度，这是因为ORACLＥ在对主表操作提交后马上会进行刷新物化视图操作，这部分时间是也包括在提交时间中。a) refresh force on commit:中对删，新增记录，物理视图都能真实反映主表的变化。同时这种情况下不用建物化视图日志表。缺点是提交时间长。b) refresh fast on commit:中对新增或修改能真实反映主表的变化，但对删除则不能反映，必须进行一次完全刷新。ON DEMAND
DEMAND必须用DBMS_MVIEW.REFRESH存储过程建立的JOB去定时刷新物化视图。a) refresh fast on DEMAND:必须通过调用DBMS_MVIEW.REFRESH存储过程来进行快速刷新反映主表新增情况；但当对主表中的数据删除或修改时，快速刷新则会报错，因此必须调DBMS_MVIEW.REFRESH的完全刷新才能反映。可以通过建立JOB解决。表１：快速刷新declare
v_mvname varchar2(50);
begin
v_mvname:='MOCHA_FE_DOC_CONTENT_MV';
dbms_mview.refresh(v_mvname,'f');
end;
/表２：完全刷新declare
v_mvname varchar2(50);
begin
v_mvname:='MOCHA_FE_DOC_CONTENT_MV';
dbms_mview.refresh(v_mvname,'C');
end;
/注意：用FAST 刷新物化视图，前提要新建物化视图日志表。b) refresh force/complate on DEMAND:在这种方式下物化视图也是无法自动刷新，必须通过JOB或手工。FAST、FORCE、COMPLETE区别
FAST：增量式刷新，使用此方法必须有前提，就是建立物化视图日志表。FORCE:：如果可以以fast 方式刷新则用，否则完全刷新。COMPLETE：先将物化视图表内容删除，然后再刷新。此方式缺少就是在刷新时间内用法在页面无法查到的所需要内容。
----------------------------------------------------------------------------------
官方文档:https://docs.oracle.com/cd/E11882_01/server.112/e10706/repmview.htm#REPLN3351.1   概念
物化视图 [1]  （Materialized View）在9i以前的版本叫做快照（SNAPSHOT)，从9i开始改名叫做物化视图。它是用于预先计算并保存表连接或聚集等耗时较多的操作的结果，这样，在执行查询时，就可以避免进行这些耗时的操作，从而快速的得到结果。物化视图有很多方面和索引很相似：使用物化视图的目的是为了提高查询性能；物化视图对应用透明，增加和删除物化视图不会影响应用程序中SQL 语句的正确性和有效性；物化视图需要占用存储空间；当基表发生变化时，物化视图也应当刷新。简单说,物化视图不仅存储了sql的定义,还存储了数据;它是远程数据的的本地副本，或者用来生成基于数据表求和的汇总表。物化视图存储基于远程表的数据，也可以称为快照。物化视图可以查询表，视图和其它的物化视图。特点：(1) 物化视图在某种意义上说就是一个物理表(而且不仅仅是一个物理表)，这通过其可以被user_tables查询出来，而得到确认；(2) 物化视图也是一种段(segment)，所以其有自己的物理存储属性；(3) 物化视图会占用数据库磁盘空间，这点从user_segment的查询结果，可以得到佐证；创建语句：create materialized view mv_name asselect * from table_name因为物化视图由于是物理真实存在的，故可以创建索引。字典:--物化视图日志字典,可查看具体的日志表select* from dba_MVIEW_LOGS;     --查看物化视图,可以查到定义的各种条件以及更新时间,以及查询语句等select* from DBA_MVIEWS;--物化视图跟源对象的对应关系select * from all_mview_refresh_times aa whereaa.MASTER='EMP'and aa.NAME='MY_EMP_VIEW';1.1.1  语法create materialized view view_namebuild immediate|deferred
refresh [fast|complete|force]
[on [commit|demand] |
enable queryrewrite |disable query rewrite
start with (start_time) next (next_time)]AS 查询语句;默认: build immediate,refresh force,on demand,disablequery rewrite含义:1创建时生成数据：分为两种：build immediate 和 build deferred，build immediate是在创建物化视图的时候就生成数据。build deferred则在创建时不生成数据，以后根据需要在生成数据。如果不指定，则默认为buildimmediate。2刷新模式：物化视图有二种刷新模式：在创建时refresh mode是 ondemand 还是 on commit。on commit  提交触发，一旦基表有了commit，即事务提交，则立刻刷新;如果选择on commit ，则在对主表应用上会造成速度，这是因为ORACLＥ在对主表操作提交后马上会进行刷新物化视图操作，这部分时间是也包括在提交时间中。a) refresh complete on commit:完全更新,不用建日志表,缺点是提交时间长。b) refreshfast on commit:必须先建立日志表,增删改都能同步 ,oracle11g经过测试得出;c) refresh force oncommit:先走fast,不行走completeon demand:手动刷新同步,调用过程DBMS_MVIEW.REFRESH,也可以建立job调用过程更新;相对于commit,只不过手动调用而已;a) refresh completeon DEMAND:全量刷新b) refresh fast on DEMAND: 同commit必须先建立日志表通过调用DBMS_MVIEW.REFRESH存储过程来进行数据的刷新同步;c) refresh force on DEMAND: 先走fast,不行走complete3细节如下:完全刷新（COMPLETE）： 会删除表中所有的记录（如果是单表刷新，可能会采用TRUNCATE的方式），然后根据物化视图中查询语句的定义重新生成物化视图。快速刷新（FAST）： 采用增量刷新的机制，只将自上次刷新以后对基表进行的所有操作刷新到物化视图中去。FAST必须创建基于主表的视图日志。对于增量刷新选项，如果在子查询中存在分析函数，则物化视图不起作用。FORCE方式：这是默认的数据刷新方式。Oracle会自动判断是否满足快速刷新的条件，如果满足则进行快速刷新，否则进行完全刷新。关于快速刷新fast：Oracle物化视图的快速刷新机制是通过物化视图日志完成的。Oracle通过一个物化视图日志还可以支持多个物化视图的快速刷新。快速更新必须要有物化视图日志表,不论是commit还是demand;4查询重写（QueryRewrite）：包括 enablequery rewrite 和 disable query rewrite 两种。分别指出创建的物化视图是否支持查询重写。查询重写是指当对物化视图的基表进行查询时，oracle会自动判断能否通过查询物化视图来得到结果，如果可以，则避免了聚集或连接操作，而直接从已经计算好的物化视图中读取数据。默认为disable queryrewrite。5fast刷新的限制：所有类型的快速刷新物化视图都必须满足的条件：1.物化视图不能包含对不重复表达式的引用，如SYSDATE和ROWNUM；2.物化视图不能包含对LONG和LONG RAW数据类型的引用。只包含连接的物化视图：1.必须满足所有快速刷新物化视图都满足的条件；2.不能包括GROUP BY语句或聚集操作；3.如果在WHERE语句中包含外连接，那么唯一约束必须存在于连接中内表的连接列上；4.如果不包含外连接，那么WHERE语句没有限制，如果包含外连接，那么WHERE语句中只能使用AND连接，并且只能使用“＝”操作。5.FROM语句列表中所有表的ROWID必须出现在SELECT语句的列表中。1.2   物化视图日志
Following are the types of materializedview logs:Primary Key: The materialized view records changes to the master table or master materialized view based on the primary key of the affected rows.
Row ID: The materialized view records changes to the master table or master materialized view based on the rowid of the affected rows.
Object ID: The materialized view records changes to the master object table or master object materialized view based on the object identifier of the affected row objects.
Combination: The materialized view records changes to the master table or master materialized view based any combination of the three options. It is possible to record changes based on the primary key, the ROWID, and the object identifier of the affected rows. Such a materialized view log supports primary key, ROWID, and object materialized views, which is helpful for environments that have all three types of materialized views based on a master.
翻译：主键：物化视图根据受影响行的主键记录对主表或主物化视图的更改。行ID：物化视图根据受影响行的rowid记录对主表或主物化视图的更改。Object ID：物化视图根据受影响行对象的对象标识符记录对主对象表或主对象物化视图的更改。组合：物化视图记录基于这三个选项的任意组合对主表或主物化视图的更改。可以根据主键、ROWID和受影响行的对象标识符记录更改。这样的物化视图日志支持主键、ROWID和对象物化视图，这对于基于主目录拥有所有三种类型物化视图的环境很有帮助。物化视图日志根据不同物化视图的快速刷新的需要，可以建立为ROWID或PRIMARY KEY类型的。还可以选择是否包括SEQUENCE、INCLUDING NEW VALUES以及指定列的列表。底层应该还是用到了类似的行级触发器;如:create materialized view log on emp--可以指定表空间tablespacetest_space -- 日志空间 with primary key; --查看物化视图的刷新情况select *from USER_MVIEW_LOGS;物化视图日志的名称为MLOG$_后面跟基表的名称，如果表名的长度超过20位，则只取前20位，当截短后出现名称重复时，Oracle会自动在物化视图日志名称后面加上数字作为序号。通过这个字典可以查找到具体的日志表;通过日志表就可以知道更新情况;--查看日志表select *from MLOG$_EMP  ;SNAPTIME$$：用于表示刷新时间。DMLTYPE$$：用于表示DML操作类型，I表示INSERT，D表示DELETE，U表示UPDATE。OLD_NEW$$：用于表示这个值是新值还是旧值。N（EW）表示新值，O（LD）表示旧值，U表示UPDATE操作。CHANGE_VECTOR$$：表示修改矢量，用来表示被修改的是哪个或哪几个字段。当刷新完成后MLOG$_EMP相应的日志记录,会被清空;在刷新(同步)物化视图之前你可以做各种DML操作;在你提交之前就会记录到日志表;-------------------------------------------------------------------------------
1. 用法物化视图是包括一个查询结果的数据库对象，它是远程数据的的本地副本，或者用来生成基于数据表求和的汇总表。物化视图存储基于远程表的数据，也可以称为快照。对于复制，物化视图允许你在本地维护远程数据的副本,这些副本是只读的。如果你想修改本地副本，必须用高级复制的功能。当你想从一个表或视图中抽取数据时，你可以用从物化视图中抽取。对于数据仓库，创建的物化视图通常情况下是聚合视图，单一表聚合视图和连接视图。    实现两个数据库之间的数据同步，可以存在时间差。1. 刷新的方式FastCompleteFource2. 刷新的方法DBMS_REFRESH.RefreshDBMS_MVIEW.Refresh2. 具体应用(1).在源数据库建立mview log日志文件create materialized view log on w_1 ;----注：(TEST为表名或者视图名，关于视图上建立物化视图，见基于视图的物化视图----创建物化视图语句：(2).在统计数据建立materializad view  语法    Create materialized view MV_TEST----MVTEST为物化视图名Build immediate----创建时生成数据对应的是build deferredRefresh fast----增量刷新On commit----在基表有更新时提交，这里该句对视图无效With rowid----这里创建基于rowid的物化视图，对应的是 primary keyAsSelect * from TEST;----生成物化视图数据语句(3).调用时进行刷新dbms_refresh.refresh('W_1')---------------------------------------------------------------
oracle物化视图
物化视图是一种特殊的物理表，“物化”(Materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询，Oracle都实际上转换为视图SQL语句的查询。这样对整体查询性能的提高，并没有实质上的好处。创建物化视图需要的权限：grant create materialized view to user_name; 创建语句：create materialized view mv_name [选项n] as select * from table_name;[选项1]：BUILD [immediate,deferred] 是否在创建视图时生成数据，默认生成、deferred为不生成数据，需要的时候生成[选项2]：refresh  [fast|complete|force|never] fast是增量刷新，或者叫快速刷新；complete为全表刷新；force为如果增量刷新可以使用则使用增量刷新，否则全表刷新；never则是不进行刷新（不使用）[选项3]：on [demand,commit] 即手工刷新和提交时刷新[选项4]：start with 通知数据库完成从主表到本地表第一次复制的时间[选项5]：next 说明了刷新的时间间隔，下次刷新的时间=上次执行完成的时间+时间间隔例子1：create materialized view V_AB refresh force on commit as  select * from a,b where a.id=b.id分析：创建一个物化视图来存储a,b两个表的数据，force表示尽量使用增量刷新，但是这种写法只会进行全表刷新。commit表示自动刷新，也就是说，当我们增删改a,b表后进行commit操作后，我们的物化视图也会同时进行数据的刷新。如果想要使用增量刷新来提高效率，请看下面的例子例子2：首先要建立与原表rowid相关的物化视图：create materialized view log on A with rowid;create materialized view log on B with rowid;再创建真正的物化视图create materialized view V_AB refresh fast on demand start with sysdate next  sysdate+1/1440 as select a.rowid as arowid,b.rowid as browid, (其余字段) from a,b where a.id=b.id;这里使用demand代表手动刷新，start with代表开始复制的时间，next说明间隔一分钟后刷新，也就是说，当我们增删改a,b表后进行commit操作后，我们的物化视图再经过1分钟后会进行数据的刷新。查询已经建立的物化视图语句：SELECT * FROM user_mviews WHERE mview_name = '物化视图名称';
-------------------------------------------------------------------------

中间表的方案

中间表的由来中间表是数据库中专门存放中间计算结果的数据表。报表系统中的中间表是普遍存在的。那么，这些中间表是如何出现的？为什么中间表会越来越多？中间表会给项目组带来什么样的困扰，如何解决这些困扰？这里我们就尝试探讨一下这个问题。中间表出现的典型场景主要有三个：一步算不出来。数据库中的原始数据表要经过复杂计算，才能在报表上展现出来。一个SQL很难实现这样的复杂计算。要连续多个SQL实现，前面的生成中间表给后边的SQL使用。实时计算等待时间过长。因为数据量大或者计算复杂，报表用户等待时间太长。所以要每天晚上跑批量任务，把数据计算好之后存入中间表。报表用户基于中间表查询就会快很多。多样性数据源参加计算。来自于文件、NOSQL、Webservice等的外部数据，需要与数据库内数据进行混合计算时，传统办法只能导入数据库形成中间表。中间表带来的问题在一个运营商的报表系统中，我们发现了一个让人吃惊的现象。在DB2数据仓库中，有两万多个数据库表！经过深入了解发现，真正的原始数据表只有几百张，剩下的大量的数据库表都是为查询和报表服务的中间表。经过几年乃至十几年的运行，数据库中的中间表越来越多，甚至出现这个项目中上万个的情况。大量中间表带来的直接困扰是数据库存储空间不够用，面临频繁的扩容需求。中间表对应的存储过程、触发器等等需要占用数据库的计算资源，也会造成数据库的扩容压力。那么，是不是可以清理掉一些不用的中间表？一般的结论都是：搞不动。数据库中的中间表是不同程序员制作的，有的是综合查询系统使用，有的是报表系统使用。中间表之间还存在交叉引用，有些程序员看到有别人生成的中间表就直接使用了。有时候一些查询报表已经废弃不用了，但是对应的中间表没人敢删，因为不知道删掉之后会影响其他什么查询或者报表。很多情况下，项目组只好为了越来越多的中间表去扩容数据库。但是数据库的扩容成本太昂贵了：不管是换更强的服务器（纵向扩容），还是增加数据库服务器的节点（横向扩容），都不便宜。过于频繁的扩容让项目组非常头疼。那么，能不能把中间表导出到文件中，从而减轻数据库的压力呢？这个办法初看挺好，但是有个问题始终无法解决。例如：每天晚上把经营分析表数据生成好之后放到文件中，第二天上班的时候发现，业务人员还要对经营分析表按照各种条件过滤，或者按照各种维度分组。因为文件本身是没有计算能力的，一旦把中间表从数据库中导出成文件就很难进一步计算了。不得已，只能把中间表继续留在数据库中。解决问题的办法采用润乾集算器实现文件计算，就可以把中间表从库中迁移到文件系统中了。采用集算器的前后对比图如下：在集算器结构中，数据库的大量中间表都移到了库外，数据库仅仅存储少量原始数据表，压力就小了很多。针对这些中间表实现的多个ETL存储过程、触发器、复杂SQL也都由集算器来实现，数据库的计算压力也变小了很多。虽然计算和存储压力由应用服务器来承担，但是成本还是要比数据库服务器低很多。项目组不用再每隔一段时间就申请数据库服务器扩容了。同时，集算器可以读取多样性数据源，直接参与混合计算。无需再导入数据库，成为中间表。集算器编程很容易移到库外的数据文件不能再使用SQL计算了，换成集算器会不会增加编写的难度呢？实际上，集算器编写简单计算脚本的时候和SQL差不多，复杂多步骤计算还要比SQL容易。例如：从上述例子来看，采用集算器实现数据文件库外计算，学习成本很低，很容易掌握。新方案的价值新方案的价值还不仅仅是降低数据库的压力。对于报表应用而言，中间数据的存在是有价值的：有些中间表是报表业务决定的，有些是为了弥补现有技术的不足。也就是说，中间数据和报表模板一样，都是报表系统的一部分。所以，集算器的方案并没有让中间数据消失，只是移到了库外，保存在报表应用的文件目录中，使得中间表在物理上也成为了报表应用系统的一部分。这样既能发挥中间数据的价值，还可以让中间数据和报表系统的其他部分一起管理。显然，文件系统的树形目录结构比数据库混在一起的几万个表要更容易维护。在实际项目中，可以给中间数据文件建立多层文件夹存储。例如：第一层目录是财务管理、人力资源、ERP等等。人力资源又有子目录：工资管理，基本信息，党员信息等等。目录可以细化到某个报表，如果该报表发生了变化，只需要调整这个目录中的报表模板或者数据文件即可。如果该报表废弃不用，那么删掉或者移走报表所在目录，就可以快速的释放硬盘空间。从计算速度来说，由于文件更底层，更接近于磁盘，IO性能要好于数据库。所以集算器的方案可以为报表系统带来更快的性能。报表数据来自于多样性数据源时，还可以有更好的实时性，不像传统手段时只能定期入库。----------------------------------------------------------------------------------
中间表起一种如关联的作用。比如课件和课件包，他们之间的关系是，一个课件包有多个课件。如果建了一个中间表，专门用来关联课件和课件包的。这样，当要删除一个课件的时候，只用先把这个中间表中关于这个这个课件的数据给删除，然后再在课件的表中将该课件给删除。这样整个课件就删除了。如果我是在课件包这端建立关联关系，@OneToMany。这样如果要用分页获取课件。（该课件包的课件）这个时候如果一个课件包有好多的课件，要进行分页。@OneToMany就会不合适。如果在课件端建立关联关系，@ManyToOne这样分页的问题是解决了，但是如果要删除掉该课件，但是由于，课件与课件包关联着，删除课件会报错。如果用课件与课件包中间表来解决此问题就会方便的多。删除上面说了。分页，只用将课件包的id得到就行。---------------------------------------------------------------------------------
数据库设计中，经常遇到一个决策：究竟是使用视图，还是中间表？考虑库存管理的一个场景：最普通的单据是入库和出库单，库管员需要看到当前的库存。对库存的处理，我们有两个方案：一是使用视图，所有的入库减去所有的出库，就是当前库存；另外就是使用中间表，建立一个库存表，记录当前的库存。1、使用视图的方案入库时，系统记录入库单据；出库时，系统查询库存视图，判断是否有充足的库存可以出库，然后记录出库单据；可见，系统只需要记录入库和出库单据，库存的计算是由DBMS在查询视图时进行的；2、使用库存表的方案入库时，系统记录入库单据，同时增加相应的库存；出库时，系统查询库存表，判断是否有充足的库存可以出库，然后记录出库单据，减少相应的库存；可见，系统除了记录入库和出库单据外，还需要更新库存表的当前库存数量；3、方案的比较对系统本身的设计和编码来说，视图方案易于实现，测试方便；库存表方案则稍微复杂。从这点上看，视图方案可以在原型阶段大展身手。用户体验到的性能方面，视图方案的性能压力在查询库存上，库存表方案的性能压力在业务处理上：视图方案：由于每次查询库存，DBMS都需要扫描入库和出库单据，查询时间长；还可能会对入库和出库单据加锁，导致入库和出库处理延长，甚至失败（尤其是查询库存视图在一个事务中时）；库存视图如果和其它表或者视图连接，构成复杂的SQL时，由于索引不能有效（或无法）使用，查询速度会更慢；库存表方案：库存表上可以建索引，查询速度比视图会快很多；在入库和出库时，更新库存表的SQL会对出入库处理的速度有一些影响，但是由于更新只影响出入库的SKU，与查询库存表并发时，加锁时间非常短，影响会比较小。4、结论视图方案适用情形：原型，数据量比较小；库存表方案适用情形：数据量比较大，针对库存的分析较多；
--------------------------------------------------------------------------------------
为了提高性能，对于中间表，的同步，采用初台全量同步，每天，增量同步的方案。
我介绍一下我们增量方案吧！
要增量，增量日志表是必需的，增量日志表的设计。KEY（原业务表关键字），CREATE_DATE(变更时间)，FLAG（数据修改与删除标志），USE_FLAG（增量表是否被使用的记录，（一个存储过滤使用一位））每天增量同步时，做如下操作
--如果增量日志表，所有标志位都已经使用，把增量日志表移到增量日志备份表里
INSERT LOG_MANUAL_INC_BAK
SELECT *
FROM LOG_MANUAL_INC
WHERE LEFT(USING_FLAG,4)='1111'DELETE LOG_MANUAL_INC WHERE LEFT(USING_FLAG,4)='1111'--建临时中间表，方便同步(字段内容与真实表一样)
CREATE TABLE #TG_ENTRY ([TE_ENTRY_ID] [char] (18)   NOT NULL
..)
GO---------------------将未整合记录从中间表中删除
--SUBSTRING(USING_FLAG,2,1)为这次整合使用的标记位DELETE FROM TG_ENTRY WHERE TG_ENTRY_ID IN (SELECT TG_ENTRY_ID FROM LOG_MANUAL_INC WHERE SUBSTRING(USING_FLAG,2,1)<>1)。。下面就可以做同步数据了，
。。。同步数据是从原业务表里取，不过，数据范围限定在，增量表里的没有做增量操作(并且操作类型为新加与修改的)的数据也就同步多加一个WHERE条件，
WHERE LOG_MANUAL_INC.ARJ_MARK='M' and SUBSTRING(USING_FLAG,2,1)<>1
取好的数据是放在新建的临时中间表，#TG_ENTRY做好了同步操作，不要忘了更新增量表的标志。
---------------------

oracle 物化视图、中间表的方案相关推荐

oracle物化视图和表的区别,数据库中普通视图和物化视图有什么区别？
对于增量刷新选项,如果在子查询中存在分析函数,则物化视图不起作用. Refresh方法- COMPLETE子句完全刷新重新生成整个视图,如果请求完全刷新,oracle会完成完全刷新即使增量刷新可用 ...
oracle 物化视图 ORA-23413: 表 xxx.xx 不带实体化视图日志
DROP materialized view log on TAB_NAME ; --不是view名,是表名 CREATE MATERIALIZED VIEW LOG ON TAB_NAME W ...
Oracle物化视图优化多表查询速度
近期项目中遇到有关报表查询sql速度过慢的问题,由于sql是多个表相关联的查询结果,并且数据量过大,所以导致查询速度过慢.为此,采用物化视图来提高查询速度. 1.物化视图概述物化视图是包括一个查询结 ...
oracle 物化视图－－转
Oracle的物化视图提供了强大的功能,可以用在不同的环境中.在不同的环境中,物化视图的作用也不相同. 数据仓库中的物化视图主要用于预先计算并保存表连接或聚集等耗时较多的操作的结果,这样,在执行查询 ...
oracle技术之Oracle 物化视图（一）
一. 理论部分 Oracle的物化视图是包括一个查询结果的数据库对像,它是远程数据的的本地副本,或者用来生成基于数据表求和的汇总表.物化视图存储基于远程表的数据,也可以称为快照. Oracle的物化视 ...
Oracle物化视图的创建及使用（一
Oracle物化视图的创建及使用 http://blog.csdn.net/tegwy/article/details/8935058 先看简单创建语句: create materialize ...
Oracle物化视图的简单使用
最近有个项目因为有比较多的查询汇总,之前用的是oralce的临时表,但临时表的特性导致无法完成业务需求,所以使用了物化视图. 先看简单创建语句: //创建物化视图 create materialize ...
Oracle物化视图和普通视图区别
一.物化视图的简介物化视图是一种特殊的物理表,"物化"(Materialized)视图是相对普通视图而言的.普通视图是虚拟表,应用的局限性大,任何对视图的查询,Oracle都实际 ...
Oracle物化视图与物化视图日志
文章目录物化视图物化视图与普通视图的区别创建一个存放person的表创建一个存放person的address的表初始化数据创建物化视图的语句 1.build [immediate|defe ...

oracle 物化视图、中间表的方案

oracle 物化视图、中间表的方案相关推荐

最新文章

热门文章