Materialized View Operator

Hi All,
In which scenario's we can use Materialized View Operator as a Target.
What are advantages/features by using Materialized View Operator as a Target.
Regards,
Subbu

Hi
You can design views and materialized views in OWB using the mapping editor, and have the view/mv as a target operator, you then create the actual view/mv from the target operator by doing a 'create and bind', the SQL in the map will be the view/view definition. So you could design the summary as a mapping in OWB.
See here for some details:
http://blogs.oracle.com/warehousebuilder/2007/07/what_is_new_in_11g_and_10203_f.html
Cheers
David

Similar Messages

Table Operator Vs Materialized View Operator

Hi All,
Could you please give the differences between Table Operator and Materialized view Operator in Oracle Warehouse Builder 11g.
Regards,
Subbu

Below an extract of my notes of the Materialized view. The complete notes are here :
http://gerardnico.com/wiki/dw/aggregate_table
=====Notes=====
Materialized views are the equivalent of a summary table. (Materialized views can be also use as replica).
In a olap approach, each of the elements of a dimension could be summarized using a hierarchy.
The end user queries the tables and views in the database. The query rewrite mechanism in a database automatically rewrites the SQL query to use this summary tables.
This mechanism reduces response time for returning results from the query. Materialized views within the data warehouse are transparent to the end user or to the database application.
This is relatively straightforward and is answered in a single word - performance. By calculating the answers to the really hard questions up front (and once only), we will greatly reduce the load on the machine, We will experience:
* Less physical reads - There is less data to scan through.
* Less writes - We will not be sorting/aggregating as frequently.
* Decreased CPU consumption - We will not be calculating aggregates and functions on the data, as we will have already done that.
* Markedly faster response times - Our queries will return incredibly quickly when a summary is used, as opposed to the details. This will be a function of the amount of work we can avoid by using the materialized view, but many orders of magnitude is not out of the question.
Materialized views will increase your need for one resource - more permanently allocated disk. We need extra storage space to accommodate the materialized views, of course, but for the price of a little extra disk space, we can reap a lot of benefit.
Also notice that we may have created a materialized view, but when we ANALYZE, we are analyzing a table. A materialized view creates a real table, and this table may be indexed, analyzed, and so on.
Success
Nico

DML operations on Materialized view

Hi,
I want to know can we perform DML operations like insert/update on a materialized view?
Thanks
Deepak

Thanks Michaels. I'm able to update/insert into materialized view.
But I'm having another problem.
My materialized view is selecting rows on group by condition, but to create a MV as updatable, it should be simple.
SQL> create materialized view mv_utr_Link
2 build immediate
3 refresh force on demand
4 for update
5 enable query rewrite
6 as
7 select link_id,booking_date
8 from t_utr
9 where link_id=246229
10 group by link_id,booking_date
11 /
from t_utr
ERROR at line 8:
ORA-12013: updatable materialized views must be simple enough to do fast
refresh
If I remove the group by clause, its allowing me to create MV, but that won't solve my problem.
any workaround on that?
Thanks
Deepak

Refresh FAST for Materialized View failed after Partition Operation

Dear all,
I have created a Materialized View having a simple join between a Dimension and Fact Table of a Datawarehouse. The MV is REFRESH FAST ON DEMAND.
However, when a Partition Maintenance Operation (PMOP) was performed on the Master Tables, the MV failed to Refresh giving a ORA-32313 error.
As suggested on one of the troubleshooting websites, we did a complete refresh of the MV and fixed it temporarily. However, I would like to know the exact cause for this and would like to have a permanent fix for the same.
Can the DBA for this Database provide me the answers or are there some standard troubleshooting steps for the same?
Please let me know.
Best,
Ketan

Hello Maurice,
Here are the answers to your questions.
1) Database is Oracle 9i.
2) We have a stored procedure to refresh the MV. The command is dbms_mview.refresh('SALES_FACT_MV','f'). It was working fine daily. Only after a PMOP was done on the Master Tables, it failed to refresh. We have also created indexes on some columns of the MV for performance improvement. We are getting a very good improvement.
3) We have MV logs for both Master Tables to store the incremental values.
4) We are not able to get the output from DBMS_MVIEW.EXPLAIN_MVIEW since this can be done only by the DBA. WIll update you once I have the info.
5) Same as Point 2.
Let me know if you need any further info.
Thanks, Ketan

Regd FAST refresh option in a Materialized view

Hi All,
I am using a pipeline function in which I am creating a table of records and a few cursors to fetch data from various tables.
Now this PL/SQL table is being used to construct a Materialized view.
Creation of Materialized view is happening fine but not with FAST refresh option. It gives an error " Cannot create a FAST refresh Materialized view from a complex query."
The query which I have used for the view creation is
CREATE MATERIALIZED VIEW CUSTOM.ABC
PCTFREE 0
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
AS
SELECT A.Number,
A.Guarantors_Number,
A.Guarantors_Name,
A.Personal_Garantee_PCNT,
A.Company, LG.Source_System,
A.Type_of_Info,
A.File_Gen_Date,
A.Periodicity
FROM
TABLE(CUSTOM.CDM_LG_PACK_PF.CDM_LG_FUNC) A;
where CDM_LG_PACK_PF is the package and CDM_LG_FUNC is the pipeline function I have written to fetch all the records.
Please help me on how can I do a FAST refresh on this materialized view.
Thanks in advance,
Gaurav

Welcome to the forum!
FAST refresh doesn't mean that the operation is fast (time wise), it means it's an incremental refresh.
If you have a complex query, you can't use a FAST refresh - that's what the exception tells you.

Need help on tuning materialized view refresh

Hi All,
I am working on materialized view refresh tuning.Initially it was complete refresh and used to take more than 90 mins to complete.
I changed it to fast refresh now it is completing fast. Now i have partitioned the base tables gl_balances and gl_code_combinations of column code_combination_id and created a local index on column code_combination_id then i am trying to partition the materialized on the same column to take advantage of partition change tracking.
Size of gl_balances base tables is 40Gb and all others tables sizes are small. In where clause there all the 4 tables are mapped. If i will create the partition only on code_combination_id will i the materialized will become the candidate for partition change tracking. As i know it will be applicable for PCT. I need expert advice on this.
While doing a fast refresh. the refresh takes less time. when there is a change in gl_balances , gl_code_combinations or gl_periods it completes in 20-30 mins. When there is a change in gl_set_of_books tables. It creates a problem here.DEL query takes more than 48 hours to complete.
CREATE MATERIALIZED VIEW apps.BAL_PART
REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE as
SELECT GL.GL_CODE_COMBINATIONS21.ROWID C1,GL.GL_BALANCES21.ROWID C2, GL.GL_SETS_OF_BOOKS.ROWID C3,
GL.GL_PERIOD.ROWID C4,
"GL"."GL_BALANCES21"."ACTUAL_FLAG" ,
"GL"."GL_BALANCES21"."CURRENCY_CODE" ,
"GL"."GL_BALANCES21"."PERIOD_NUM" ,
"GL"."GL_BALANCES21"."PERIOD_YEAR" ,
"GL"."GL_BALANCES21"."SET_OF_BOOKS_ID" "SOB_ID",
"GL"."GL_CODE_COMBINATIONS21"."CODE_COMBINATION_ID" "CCID",
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT1" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT10" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT11" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT12" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT13" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT14" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT2" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT3" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT4" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT5" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT6" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT7" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT8" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT9" ,
"GL"."GL_PERIODS"."PERIOD_NAME" ,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal_Cr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal_Cr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) Open_Bal_Dr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Close_Bal_Dr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) -
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal,
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Period_Cr,
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Period_Dr
FROM GL.GL_CODE_COMBINATIONS21,
GL.GL_BALANCES21,
GL.GL_SETS_OF_BOOKS,
GL.GL_PERIODS
WHERE GL.GL_BALANCES21.CODE_COMBINATION_ID =GL.GL_CODE_COMBINATIONS21.CODE_COMBINATION_ID
AND GL.GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID = GL.GL_BALANCES21.SET_OF_BOOKS_ID
AND GL.GL_PERIODS.PERIOD_NUM = GL.GL_BALANCES21.PERIOD_NUM
AND GL.GL_PERIODS.PERIOD_YEAR = GL.GL_BALANCES21.PERIOD_YEAR
AND GL.GL_PERIODS.PERIOD_TYPE = GL.GL_BALANCES21.PERIOD_TYPE
AND GL.GL_PERIODS.PERIOD_NAME = GL.GL_BALANCES21.PERIOD_NAME
AND GL.GL_PERIODS.PERIOD_SET_NAME = GL.GL_SETS_OF_BOOKS.PERIOD_SET_NAME
and gl.GL_CODE_COMBINATIONS21.summary_flag != 'Y'TRACE 1046 del statement
DELETE FROM "APPS"."apps.BAL_PART" SNA$
WHERE "C3" IN (SELECT /*+ NO_MERGE */ * FROM (SELECT
CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM "GL"."MLOG$_GL_SETS_OF_BOOKS"
"MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1 ) AS OF SNAPSHOT(:B_SCN) MAS$)
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1 17759.00 171782.99 159422121    1267371 2564144739           0
Fetch        0      0.00       0.00          0          0          0           0
total        2 17759.00 171782.99 159422121    1267371 2564144739           0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 175 (APPS)   (recursive depth: 1)
Rows     Row Source Operation
      0 DELETE apps.BAL_PART (cr=0 pr=0 pw=0 time=0 us)
193128740   NESTED LOOPS (cr=592437 pr=592422 pw=0 time=945244160 us cost=339302 size=168 card=1)
      3    SORT UNIQUE (cr=7 pr=0 pw=0 time=15832 us cost=2 size=138 card=1)
     24     TABLE ACCESS FULL MLOG$_GL_SETS_OF_BOOKS (cr=7 pr=0 pw=0 time=19 us cost=2 size=138 card=1)
193128740    INDEX RANGE SCAN C3BOOKS (cr=592430 pr=592422 pw=0 time=789499200 us cost=339299 size=3318314250 card=110610475)(object id 2114736)
error during execute of EXPLAIN PLAN statement
ORA-08187: snapshot expression not allowed here
parse error offset: 314
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                   159520897        2.12     144415.96
latch: cache buffers chains                   134        0.06          0.68
latch: undo global data                        33        0.02          0.15
latch: object queue header operation          521        0.02          0.53
log file switch (private strand flush incomplete)
                                                532        0.31         28.26
resmgr:cpu quantum                            155        1.40         13.49
resmgr:internal state change                   25        0.11          2.21
latch free                                     10        0.00          0.00
latch: cache buffers lru chain                  4        0.00          0.00
rdbms ipc reply                               489        0.02          0.54
reliable message                              587        0.00          0.56
latch: row cache objects                        3        0.00          0.00
********************************************************************************GL_SETS_OF_BOOKS has only 6 rows. I know there is complete refresh as a option which will again take more than 90 mins.
I want to do the fast refresh. Tables rows details below.
SQL> select count(*) from gl.gl_code_combinations21;
COUNT(*)
3075255
SQL> select count(*) from gl.GL_PERIODS;
COUNT(*)
1160
SQL> select count(*) from gl.gl_balances21;
COUNT(*)
477613527
SQL> select count(*) from gl.gl_sets_of_books;
COUNT(*)
6gl_sets_of_books has less rows. Whenever there is a change then it mapped to huge rows hence during materialized view has delete huge number of rows.
select count(*) from apps.BAL_PART group by C3;
C3 is the rowid which is present in create materialized statement.
COUNT(*)
292927011
210215
69330
184406971
Is there any way to improve the plan. As i created a partition on code_combination_id and local index on code_combination_id which will not help in set_of_books_id case. I dont PCT will help here or not. Is it possible to use PCT refresh by equipartitioning only one column in where clause.
Please assist me in improving refresh of materialized view using fast refresh.
Thanks and Regards,
Edited by: user646034 on Feb 23, 2013 11:13 PM
Edited by: user646034 on Feb 23, 2013 11:19 PM
Edited by: user646034 on Feb 23, 2013 11:46 PM
Edited by: user646034 on Feb 25, 2013 11:46 AM

Hi
The below explain without index and with index.
/* MV_REFRESH (DEL) */ DELETE FROM "APPS"."BAL_PART
" SNA$ WHERE "C3" IN (SELECT /*+ NO_MERGE */ * FROM (SELECT
CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM
"GL"."MLOG$_GL_SETS_OF_BOOKS" "MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1
) AS OF SNAPSHOT(:B_SCN) MAS$)
Plan hash value: 2704021294
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | Id | Operation            | Name                          | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |
|   0 | DELETE STATEMENT     |                               |        |       |   339K(100)|          |
|   1 | DELETE              | BAL_PART                          |        |       |            |          |
|   2 |   NESTED LOOPS       |                               |      1 |   168 |   339K (1)|999:59:59 |
|   3 |    SORT UNIQUE       |                               |      1 |   138 |     2   (0)| 00:02:31 |
|   4 |     TABLE ACCESS FULL| MLOG$_GL_SETS_OF_BOOKS        |      1 |   138 |     2   (0)| 00:02:31 |
|   5 |    INDEX RANGE SCAN | C3BOOKS                       |    110M| 3164M|   339K (0)|999:59:59 |
If i will not use the C3 index then the query will use the belolw plan, I guess this will also take same time or more time.
|   0 | DELETE STATEMENT       |                               |        |       | 9743K(100)|          |
|   1 | DELETE                | BAL_PART                          |       |            |          |

Materialized view takes long to refresh

On Oracle 11g2, I created a materialized view fast refresh on commit CREATE MATERIALIZED VIEW mv_case
PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
SELECT p.jperson_id,offense_id,CASE_SENTENCE_DATE,court_ref,CASE_COURT_ORI,
c.CASE_VERDICT_DATE,CASE_DOCKET,c.CASE_EXPUNGED,c.jcase_id,cc.CYCLEID_ID,
p.rowid p_rowid,xc.rowid xc_rowid,c.rowid c_rowid,cxo.rowid cxo_rowid,cc.rowid cc_row_id
FROM jperson p,jperson_x_jcase xc,jcase c,jcase_x_offense cxo,jcase_x_cycleid cc
where p.jperson_id = xc.jperson_id(+) and xc.jcase_id = c.jcase_id(+)
and c.jcase_id = cxo.jcase_id(+) and c.jcase_id=cc.jcase_id;
create index idx_mv_case_pid on mv_case(jperson_id);
ALTER TABLE mv_case ADD (CONSTRAINT PK_MV_CASE PRIMARY KEY(jcase_id,offense_id)) ;
create index idx_mv_case_p_rowid on mv_case(p_rowid);
create index idx_mv_case_xc_rowid on mv_case(xc_rowid);
create index idx_mv_case_c_rowid on mv_case(c_rowid);
create index idx_mv_case_cxo_rowid on mv_case(cxo_rowid);
create index idx_mv_case_cc_rowid on mv_case(cc_row_id); I inserted one single row into one of the master table
insert into jcase_x_offense (offense_id,jcase_id) values ('test_row3','test_row3');
commit; The commit tooks a quite long. I looked into the trace file and the actual insert took 0.01 seconds but one of the internel DML took most of time. I copy the relevant TKPROF output for the internal DML belowINSERT INTO QAPF.MV_CASE SELECT /*+ NO_MERGE(JV$) */
MAS$4.JPERSON_ID,JV$.OFFENSE_ID,MAS$2.CASE_SENTENCE_DATE,
MAS$2.COURT_REF,MAS$2.CASE_COURT_ORI,MAS$2.CASE_VERDICT_DATE,
MAS$2.CASE_DOCKET,MAS$2.CASE_EXPUNGED,MAS$2.JCASE_ID,
MAS$0.CYCLEID_ID,MAS$4.ROWID,MAS$3.ROWID,MAS$2.ROWID,JV$.RID$,
MAS$0.ROWID
FROM ( SELECT MAS$.ROWID RID$ , MAS$.* FROM QAPF.JCASE_X_OFFENSE MAS$ WHERE ROWID IN
          (SELECT /*+ HASH_SJ */ CHARTOROWID(MAS$.M_ROW$$) RID$
           FROM QAPF.MLOG$_JCASE_X_OFFENSE MAS$ WHERE MAS$.XID$$ = :1 )) JV$,
JCASE_X_CYCLEID AS OF SNAPSHOT(:B_SCN) MAS$0, JCASE AS OF SNAPSHOT(:B_SCN) MAS$2,
JPERSON_X_JCASE AS OF SNAPSHOT(:B_SCN) MAS$3, JPERSON AS OF SNAPSHOT(:B_SCN) MAS$4
WHERE (MAS$4.JPERSON_ID=MAS$3.JPERSON_ID(+)
AND MAS$3.JCASE_ID=MAS$2.JCASE_ID(+)
AND MAS$2.JCASE_ID=JV$.JCASE_ID(+)
AND MAS$2.JCASE_ID=MAS$0.JCASE_ID)
AND NOT EXISTS (
    SELECT 1 FROM QAPF.MV_CASE SNA2$
    WHERE (SNA2$.P_ROWID = MAS$4.ROWID)
    AND (SNA2$.XC_ROWID = MAS$3.ROWID OR MAS$3.ROWID IS NULL )
    AND (SNA2$.C_ROWID = MAS$2.ROWID OR MAS$2.ROWID IS NULL )
    AND (SNA2$.CC_ROW_ID = MAS$0.ROWID OR MAS$0.ROWID IS NULL )
    AND JV$.RID$ IS NULL)
AND NOT EXISTS (
    SELECT 1 FROM JCASE_X_OFFENSE MAS_INNER$, JCASE AS OF SNAPSHOT(:B_SCN) MAS_OUTER$
    WHERE MAS$2.ROWID = MAS_OUTER$.ROWID AND JV$.RID$ IS NULL
    AND MAS_OUTER$.JCASE_ID=MAS_INNER$.JCASE_ID)
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1     99.51     364.87     377012   17412972          1           0
Fetch        0      0.00       0.00          0          0          0           0
total        2     99.51     364.87     377012   17412972          1           0
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=17412968 pr=377012 pw=120527 time=0 us)
      0   FILTER (cr=17412968 pr=377012 pw=120527 time=0 us)
3363837    HASH JOIN RIGHT OUTER (cr=264914 pr=280254 pw=120527 time=35845080 us cost=299444 size=1029332286 card=3363831)
      1     VIEW (cr=112490 pr=180864 pw=119722 time=0 us cost=30743 size=78 card=1)
      1      HASH JOIN SEMI (cr=112490 pr=180864 pw=119722 time=0 us cost=72627 size=208 card=1)
11354346       TABLE ACCESS FULL JCASE_X_OFFENSE (cr=112488 pr=112447 pw=0 time=4814838 us cost=30703 size=749386770 card=11354345)
      1       TABLE ACCESS BY INDEX ROWID MLOG$_JCASE_X_OFFENSE (cr=2 pr=0 pw=0 time=0 us cost=1 size=142 card=1)
      1        INDEX RANGE SCAN IDX_MLOG$_XID_JCASE_X_OFFENSE (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 98375)
3363837     HASH JOIN (cr=152424 pr=99390 pw=805 time=29973970 us cost=268690 size=766953468 card=3363831)
2994042      INDEX FAST FULL SCAN JPERSON_I0 (cr=18134 pr=0 pw=0 time=772990 us cost=17450 size=134731845 card=2994041)(object id 83738)
3363837      HASH JOIN (cr=134290 pr=99390 pw=805 time=25292580 us cost=212128 size=615581073 card=3363831)
3363837       HASH JOIN (cr=69008 pr=34127 pw=805 time=4750330 us cost=101637 size=393568929 card=3363837)
3363837        TABLE ACCESS FULL JCASE_X_CYCLEID (cr=33337 pr=33322 pw=0 time=2942460 us cost=33569 size=222013242 card=3363837)
6586646        TABLE ACCESS FULL JCASE (cr=35671 pr=0 pw=0 time=1584102 us cost=35988 size=335918895 card=6586645)
6586635       TABLE ACCESS FULL JPERSON_X_JCASE (cr=65282 pr=65263 pw=0 time=5446686 us cost=65632 size=434717844 card=6586634)
3363837    FILTER (cr=17148054 pr=96758 pw=0 time=0 us)
3363837     MAT_VIEW ACCESS BY INDEX ROWID MV_CASE (cr=17148054 pr=96758 pw=0 time=0 us cost=7 size=40 card=1)
32464070      INDEX RANGE SCAN IDX_MV_CASE_P_ROWID (cr=4489770 pr=15250 pw=0 time=19576798 us cost=3 size=0 card=7)(object id 98467)
      0    FILTER (cr=0 pr=0 pw=0 time=0 us)
      0     NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=78 card=1)
      0      TABLE ACCESS BY USER ROWID JCASE (cr=0 pr=0 pw=0 time=0 us cost=1 size=45 card=1)
      0      INDEX RANGE SCAN JCASE_X_OFFENSE_I0 (cr=0 pr=0 pw=0 time=0 us cost=3 size=33 card=1)(object id 83623)Questions:
1) what are the objects like JCASE AS OF SNAPSHOT(:B_SCN) ? Can I index them? I tried access it but got error
select * from JCASE AS OF SNAPSHOT(:B_SCN) ;
ORA-08187: snapshot expression not allowed here
08187. 00000 - "snapshot expression not allowed here"
*Cause:    A snapshot expression using AS OF was specified when not allowed.
*Action:   Do not use the AS OF clause
2) In the inline view following the firs FROM, it used ROWID in where clause. I tried create an index on ROWID, and error
create index idx_jcase_offense_rid on JCASE_X_OFFENSE(rowid)
ERROR at line 1:
ORA-00904: : invalid identifier
Note: I checked that I have indexes all fields in all where clauses in the DML except rowid.
Thanks for help.

sybrand_b wrote:
1 Apparently Oracle is using Flashback technology when no materialized view logs have been set up
As your MV is a complex MV it is not a candidate for FAST REFRESH ON COMMIT.
I haven't looked closely at how 11.2 has changed the "fast refresh on commit" - but I would have expected it to raise an Oracle error when the OP tried to create the materialized view with that option if it were not possible.
I think your first comment is probably the more important one - if the user sets up suitable materialized view logs on all the tables in the outer join then it's possible that the fast refresh could work properly.
This is pure speculation, of course, based on the absence of an error message.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+

Materialized view to be optimized!!

The following materialized view is taking more than 1.5 hours. Any alternate suggestion/advise would be appreciated. Thanks in advance .
SELECT e.emp_key, trim(e.gid) gid, pcm.check_id, pcm.end_date, pcm.g_amt, pcm.net_amt, pedt.ded_amt, pedt.tax, pdm.ded_cd, trim(pdm.ded) ded, pcm.check_date
FROM employee e, check_mstr pcm, deduction_mstr pdm, deduction_tkn pedt, sys_parms sp
WHERE e.time_key = time_pkg.fx_time_key
AND e.emp_num = pcm.emp_num
AND pcm.LOAD_KEY = pedt.load_key
AND pcm.emp_num = pedt.emp_num
AND pcm.check_id = pedt.check_id
AND pdm.time_key = pedt.load_key
AND pdm.ded_key = pedt.ded_key
AND TO_CHAR(pcm.end_date, 'YYYY') = sp.run_year
--------------------------------------------------------------------------------------------------------------

When was the last time that statistics were computed
for these tables? Are you inadvertently missing a
join condition? Can you post an explain plan to see
if there are any bottlenecks?
HTH!Operation                         Object Name          Rows     Bytes     Cost
SELECT STATEMENT Optimizer Mode=CHOOSE                         1          3696
TABLE ACCESS BY INDEX ROWID               EMPLOYEE          1     26     103
NESTED LOOPS                                   1     224     3696
HASH JOIN                                        1     198     3593
NESTED LOOPS                                   1     195     3590
HASH JOIN                                   3     357     3587
TABLE ACCESS FULL               DEDUCTION_MSTR          271 K     12 M     322
TABLE ACCESS FULL               DEDUCTION_TKN          887 K     60 M     1046
TABLE ACCESS BY INDEX           ROWID     CHECK_MSTR     1     76     1
INDEX UNIQUE SCAN               CHECK_MSTR          1
TABLE ACCESS FULL               SYS_PARMS          1     3     2
INDEX RANGE SCAN                    EMP_UIDX          1          102
----------------------------------------------------------------------------------------------------------------------

How to Refresh materialized view

Hi,
I am using 11G owb. I would like to know if any one can help me know if there is any easy to Refresh materialized view . I will be using this materialized view to source data from my maps. this map will be part of a process flow. i would like to refresh the materialized view before every run of the map in process flow.
Thanks,
Ash.
Edited by: user591315 on Aug 6, 2009 1:26 PM

A couple of approaches;
* refresh the MV from a procedure in a pre map process operator (its an operator in a mapping), or
* call the procedure from a process flow activity before the map
Cheers
David

Create a materialized view :-

How do I create a materialized view on a view ,so that it will refresh automatically on every commit in base table where the view having more that 9 function ?

Read Materialized View Refresh for complete information.
For a Jist:
Refresh Mode Description
ON COMMIT
Refresh occurs automatically when a transaction that modified one of the materialized view's detail tables commits. This can be specified as long as the materialized view is fast refreshable (in other words, not complex). The ON COMMIT privilege is necessary to use this mode.
ON DEMAND
Refresh occurs when a user manually executes one of the available refresh procedures contained in the DBMS_MVIEW package (REFRESH, REFRESH_ALL_MVIEWS, REFRESH_DEPENDENT).
When a materialized view is maintained using the ON COMMIT method, the time required to complete the commit may be slightly longer than usual. This is because the refresh operation is performed as part of the commit process. Therefore this method may not be suitable if many users are concurrently changing the tables upon which the materialized view is based.
If you anticipate performing insert, update or delete operations on tables referenced by a materialized view concurrently with the refresh of that materialized view, and that materialized view includes joins and aggregation, Oracle recommends you use ON COMMIT fast refresh rather than ON DEMAND fast refresh.
If you think the materialized view did not refresh, check the alert log or trace file.
If a materialized view fails during refresh at COMMIT time, you must explicitly invoke the refresh procedure using the DBMS_MVIEW package after addressing the errors specified in the trace files. Until this is done, the materialized view will no longer be refreshed automatically at commit time.

Error on creating Materialized view.

Hi,
I don't understand why it happens...
When I tried to creating materialized view, it shows a error "ORA-01013: User requested cancel of current operation".
I don't understand why it happens. I just waited it successfully created. But I didn't press any button.
Does it matter of size of joining table? I had same issue before. At that time I just removed some tables from the joining condition, this error was gone.
But at this time, I cannot exclude any other tables the select statement
Can anyone help me this issue, please?

Hi,
11g ( 11.2.0.3 ) has a problem with materialized views based on ROWID, resulting in the problem you mentioned.
A workaround is creating the MV's based on primary keyl.
There is also a patch available on MOS, to solve the problem ( thanks to a very long SR from me :-) )
It is known as bug 13657605 and the patch for it has the same number.
Remember to read the README, as this patch is only for 11.2.0.3 !!
Cheers
FJFranken

Spatial vs. materialized views/query rewrite

Dear all,
we are trying to use Spatial (Locator) functionality together with performance optimization using materialized views and query rewrite, and it does not seem to work. Does anybody has experience with this?
The problem in more detail:
* There is a spatial attribut (vom Typ GEOMETRY) in our table;
* we define a materialized view on that table;
* we run a query that could be better answered using the materialized view with query rewrite;
*the optimizer does not choose the plan using the materialized view, query rewrite does not take place;
This happenes, even if neither the materialized view, nor the query contains the spatial attribut.
The explanation given by the procedure DBMS_MVIEW.Explain_Rewrite is:
"QSM-01064 query has a fixed table or view Cause: Query
rewrite is not allowed if query references any fixed tables or views"
We are using Oracle 9R2, Enterprise Edition, with locator. Nevertheless, it would also be interesting, if there is any improvement in 10g?
A more complicated task, using materialized views to optimize spatial operations (e.g., sdo_relate) would also be very interesting, as spatial joins are very expensive operations.
Thanks in advance for any comments, ideas!
Cheers,
Gergely Lukacs

Hi Dan,
thanks for your rapid response!
A simple example is:
alter session set query_rewrite_integrity=trusted;
alter session set query_rewrite_enabled=true;
set serveroutput on;
/* Creating testtable */
CREATE TABLE TESTTABLE (
KEY1 NUMBER (4) NOT NULL,
KEY2 NUMBER (8) NOT NULL,
KEY3 NUMBER (14) NOT NULL,
NAME VARCHAR2 (255),
X NUMBER (9,2),
Y NUMBER (9,2),
ATTR1 VARCHAR2 (2),
ATTR2 VARCHAR2 (30),
ATTR3 VARCHAR2 (80),
ATTR4 NUMBER (7),
ATTR5 NUMBER (4),
ATTR6 NUMBER (5),
ATTR7 VARCHAR2 (40),
ATTR8 VARCHAR2 (40),
CONSTRAINT TESTTABLE_PK
PRIMARY KEY ( KEY1, KEY2, KEY3 ));
/* Creating materialized view */
CREATE MATERIALIZED VIEW TESTTABLE_MV
REFRESH COMPLETE
ENABLE QUERY REWRITE
AS SELECT DISTINCT ATTR7, ATTR8
FROM TESTTABLE;
/* Creating statistics, just to make sure */
execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE', cascade=>TRUE);
execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE_MV', cascade=>TRUE);
/* Explain rewrite procedure */
DECLARE
Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
querytxt VARCHAR2(1500) :=
'SELECT COUNT(*) FROM (
SELECT DISTINCT
ATTR8 FROM
TESTTABLE
i NUMBER;
BEGIN
DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
FOR i IN 1..Rewrite_Array.count
LOOP
DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
END LOOP;
END;
The message you get is:
QSM-01009 materialized view, string, matched query text
Cause: The query was rewritten using a materialized view, because query text matched the materialized view text.
Action: No action required.
i.e. query rewrite works!
/* Adding geometry column to the testtable -- not to the materialized view, and not to the query! */
ALTER TABLE TESTTABLE
ADD GEOMETRYATTR mdsys.sdo_geometry;
/* Explain rewrite procedure */
DECLARE
Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
querytxt VARCHAR2(1500) :=
'SELECT COUNT(*) FROM (
SELECT DISTINCT
ATTR8 FROM
TESTTABLE
i NUMBER;
BEGIN
DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
FOR i IN 1..Rewrite_Array.count
LOOP
DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
END LOOP;
END;
The messages you get are:
QSM-01064 query has a fixed table or view
Cause: Query rewrite is not allowed if query references any fixed tables or views.
Action: No action required.
QSM-01019 no suitable materialized view found to rewrite this query
Cause: There doesn't exist any materialized view that can be used to rewrite this query.
Action: Consider creating a new materialized view.
i.e. query rewrite does not work!
If this works, the next issue is to use materialized views for optimizing spatial operations, e.g., a spatial join. I can supply you with an example, if necessary (only makes sense, I think, after the first problem is solved).
Thanks in advance for any ideas, comments!
Cheers,
Gergely

ORA-12008: error in materialized view refresh path with ORA-01652

I have a temp tablespace with 2 tempfiles of 2GB each (total 4GB) but still refresh of materialized view is failing with following error:
5646690 - BIS Materialized View Refresh Program
ORA-12008: error in materialized view refresh path
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP1
I checked and temp ts is completly filled
SQL> select TABLESPACE_NAME, BYTES_USED, BYTES_FREE from V$TEMP_SPACE_HEADER;
TABLESPACE_NAME BYTES_USED BYTES_FREE
TEMP1 2147483648 0
TEMP1 2147483648 0
My question is how do I find out how much space I need for temp tablespace. what 's the best practise to size temp tablespace when running refresh. refresh is done by client who is submitting a request thru ebiz apps so I 'd like to size it correctly without having to keep guessing.
Thanks so much in advance for any help

Hello,
Temp tablespace size depends how much sort by , order by operation your application performing. You can create new temp tablespace and drop old one with bigger file size
CREATE TEMPORARY TABLESPACE TEMP02 TEMPFILE '\mypath_to_temp\TEMP02' SIZE 256M REUSE AUTOEXTEND ON NEXT 256M MAXSIZE 8192M EXTENT MANAGEMENT LOCAL;
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP02;
Drop tablespace temp including contents; -- Make sure you delete on temp data files.Here is link for your reading purpose
http://www.idevelopment.info/data/Oracle/DBA_tips/Tablespaces/TBS_3.shtml
Regards
Edited by: OrionNet on Mar 6, 2009 6:15 PM

Materialized View with Joins

Dear Dev/DBAs,
I have the following scenario:
SQL> CREATE TABLE T1 (ID NUMBER(3),NAME VARCHAR2(10));
SQL> CREATE TABLE T2 (ID NUMBER(3),NAME VARCHAR2(10));
The T1 contains records having the ID num from 10 to 80 and the T2 having the ID from 90 to 170
SQL> SELECT * FROM T1 JOIN ALL SELECT * FROM T2
It give all records in the 2 tables.
I'm planning to create a materialized view (like CREATE MATERIALIZED VIEW V_TAB REFRESH ON COMMIT AS SELECT * FROM T1 JOIN ALL SELECT * FROM T2) and it seems i can't do with the error ORA-12054, further the oracle documentation says that materialized view can only be used with a simple join.
Do you have another solution??
Note that the materialized views can be used to improve queries.
Thank you in advance

Straight from the link I posted:
*Restrictions on Fast Refresh on Materialized Views with UNION ALL*Materialized views with the UNION ALL set operator support the REFRESH FAST option if the following conditions are satisfied:
* The defining query must have the UNION ALL operator at the top level.
The UNION ALL operator cannot be embedded inside a subquery, with one exception: The UNION ALL can be in a subquery in the FROM clause provided the defining query is of the form SELECT * FROM (view or subquery with UNION ALL) as in the following example:
CREATE VIEW view_with_unionall AS
(SELECT c.rowid crid, c.cust_id, 2 umarker
FROM customers c WHERE c.cust_last_name = 'Smith'
UNION ALL
SELECT c.rowid crid, c.cust_id, 3 umarker
FROM customers c WHERE c.cust_last_name = 'Jones');
CREATE MATERIALIZED VIEW unionall_inside_view_mv
REFRESH FAST ON DEMAND AS
SELECT * FROM view_with_unionall;
Note that the view view_with_unionall satisfies the requirements for fast refresh.
* Each query block in the UNION ALL query must satisfy the requirements of a fast refreshable materialized view with aggregates or a fast refreshable materialized view with joins.
The appropriate materialized view logs must be created on the tables as required for the corresponding type of fast refreshable materialized view.
Note that the Oracle Database also allows the special case of a single table materialized view with joins only provided the ROWID column has been included in the SELECT list and in the materialized view log. This is shown in the defining query of the view view_with_unionall.
* The SELECT list of each query must include a maintenance column, called a UNION ALL marker. The UNION ALL column must have a distinct constant numeric or string value in each UNION ALL branch. Further, the marker column must appear in the same ordinal position in the SELECT list of each query block.
* Some features such as outer joins, insert-only aggregate materialized view queries and remote tables are not supported for materialized views with UNION ALL.
* Partiton Change Tracking (PCT)-based refresh is not supported for UNION ALL materialized views.
* The compatibility initialization parameter must be set to 9.2.0 or higher to create a fast refreshable materialized view with UNION ALL.

Updatable Materialized View with Union ALL

(please don't ask about db structure)
DB: 11gR2
create table table_1 (
    id number primary key,
    val varchar2(100)
create table table_2 (
    id number primary key,
    val varchar2(100)
insert into table_1(id) values (0);
insert into table_1(id) values (2);
insert into table_1(id) values (3);
insert into table_1(id) values (4);
insert into table_1(id) values (5);
insert into table_2(id) values (10);
insert into table_2(id) values (12);
insert into table_2(id) values (13);
insert into table_2(id) values (14);
insert into table_2(id) values (15);
update table_1 set val='Table1 val:'||id;
update table_2 set val='Table2 val:'||id;
create view v_table_all as
select * from table_1
view V_TABLE_ALL created.
select * from v_table_all;
ID                     VAL
0                      Table1 val:0
2                      Table1 val:2
3                      Table1 val:3
4                      Table1 val:4
5                      Table1 val:5
select column_name, updatable, insertable, deletable
from user_updatable_columns
where table_name = 'V_TABLE_ALL'
COLUMN_NAME                    UPDATABLE INSERTABLE DELETABLE
ID                             YES       YES        YES
VAL                            YES       YES        YES
update v_table_all set val='XXX changed' where id = 3;
1 row updated.
select * from table_1;
ID                     VAL
0                      Table1 val:0
2                      Table1 val:2
3                      XXX changed
4                      Table1 val:4
5                      Table1 val:5
rollback;
select * from table_1;
ID                     VAL
0                      Table1 val:0
2                      Table1 val:2
3                      Table1 val:3
4                      Table1 val:4
5                      Table1 val:5
create or replace view v_table_all as
select * from table_1
union select * from table_2;
view V_TABLE_ALL created.
select * from v_table_all;
ID                     VAL
0                      Table1 val:0
2                      Table1 val:2
3                      Table1 val:3
4                      Table1 val:4
5                      Table1 val:5
10                     Table2 val:10
12                     Table2 val:12
13                     Table2 val:13
14                     Table2 val:14
15                     Table2 val:15
select column_name, updatable, insertable, deletable
from user_updatable_columns
where table_name = 'V_TABLE_ALL'
COLUMN_NAME                    UPDATABLE INSERTABLE DELETABLE
ID                             NO        NO         NO
VAL                            NO        NO         NO
trying update:
update v_table_all set val='XXX changed' where id = 3;
SQL-Fehler: ORA-01732: Datenmanipulationsoperation auf dieser View nicht zulässig
01732. 00000 - "data manipulation operation not legal on this view"
*Cause:
*Action:
drop view v_table_all;
view V_TABLE_ALL dropped.all is ok before this point.
now we want create a new materialized view with some query
create materialized view v_table_all
as
select * from table_1
union all select * from table_2 ;
materialized view V_TABLE_ALL created.
select column_name, updatable, insertable, deletable
from user_updatable_columns
where table_name = 'V_TABLE_ALL'
COLUMN_NAME                    UPDATABLE INSERTABLE DELETABLE
ID                             YES       YES        YES
VAL                            YES       YES        YES       it seems to be ok with update.
but...
update v_table_all set val='XXX changed' where id = 3;
SQL-Fehler: ORA-01732: Datenmanipulationsoperation auf dieser View nicht zulässig
01732. 00000 - "data manipulation operation not legal on this view"
*Cause:
*Action:How can solve this issue??
Any suggestion

Looks like user_updatable_columns sort of thinks the MV is just a table - I don't know about that...
An MV on a single table can be updated - I tried that and it works:
create materialized view mv_table_1 for update
as
select * from table_1;I noticed [url http://download.oracle.com/docs/cd/E11882_01/server.112/e16579/advmv.htm#sthref294]examples stating the UNION ALL needs a "marker" so Oracle can know from the data which source table a row in the MV originates from - like this:
create materialized view v_table_all for update
as
select 'T1' tab_id, table_1.* from table_1
union all
select 'T2' tab_id, table_2.* from table_2 ;But that also fails (the "marker" requirement was specifically for FAST REFRESH, so it was just a long shot ;-) )
What are you planning to do?
<li>Create the MV.
<li>Update records in the MV - which then is no longer consistent with the source data.
<li>Schedule a complete refresh once in a while - thereby overwriting/losing the updates in the MV.
If that is the case, I suggest using a true table rather than an MV.
<li>Create table t_table_all as select ... .
<li>Update records in the table - which then is no longer consistent with the source data.
<li>Schedule a job to delete table and insert into table select ... once in a while - thereby overwriting/losing the updates in the table.
In other words a kind of "do it yourself MV".
I cannot see another way at the moment? But perhaps try in the data warehousing forum - the people there may have greater experience with MV's ;-)

Materialized View Operator

Similar Messages

Maybe you are looking for