Updatable Materialized View and Master Table on same database

Hi all,
My first question - Is it possible to have an Updatable Materialized View and the associated Master Table located on the same database?
This is the requirement scenario:
One unique database D exists.
A is a batch table. Only inserts are allowed on Table A.
M is an updatable materialized view on Table A (Master). Only updates are allowed on M (no insert or delete).
Requirement is to push updates/changes from M to A periodically and then get the new inserted records from A into M via a refresh.
Is this possible? What other approaches are applicable here?

John,
My question is related to the implementation and setup of the environment as explained in the above example. How can I achieve this considering that I have created an updatable m-view?
If possible, how do I push changes made to an updatable m-view back to it's master table when/before I execute DBMS_MVIEW.REFRESH on the m-view? What is the procedure to do this if both table and mview exist on the same database? Do I need to create master groups, materialized view refresh groups, etc.?
One more thing.. Is there a way to retain changes to the m-view during refresh? In this case, only newly inserted/updated records in the associated table would get inserted into m-view. Whereas changes made to m-view records would stay as-is.
Hope my question is directed well. Thanks for your help.
- Ankit

Similar Messages

Query performance on materialized view vs master tables

Hi,
I am afraid of strange behavior in db, on my master tables UDBMOVEMENT_ORIG(26mil.rows) and UDBIDENTDATA_ORIG(18mil.rows) is created materialized view TMP_MS_UDB_MV (UDBMOVEMENT is synonym to this object) which meets some default conditions and join condition on these master tables. MV got about 12milions rows. I created MV to query not so huge objects, MV got 3GB, master tables toghether 12GB. But I don't understand that even physical reads and consistent gets are less on MV than on master tables, the final execution time is shorter on master tables. See my log below.
Why?
Thanks for answers.
SQL> set echo on
SQL> @flush
SQL> alter system flush buffer_cache;
System altered.
Elapsed: 00:00:00.20
SQL> alter system flush shared_pool;
System altered.
Elapsed: 00:00:00.65
SQL> SELECT
2 UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBIdentData.sCardSubType, UDBIdentData.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBIdentData.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBIdentData.tTarifTimeStart, UDBIdentData.tTarifTimeEnd, UDBIdentData.cLicensePlate, UDBIdentData.lMoneyValue, UDBIdentData.lPointValue, UDBIdentData.lTimeValue, UDBIdentData.tProdTime, UDBIdentData.tExpireDate
3 FROM UDBMOVEMENT_orig UDBMovement, Udbidentdata_orig UDBIdentData
4 WHERE
5 UDBMovement.lGlobalId = UDBIdentData.lGlobalRef(+) AND UDBMovement.sComputer = UDBIdentData.sComputer(+)
6 AND UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBIdentData.sCardType IN (2) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
7 AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25 AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
8 ORDER BY tActionTime, lBlock, lSequenz;
4947 rows selected.
Elapsed: 00:00:15.84
Execution Plan
Plan hash value: 1768406139
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 7166 | 1238K| | 20670 (1)| 00:04:09 |
| 1 | SORT ORDER BY | | 7166 | 1238K| 1480K| 20670 (1)| 00:04:09 |
| 2 | NESTED LOOPS | | | | | | |
| 3 | NESTED LOOPS | | 7166 | 1238K| | 20388 (1)| 00:04:05 |
|* 4 | TABLE ACCESS BY INDEX ROWID| UDBMOVEMENT_ORIG | 7142 | 809K| | 7056 (1)| 00:01:25 |
|* 5 | INDEX RANGE SCAN | IDX_UDBMOVARTICLE | 10709 | | | 61 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | UDBIDENTDATA_PRIM | 1 | | | 1 (0)| 00:00:01 |
|* 7 | TABLE ACCESS BY INDEX ROWID | UDBIDENTDATA_ORIG | 1 | 61 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("UDBMOVEMENT"."STRANSTYPE">0 AND "UDBMOVEMENT"."SDEVICE"<1000 AND
BITAND("SSALEFLAG",1)=0 AND "UDBMOVEMENT"."SDEVICE">=0 AND BITAND("UDBMOVEMENT"."SSALEFLAG",4)=0)
5 - access("UDBMOVEMENT"."TACTIONTIME">=TO_DATE(' 2011-05-05 06:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "UDBMOVEMENT"."TACTIONTIME"<TO_DATE(' 2011-05-05 12:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "UDBMOVEMENT"."SARTCLASSREF"<100)
filter("UDBMOVEMENT"."SARTCLASSREF"<100)
6 - access("UDBMOVEMENT"."LGLOBALID"="UDBIDENTDATA"."LGLOBALREF" AND
"UDBMOVEMENT"."SCOMPUTER"="UDBIDENTDATA"."SCOMPUTER")
7 - filter("UDBIDENTDATA"."SCARDTYPE"=2)
Statistics
543 recursive calls
0 db block gets
84383 consistent gets
4485 physical reads
0 redo size
533990 bytes sent via SQL*Net to client
3953 bytes received via SQL*Net from client
331 SQL*Net roundtrips to/from client
86 sorts (memory)
0 sorts (disk)
4947 rows processed
SQL> @flush
SQL> alter system flush buffer_cache;
System altered.
Elapsed: 00:00:00.12
SQL> alter system flush shared_pool;
System altered.
Elapsed: 00:00:00.74
SQL> SELECT UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBMovement.sCardSubType, UDBMovement.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBMovement.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBMovement.tTarifTimeStart, UDBMovement.tTarifTimeEnd, UDBMovement.cLicensePlate, UDBMovement.lMoneyValue, UDBMovement.lPointValue, UDBMovement.lTimeValue, UDBMovement.tProdTime
2 FROM UDBMOVEMENT WHERE
3 UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBMovement.sCardType IN (2) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
4 AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
5 AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5 ORDER BY tActionTime, lBlock, lSequenz;
4947 rows selected.
Elapsed: 00:00:26.46
Execution Plan
Plan hash value: 3648898312
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2720 | 443K| 2812 (1)| 00:00:34 |
| 1 | SORT ORDER BY | | 2720 | 443K| 2812 (1)| 00:00:34 |
|* 2 | MAT_VIEW ACCESS BY INDEX ROWID| TMP_MS_UDB_MV | 2720 | 443K| 2811 (1)| 00:00:34 |
|* 3 | INDEX RANGE SCAN | EEETMP_MS_ACTTIMEDEVICE | 2732 | | 89 (0)| 00:00:02 |
Predicate Information (identified by operation id):
2 - filter("UDBMOVEMENT"."STRANSTYPE">0 AND BITAND("UDBMOVEMENT"."SSALEFLAG",4)=0 AND
BITAND("SSALEFLAG",1)=0 AND "UDBMOVEMENT"."SARTCLASSREF"<100)
3 - access("UDBMOVEMENT"."TACTIONTIME">=TO_DATE(' 2011-05-05 06:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "UDBMOVEMENT"."SDEVICE">=0 AND "UDBMOVEMENT"."SCARDTYPE"=2 AND
"UDBMOVEMENT"."TACTIONTIME"<TO_DATE(' 2011-05-05 12:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"UDBMOVEMENT"."SDEVICE"<1000)
filter("UDBMOVEMENT"."SCARDTYPE"=2 AND "UDBMOVEMENT"."SDEVICE"<1000 AND
"UDBMOVEMENT"."SDEVICE">=0)
Statistics
449 recursive calls
0 db block gets
6090 consistent gets
2837 physical reads
0 redo size
531987 bytes sent via SQL*Net to client
3953 bytes received via SQL*Net from client
331 SQL*Net roundtrips to/from client
168 sorts (memory)
0 sorts (disk)
4947 rows processed
SQL> spool off
Edited by: MattSk on Feb 4, 2013 2:20 PM

I have added some tkprof outputs on MV and master tables:
SELECT tmp_ms_udb_mv.zIdDevice, tmp_ms_udb_mv.sDevice, tmp_ms_udb_mv.zIdLocal, tmp_ms_udb_mv.sComputer, tmp_ms_udb_mv.tActionTime, tmp_ms_udb_mv.sCardSubType, tmp_ms_udb_mv.sCardType, tmp_ms_udb_mv.cEpan, tmp_ms_udb_mv.cText, tmp_ms_udb_mv.lArtRef, tmp_ms_udb_mv.sArtClassRef, tmp_ms_udb_mv.lSequenz, tmp_ms_udb_mv.sTransMark, tmp_ms_udb_mv.lBlock, tmp_ms_udb_mv.sTransType, tmp_ms_udb_mv.lGlobalID, tmp_ms_udb_mv.sFacility, tmp_ms_udb_mv.sCardClass, tmp_ms_udb_mv.lSingleAmount, tmp_ms_udb_mv.sVAT, tmp_ms_udb_mv.lVATTot, tmp_ms_udb_mv.tTarifTimeStart, tmp_ms_udb_mv.tTarifTimeEnd, tmp_ms_udb_mv.cLicensePlate, tmp_ms_udb_mv.lMoneyValue, tmp_ms_udb_mv.lPointValue, tmp_ms_udb_mv.lTimeValue, tmp_ms_udb_mv.tProdTime
FROM tmp_ms_udb_mv WHERE
tmp_ms_udb_mv.sTransType > 0 AND tmp_ms_udb_mv.sDevice < 1000 AND tmp_ms_udb_mv.sDevice>= 0 AND tmp_ms_udb_mv.sCardType IN (1) AND (bitand(tmp_ms_udb_mv.sSaleFlag,1) = 0 AND bitand(tmp_ms_udb_mv.sSaleFlag,4) = 0) AND tmp_ms_udb_mv.sArtClassRef < 100
AND tmp_ms_udb_mv.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
AND tmp_ms_udb_mv.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
ORDER BY tActionTime, lBlock, lSequenz
call count cpu elapsed disk query current rows
Parse 1 0.04 0.10 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 596 0.17 27.07 2874 8894 0 8925
total 598 0.21 27.18 2874 8894 0 8925
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 60
Rows Row Source Operation
8925 SORT ORDER BY (cr=8894 pr=2874 pw=0 time=27071773 us)
8925 MAT_VIEW ACCESS BY INDEX ROWID TMP_MS_UDB_MV (cr=8894 pr=2874 pw=0 time=31458291 us)
8925 INDEX RANGE SCAN EEETMP_MS_ACTTIMEDEVICE (cr=68 pr=68 pw=0 time=161347 us)(object id 149251)
SELECT
UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBIdentData.sCardSubType, UDBIdentData.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBIdentData.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBIdentData.tTarifTimeStart, UDBIdentData.tTarifTimeEnd, UDBIdentData.cLicensePlate, UDBIdentData.lMoneyValue, UDBIdentData.lPointValue, UDBIdentData.lTimeValue, UDBIdentData.tProdTime, UDBIdentData.tExpireDate
FROM UDBMOVEMENT_orig UDBMovement, Udbidentdata_orig UDBIdentData
WHERE
UDBMovement.lGlobalId = UDBIdentData.lGlobalRef(+) AND UDBMovement.sComputer = UDBIdentData.sComputer(+)
AND UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBIdentData.sCardType IN (1) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
ORDER BY tActionTime, lBlock, lSequenz
call count cpu elapsed disk query current rows
Parse 1 0.03 0.06 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 596 0.76 16.94 3278 85529 0 8925
total 598 0.79 17.01 3278 85529 0 8925
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 60
Rows Row Source Operation
8925 SORT ORDER BY (cr=85529 pr=3278 pw=0 time=16942799 us)
8925 NESTED LOOPS (cr=85529 pr=3278 pw=0 time=15017857 us)
22567 TABLE ACCESS BY INDEX ROWID UDBMOVEMENT_ORIG (cr=17826 pr=1659 pw=0 time=7273473 us)
22570 INDEX RANGE SCAN IDX_UDBMOVARTICLE (cr=111 pr=111 pw=0 time=112351 us)(object id 143693)
8925 TABLE ACCESS BY INDEX ROWID UDBIDENTDATA_ORIG (cr=67703 pr=1619 pw=0 time=8154915 us)
22567 INDEX UNIQUE SCAN UDBIDENTDATA_PRIM (cr=45136 pr=841 pw=0 time=3731470 us)(object id 108324)

Difference between materailized view and a table

hey hiii
i want to know what is a difference between a materialized view and a table i.e suppose i create a table A and another table B on table A i have created a trigger which will upload all the changes made in A ie insert,update or delete so whether this will perform all the action that a materialized view can perform on A or is there any difference between them
thks

I'll add to Nicolas' answer that the MV maintenance does have access to mechsnisms other than row-by-row replication of the trigger-based type. Direct path inserts to the base table are very efficiently propagated to the MV, as are partition-based DDL operations. Also MV's come with optional query rewrite built in (you need 10g+ to query rewrite to a non-MV data set), and scheduled refresh so you can defer maintenance of the data set until later.
MV maintenance can be less efficient though -- you may know something about the data and the way that it changes that allows you to write more efficient meintenance than the MV code.

Questions on Materialized Views and MV Log tables

Hello all,
Have a few questions with regards to Materialized View.
1) Once the Materialized View reads the records from the MLOG table the MLOG's records get purged. correct? or is it not the case? In some cases I still see (old) records in the MLOG table even after the MV refresh.
2) How does the MLOG table distinguish between a read that comes from an MV and a read that comes from a user? If I manually execute
"select * from <MLOG table>" would the MLOG table's record get purged just the same way as it does after an MV refresh?
3) One of our MV refreshes hangs intermittently. Based on the wait events I noticed that it was doing a "db file sequential read" against the master table. Finally I had to terminate the refresh. I'm not sure why it was doing sequential read on the master table when it should be reading from the MLOG table. Any ideas?
4) I've seen "db file scattered read" (full table scan) in general against tables but I was surprised to see "db file sequential read" against the table. I thought sequential read normally happens against indexes. Has anyone noticed this behaviour?
Thanks for your time.

1) Once all registered materialized views have read a particular row from a materialized view log, it is removed, yes. If there are multiple materialized views that depend on the same log, they would all need to refresh before it would be safe to remove the MV log entry. If one of the materialized views does a non-incremental refresh, there may be cases where the log doesn't get purged automatically.
2) No, your query wouldn't cause anything to be purged (though you wouldn't see anything interesting unless you happen to implement lots of code to parse the change vectors stored in the log). I don't know that the exact mechanism that Oracle uses has been published, though you could go through and trace a session to get an idea of the moving pieces. From a practical standpoint, you just need to know that when you create a fast-refreshable materialized view, it's going to register itself as being interested in particular MV logs.
3) It would depend on what is stored in the MV log. The refresh process may need to grab particular columns from the table if your log is just storing the fact that data for a particular key changed. You can specify when you create a materialized view log that you want to store particular columns or to include new values (with the INCLUDING NEW VALUES) clause. That may be beneficial (or necessary) to the fast refresh process but it would tend to increase the storage space for the materialized view log and to increase the cost of maintianing the materialized view log.
4) Sequential reads against a table are perfectly normal-- it just implies that someone is looking at a particular block in the table (i.e. looking up a row in the table by ROWID based on the ROWID in an index or in a materialized view log).
Justin

Issue with materialized view and fast refresh between Oracle 10g and 11g

Hi all,
I've hit a problem when trying to create a fast-refreshable materialized view.
I've got two databases, one 10.2.0.10, another 11.2.0.1.0, running on 32-bit Windows. Both are enterprise edition, and I'm trying to pull data from the 10g one into the 11g one. I can happily query across the database link from 11g to 10g, and can use complete refresh with no problem except the time it takes.
On the 10g side, I've got tables with primary keys and m.v. logs created, the logs being of this form ...
CREATE MATERIALIZED VIEW LOG ON table WITH PRIMARY KEY INCLUDING NEW VALUES
On the 11g side, when I try to create an m.v. against that ...
CREATE MATERIALIZED VIEW mv_table REFRESH FAST WITH PRIMARY KEY AS SELECT col1, col2 FROM table@dblink;
... I get an ORA-12028 error (materialized view type is not supported by master site).
After running the EXPLAIN_MVIEW procedure it shows this;
REFRESH_FAST_AFTER_INSERT not supported for this type mv by Oracle version at master site
A colleague has managed to build a fast-refresh m.v. from the same source database, but pulling to a different one than I'm using; his target is also 10g, like the (common) source, so I've no idea why I'm getting the 'not supported' message whilst he isn't.
I've been able, on previous projects, to do exactly what I'm trying to achieve but on those someone with more knowledge than me has configured the database!
I'm now stumped. I'm also no DBA but despite that it's been left to me to install the new 11g database on the 32-bit Windows server from scratch, so there are probably a couple of things I'm missing. It's probably something really obvious but I don't really know where to look now.
If anyone can give me any pointers at all, I'd be really grateful. This question is also duplicated in the Replication forum but hasn't had any replies as yet, so I'm reproducing it here in hope!
Thanks in advance,
Steve

Hi Steve,
You should have a look at metalink, Doc ID 1059547.1
If that does not help, there may be something else in Mater note ID 1353040.1
Best regards
Peter

Materialized views on prebuilt tables - query rewrite

Hi Everyone,
I am currently counting on implementing the query rewrite functionality via materialized views to leverage existing aggregated tables.
Goal*: to use aggregate-awareness for our queries
How*: by creating views on existing aggregates loaded via ETL (+CREATE MATERIALIZED VIEW xxx on ON PREBUILT TABLE ENABLE QUERY REWRITE+)
Advantage*: leverage oracle functionalities + render logical model simpler (no aggregates)
Disadvantage*: existing ETL's need to be written as SQL in view creation statement --> aggregation rule exists twice (once on db, once in ETL)
Issue*: Certain ETL's are quite complex via lookups, functions, ... --> might create overy complex SQLs in view creation statements
My question: is there a way around the issue described? (I'm assuming the SQL in the view creation is necessary for oracle to know when an aggregate can be used)
Best practices & shared experiences are welcome as well of course
Kind regards,
Peter

streefpo wrote:
I'm still in the process of testing, but the drops should not be necessary.
Remember: The materialized view is nothing but a definition - the table itself continues to exist as before.
So as long as the definition doesn't change (added column, changed calculation, ...), the materialized view doesn't need to be re-created. (as the data is not maintained by Oracle)Thanks for reminding me but if you find a documented approach I will be waiting because this was the basis of my argument from the beginning.
SQL> select * from v$version ;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> desc employees
Name                                                                                            Null?    Type
EMPLOYEE_ID                                                                                     NOT NULL NUMBER(6)
FIRST_NAME                                                                                               VARCHAR2(20)
LAST_NAME                                                                                       NOT NULL VARCHAR2(25)
EMAIL                                                                                           NOT NULL VARCHAR2(25)
PHONE_NUMBER                                                                                             VARCHAR2(20)
HIRE_DATE                                                                                       NOT NULL DATE
JOB_ID                                                                                          NOT NULL VARCHAR2(10)
SALARY                                                                                                   NUMBER(8,2)
COMMISSION_PCT                                                                                           NUMBER(2,2)
MANAGER_ID                                                                                               NUMBER(6)
DEPARTMENT_ID                                                                                            NUMBER(4)
SQL> select count(*) from employees ;
COUNT(*)
       107
SQL> create table mv_table nologging as select department_id, sum(salary) as totalsal from employees group by department_id ;
Table created.
SQL> desc mv_table
Name                                                                                            Null?    Type
DEPARTMENT_ID                                                                                            NUMBER(4)
TOTALSAL                                                                                                 NUMBER
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> create materialized view mv_table on prebuilt table with reduced precision enable query rewrite as select department_id, sum(salary) as totalsal from employees group by department_id ;
Materialized view created.
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> select object_name, object_type from user_objects where object_name = 'MV_TABLE' ;
OBJECT_NAME                                                                                                                      OBJECT_TYPE
MV_TABLE                                                                                                                         TABLE
MV_TABLE                                                                                                                         MATERIALIZED VIEW
SQL> insert into mv_table values (999, 100) ;
insert into mv_table values (999, 100)
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> update mv_table set totalsal = totalsal * 1.1 where department_id = 10 ;
update mv_table set totalsal = totalsal * 1.1 where department_id = 10
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> delete from mv_table where totalsal <= 10000 ;
delete from mv_table where totalsal <= 10000
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view While investigating for this thread I actually made my own question redundant as the answer became gradually clear:
When using complex ETL's, I just need to make sure the complexity is located in the ETL loading the detailed table, not the aggregate
I'll try to clarify through an example:
- A detailed Table DET_SALES exists with Sales per Day, Store & Product
- An aggregated table AGG_SALES_MM exists with Sales, SalesStore per Month, Store & Product
- An ETL exists to load AGG_SALES_MM where Sales = SUM(Sales) & SalesStore = (SUM(Sales) Across Store)
--> i.e. the SalesStore measure will be derived out of a lookup
- A (Prebuilt) Materialized View will exist with the same column definitions as the ETL
--> to allow query-rewrite to know when to access the table
My concern was how to include the SalesStore in the materialized view definition (--> complex SQL!)
--> I should actually include SalesStore in the DET_SALES table, thus:
- including the 'Across Store' function in the detailed ETL
- rendering my Aggregation ETL into a simple GROUP BY
- rendering my materialized view definition into a simple GROUP BY as wellNot sure how close your example is to your actual problem. Also don't know if you are doing an incremental/complete data load and the data volume.
But the "SalesStore = (SUM(Sales) Across Store)" can be derived from the aggregated MV using analytical function. One can just create a normal view on top of MV for querying. It is hard to believe that aggregating in detail table during ETL load is the best approach but what do I know?

MATERIALIZED view on two tables with Fast Refresh

i Wanted to create MV on two tables with Fast refresh on commit.
I followed below steps
create materialized view log on t1 WITH PRIMARY KEY, rowid;
create materialized view log on t2 WITH PRIMARY KEY, rowid;
CREATE MATERIALIZED VIEW ETL_ENTITY_DIVISION_ASSO_MV
REFRESH fast ON commit
ENABLE QUERY REWRITE
AS
select A.ROWID B.ROWID,a.c1, DECODE(a.c1,'aaa','xxx','aaa') c2
from t1 A
join t2 b
on AB.c1= CD.c2;
i am getting below error.
Error report:
SQL Error: ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
12054. 00000 - "cannot set the ON COMMIT refresh attribute for the materialized view"
*Cause: The materialized view did not satisfy conditions for refresh at
commit time.
*Action: Specify only valid options.
Basically i want to take record in MV by joinig two tables and if both of the base tables will updated then record should reflect in materialised view.
Please do the needfull.

does the table support PCT? the other restrictions on joins look to be ok in your statement.
maybe try creating first with on demand instead of commit to see does it create.
http://docs.oracle.com/cd/B19306_01/server.102/b14223/basicmv.htm
>
Materialized Views Containing Only Joins
Some materialized views contain only joins and no aggregates, such as in Example 8-4, where a materialized view is created that joins the sales table to the times and customers tables. The advantage of creating this type of materialized view is that expensive joins will be precalculated.
Fast refresh for a materialized view containing only joins is possible after any type of DML to the base tables (direct-path or conventional INSERT, UPDATE, or DELETE).
A materialized view containing only joins can be defined to be refreshed ON COMMIT or ON DEMAND. If it is ON COMMIT, the refresh is performed at commit time of the transaction that does DML on the materialized view's detail table.
If you specify REFRESH FAST, Oracle performs further verification of the query definition to ensure that fast refresh can be performed if any of the detail tables change. These additional checks are:
A materialized view log must be present for each detail table unless the table supports PCT. Also, when a materialized view log is required, the ROWID column must be present in each materialized view log.
The rowids of all the detail tables must appear in the SELECT list of the materialized view query definition.
If some of these restrictions are not met, you can create the materialized view as REFRESH FORCE to take advantage of fast refresh when it is possible. If one of the tables did not meet all of the criteria, but the other tables did, the materialized view would still be fast refreshable with respect to the other tables for which all the criteria are met.

Advantage of Materialized view on prebuilt table

Could someone tell me the advantage of Materialized view on prebuilt table?. I'm unable to understand the concept from the Oracle documentation. I need to know the answers for following questions.
1) Is the data stored in table and MV same?. Does the query retrive data from table or MV?. The query internally uses either table or a view as the names of both are same.
2) Our DSS application is generating complicated queries and executing for long time. Is there any way I can optimize those queries using MV without rewriting the code in the application.

It's a roughly analgous problem to figuring out what set of indexes to create to improve the performance of an application-- you need to understand the various queries, how the application is accessing data, and you need to balance a variety of competing needs in order to come up with a reasonable set of indexes.
Fundamentally, Oracle can only use a materialized view to satisfy a query if a human could use just the data in the materialized view to answer the question. That generally means that the materialized view is going to have to be aggregated at a lower level or at the same level as the query. A materialized view that aggregates sales by day can be used for queries by year but a materialized view that aggregates sales by year cannot be used for queries that get sales by day. A materiailized view that aggregates sales by vendor and product can be used for queries that aggregate by vendor or by product, but a materialized view that aggregates by product cannot be used in a query that aggregates by product for a particular vendor.
You'll have to balance what materialized views are ideal for a particular query, what materialized views are sufficient for a particular set of queries, and how to balance the space, managability, and refresh performance requirements between creating lots of somewhat redundant materialized views that provide optimal query performance at the cost of a lot of disk and a large refresh window vs creating fewer, more general materialized views that consume less disk and can be refreshed faster but that provide less query performance boosts.
Justin

Materialized view from prebuilt table doesn't work with spatial types?

Hello, I'm trying to build a materialized view of a table using the prebuilt option and a pre-built table.
Oracle gives me an ORA-32304 error, saying it can't do this with user-defined types. The original table has no user-defined types, but does use an sdo_geometry column. Is this what it's complaining about?
Now I can sort of understand this, but here's my real problem: the materialized view I'm creating is comprised of a subset of the columns from the original table, but not the geometry column. Is Oracle right in refusing my prebuilt request? Does anyone know of a way around this (besides creating the MV from scratch without prebuilt).
I've successfully created an MV on another table, which doesn't have a spatial column, using the prebuilt option and a subset of columns.
(I'm using Oracle 11.2.0.2.0 on both master and slave databases)

Good news, everyone! =)
SAPwebIDE team fixed this issue with MMD template in SAPwebIDE v1.10.2. available on http://hanatrial.ondemand.com.
This "Bug" or "Feature" was presented in 1.8.x and 1.9.x SAPwebIDE (i've used local installation) and now it's gone in v1.10.2. Thank you, SAPwebIDE Team! =)
The difference between versions of MMD template is only in one file (fixed one is on the right):
Master2.controller.js
And here it is:
Now, only one question remains: HOWTO:SAPUI5 Fiori-like report. (mix control's value as key into binding context)
Best regards, ilia.

Materialized view and Partition

Hi,
I want to discuss a scenario, with which i am dealing nowadays. there is only a single table (named livecdr ) has 22-23 fields and the records are updating in every sec (on daily basis) and in 24hrs livecdr contains approximately more than 2 crore records.
Problem is that the query processing time is so slow due to large number of records and query is fetching records from a view created on livecdr table. I want to know the options, how the query would fetch these records in a short time. Firstly i did range partitioning on livecdr and then i created materlized view but the view didn't create on partition table and when i removed partitioning it was created. After view creation, query performance is much better. i also applied indexing on livecdr.
Can you please tell me, whether this approach is okay or i am doing mistake. should i create partitioning on materialized view and how would i select records from view if partitioning would be applied on materialized view. Please guide me with best approaches.
thankyou.

Hello,
Here is how I created partitioned table (monthly partitions) and partitioned mview on the table. This is just an example you might have to change the mview partitions from monhtly to yearly or quartely.
CREATE TABLE live_cdr
   CALLID              VARCHAR2 (20),
   CD                  VARCHAR2 (25),
   CG                  VARCHAR2 (25),
   RE                  VARCHAR2 (25),
   OPC                 VARCHAR2 (12),
   DPC                 VARCHAR2 (12),
   STIME               VARCHAR2 (25),
   SDATE               DATE,
   ATIME               VARCHAR2 (25),
   ADATE               DATE,
   ETIME               VARCHAR2 (25),
   EDATE               DATE,
   schangeTime         VARCHAR2 (25),
   schangeDate         DATE,
   STATUS              VARCHAR2 (25),
   bucket              NUMBER (20),
   CIC                 NUMBER (20),
   charge              VARCHAR2 (30),
   ported              VARCHAR2 (30),
   jurisdiction_Info   VARCHAR2 (30),
   origLine_Info       CHAR (1),
   Variant             NUMBER,
   auto_inc            NUMBER
PARTITION BY RANGE (EDATE)
PARTITION LIVE_CDR_JAN_2009 VALUES LESS THAN (TO_DATE(' 2009-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS,
PARTITION LIVE_CDR_FEB_2009 VALUES LESS THAN (TO_DATE(' 2009-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
);Mview definition
CREATE MATERIALIZED VIEW KLONDIKE.LIVE_CDR_MV
LOGGING
PARTITION BY RANGE (EDATE)
PARTITION LIVE_CDR_MV_JAN_2009 VALUES LESS THAN (TO_DATE('20090201',
      'YYYYMMDD'))
    LOGGING
    NOCOMPRESS,
PARTITION LIVE_CDR_MV_FEB_2009 VALUES LESS THAN (TO_DATE('20090301',
      'YYYYMMDD'))
    LOGGING
    NOCOMPRESS
BUILD IMMEDIATE
REFRESH COMPLETE
START WITH SYSDATE
NEXT SYSDATE + 2 /24
AS
SELECT   DISTINCT (ic.callid) callid,
                  ic.CG,
                  ic.CD,
                  ic.RE,
                  ic.OPC,
                  ic.DPC,
                  ic.SDATE,
                  ic.STIME,
                  ac.ADATE,
                  ac.ATIME,
                  ec.ETIME,
                  ec.EDATE,
                  ec.STATUS
FROM   live_cdr ic, live_cdr ac, live_cdr ec
WHERE       ic.callid = ac.callid
         AND ic.callid = ec.callid
         AND ic.stime = ac.stime
         AND ic.stime = ec.stime
         AND ic.sdate = ac.sdate
         AND ic.sdate = ec.sdate
         AND ac.ADATE IS NOT NULL
         AND ec.EDATe IS NOT NULL
         AND ec.etime IS NOT NULL
         AND ic.CD IS NOT NULL
         AND ic.cg IS NOT NULL;Regards

Scheduling updatable materialized view

Hi everybody,
As you may know I have a solution in which I have 5 sites .One master site with 4 updatable materialized view sites.
I want to know that is it correct if I dont set up schedule push to run periodically and set it up to do continuous push ?
I want in at least 2 minutes all sites become update and I have to mention that at first I tried multimaster but our client doesn't want that because they want if one special site becomes unavailable they others can not transfer data to eachother.
I appreciate your help in advance.

Your requirements are a bit unclear...
1) In general, if you are looking to have sites updated within a minute or two of the original transaction being committed, you are better off looking at something like Streams rather than using materialized views.
2) Architecturally, when you set up multi-master replication (which it sounds like you are attempting to do here), you need to choose between synchronous and asynchronous replication. Synchronous replication means that a transaction cannot commit until it has been pushed to all the other nodes, which is great for latency but horrible for performance, scalability, and availability. Very, very few people really want synchronous replication. That leaves asynchronous replication, which would require you to schedule jobs to replicate changes. Some folks who think they want asnychronous replication really want another technology entirely (i.e. DataGuard, RAC, etc).
3) Are you sure about the requirement "they want if one special site becomes unavailable they others can not transfer data to each other"? That says that if one site fails, they want all transactions everywhere to fail. That pretty much defeats the purpose of setting up multi-master replication. If the system is only available as long as every node is available, and you're going to incur the overhead of synchronous replication on every change, you would be far better served consolidating everything into a single data center and potentially using RAC to create a multi-node cluster to spread the work among nodes. There would be very little benefit to offset the complexity of configuring and maintaining a multi-master replication environment if you didn't want the nodes to be able to continue in the event that one of them failed.
Justin

Updatable materialized view- error with CREATE_SNAPSHOT_REPGROUP

I'm trying to create an updatable materialized view from the replication administrators account (REPADMIN). I use the assistant and in the third step (after creating the replication group and the materialized view), when the materialized view is going to be added to the group, I got this error:
ERROR in line 1:
ORA-01403: No data found
ORA-06512: in "SYS.DBMS_REPCAT_SNA_UTL", line 5927
ORA-06512: in "SYS.DBMS_REPCAT_SNA", line 82
ORA-06512: in "SYS.DBMS_REPCAT", line 1332
ORA-06512: in "SYS.DBMS_REPCAT", line 1307
ORA-06512: in line 2
I have also tried to use the command file that the assistant generates (I add below), and the error is triggered within the CREATE_SNAPSHOT_REPOBJECT procedure.
Has anybody any idea to resolve the problem?
Thanks in advance
BEGIN
DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP(
gname => '"MYGROUP"',
master => 'DB.DOMAIN.COM',
propagation_mode => 'ASYNCHRONOUS');
END;
CREATE SNAPSHOT "MYUSER"."MYTABLE"
REFRESH COMPLETE WITH ROWID
FOR UPDATE
AS SELECT "COD", "NAME" FROM
"MYUSER"."MYTABLE"@DB.DOMAIN.COM c
BEGIN
DBMS_REFRESH.ADD(
name => '"MYUSER"."REF3"',
list => '"MYUSER"."MYTABLE"',
lax => TRUE);
END;
BEGIN
DBMS_REPCAT.CREATE_SNAPSHOT_REPOBJECT(
gname => '"MYGROUP"',
sname => '"MYUSER"',
oname => '"MYTABLE"',
type => 'SNAPSHOT',
min_communication => FALSE);
END;

Hello,
These days I have had some problems with my forum-account and I haven't been able to connect and reply.
Regarding to your doubt, the name of refresh group was correct, and as I see, the problem can't be related to the refresh group.
While the problem with my account was resolved, I created two new databases (*) and the problem within the materialized view process is disappeared. I suppose that my first original databases were degraded, but I don't know where.
(*) of course, I could do that because I use Oracle in an academy institution, not for production, thank God
Anyway, for now I will give up here. Thanks for your help.
Regards,

Updatable materialized views.

Hi ,
I am using sqlplus.
Please can anyone share a simple example to update a base table using a updatable materialized view.
Thanks

usera :- Contains the base table tab1.
userb:- Contains the materialized view
materialized view create query in userb:-
CREATE MATERIALIZED VIEW MV_UPDATETAB1
REFRESH on demand
FOR UPDATE
AS
SELECT * FROM USERA.TAB1
MView created.
Tab1 has 4 rows existing.
I added one more row to the mview.
select * from mview shows 5 rows. (base table 4 rows)
Then I refreshed the mview :-
exec DBMS_MVIEW.REFRESH('mv_updatetab1','c')
successfully executed.
Base table still has 4 rows.
The mview alos has 4 rows and the newly added is not present in the table and mview either.
Any thoughts and suggestions

Oracle Streams vs. Updatable Materialized View

Does anyone have an idea in which cases Oracle Streams is better than Updatable MV or visa verse?

Are you really talking about Updatable Materialized Views? Or multi-master replication? Personally, I'm rather hard-pressed to come up with a situation where updatable materialized views would be useful unless you're taking the next step and doing multi-master replication.
In general, Streams is going to put less load on the source system than materialized views and is going to replicate data more quickly. The downside tends to be that it's a relatively new technology, so it's not appropriate for environments that have older versions of Oracle. Going along with that, you'll find a lot more people/ organizations/ setups using materialized views than Streams, which can be a good thing if you need to hire new staff/ get support from a local user group/ etc. Streams also tends to be more flexible, which can be a good thing, but also tends to make things a bit more complicated.
If you can outline the particular problem you're trying to solve, we can probably be a lot more specific...
Justin

Materialized view as aggregate table, obiee10g???

Hi All,
I am very new to OBIEE and I am learning from OBE tutorials.
I really don't understand how these aggregated tables will be refreshed? I read in some blogs that these tables will be dropped and created using Scheduler scripts, is it correct? I am wondering if we can use "Materialized views" as aggregated tables.
Please help me to understand aggregated tables functionality.
Thanks,
Enric

Hi
You could also Materialized Views as an alternative to the Aggregation functionality in Oracle BI. Treat a MV in the same way you would treat a 'normal' tabel. Add the MV as an additional Logical Table Source to your Logical Table. Scheduling the refresh would normaly be managed outside Oracle BI.
Good Luck,
Daan Bakboord
http://obibb.wordpress.com

Updatable Materialized View and Master Table on same database

Similar Messages

Maybe you are looking for