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

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

Why we cannot perform DML operations against complex views directly.

hi
can any tell me why we cannot perform DML operations against complex views directly.

Hi,
It is not easy to perform DML operations on complex views which involve more than one table as said by vissu. The reason being you may not know which columns to be updated/inserted/deleted on the base tables of the views. If it is a simple view containing a single table it is as simple as performing actions on the table.
For further details visit this
http://www.orafaq.com/wiki/View
cheers
VT

DML operations on multiple views

Hi all.
I can't understand updateing the data on views which created by multiple table joining. Which columns I can update and why I'm getting
ORA-01779: cannot modify a column which maps to a non key-preserved table error??
Can anybody show me explanation with examples??
Thanks...

Modifying a Join View
A modifiable join view is a view that contains more than one table in the top
level FROM clause of the SELECT statement, and that does not contain any of
the following:
- DISTINCT operator
- aggregate functions: AVG, COUNT, GLB, MAX, MIN, STDDEV, SUM, or VARIANCE
- set operations: UNION, UNION ALL, INTERSECT, MINUS
- GROUP BY or HAVING clauses
- START WITH or CONNECT BY clauses
- ROWNUM pseudocolumn
With some restrictions, you can modify views that involve joins. If a view is
a join on other nested views, then the other nested views must be mergeable
into the top level view.
The examples in following sections use the EMP and DEPT tables. These examples
work only if you explicitly define the primary and foreign keys in these
tables, or define unique indexes. Following are the appropriately constrained
table definitions for EMP and DEPT:
CREATE TABLE dept
    deptno NUMBER(4) PRIMARY KEY,
    dname VARCHAR2(14),
    loc VARCHAR2(13)
CREATE TABLE emp
    empno NUMBER(4) PRIMARY KEY,
    ename VARCHAR2(10),
    job varchar2(9),
    mgr NUMBER(4),
    hiredate DATE,
    sal NUMBER(7,2),
    comm NUMBER(7,2),
    deptno NUMBER(2),
    FOREIGN KEY (DEPTNO) REFERENCES DEPT(DEPTNO)
You could also omit the primary and foreign key constraints listed above, and
create a UNIQUE INDEX on DEPT (DEPTNO) to make the following examples work.
CREATE OR REPLACE VIEW emp_dept AS
    SELECT empno, ename, sal, e.deptno, dname, loc
    FROM EMP e, DEPT d
    WHERE e.deptno = d.deptno;
Key-Preserved Tables
The concept of a key-preserved table is fundamental to understanding the
restrictions on modifying join views. A table is key preserved if every key of
the table can also be a key of the result of the join. So, a key-preserved
table has its keys preserved through a join.
Note: It is not necessary that the key or keys of a table be selected for it
to be key preserved. It is sufficient that if the key or keys were selected,
then they would also be key(s) of the result of the join.
Attention: The key-preserving property of a table does not depend on the
actual data in the table. It is, rather, a property of its schema and not of
the data in the table. For example, if in the EMP table there was at most one
employee in each department, then DEPT.DEPTNO would be unique in the result of
a join of EMP and DEPT, but DEPT would still not be a key-preserved table.
If you SELECT all rows from EMP_DEPT view, the results are:
SELECT * FROM EMP_DEPT;
EMPNO ENAME SAL DEPTNO DNAME      LOC
   7369 SMITH   800     20 RESEARCH   DALLAS
   7499 ALLEN 1600     30 SALES      CHICAGO
   7521 WARD   1250     30 SALES      CHICAGO
   7566 JONES 2975     20 RESEARCH   DALLAS
   7654 MARTIN 1250     30 SALES      CHICAGO
   7698 BLAKE 2850     30 SALES      CHICAGO
   7782 CLARK 2695     10 ACCOUNTING NEW YORK
   7788 SCOTT 3000     20 RESEARCH   DALLAS
   7839 KING   5500     10 ACCOUNTING NEW YORK
   7844 TURNER 1500     30 SALES      CHICAGO
   7876 ADAMS 1100     20 RESEARCH   DALLAS
   7900 JAMES   950     30 SALES      CHICAGO
   7902 FORD   3000     20 RESEARCH   DALLAS
   7934 MILLER 1430     10 ACCOUNTING NEW YORK
14 rows selected.
In this view, EMP is a key-preserved table, because EMPNO is a key of the EMP
table, and also a key of the result of the join. DEPT is not a key-preserved
table, because although DEPTNO is a key of the DEPT table, it is not a key of
the join.
DML Statements and Join Views
=============================
!!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!!
Any UPDATE, INSERT, or DELETE statement performed on a join view can modify
only *** one *** underlying base table.
!!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!! IMPORTANT !!!!!!
UPDATE Statements:
The following example shows an UPDATE statement that successfully modifies the
EMP_DEPT view:
UPDATE emp_dept
SET sal = sal * 1.10
WHERE deptno = 10;
The following UPDATE statement would be disallowed on the EMP_DEPT view:
UPDATE emp_dept
SET loc = 'BOSTON'
WHERE ename = 'SMITH';
This statement fails with an ORA-01779 error (cannot modify a column which
maps to a non key-preserved table), because it attempts to modify the
underlying DEPT table, and the DEPT table is not key preserved in the EMP_DEPT
view.
In general, all modifiable columns of a join view must map to columns of a
key-preserved table. If the view is defined using the WITH CHECK OPTION
clause, then all join columns and all columns of repeated tables are not
modifiable.
So, for example, if the EMP_DEPT view were defined using WITH CHECK OPTION,
the following UPDATE statement would fail:
UPDATE emp_dept
SET deptno = 10
WHERE ename = 'SMITH';
The statement fails because it is trying to update a join column.
DELETE Statements:
You can delete from a join view provided there is one and only one
key-preserved table in the join.
The following DELETE statement works on the EMP_DEPT view:
DELETE FROM emp_dept
WHERE ename = 'SMITH';
This DELETE statement on the EMP_DEPT view is legal because it can be
translated to a DELETE operation on the base EMP table, and because the EMP
table is the only key-preserved table in the join.
In the following view, a DELETE operation cannot be performed on the view
because both E1 and E2 are key-preserved tables:
CREATE VIEW emp_emp AS
    SELECT e1.ename, e2.empno, deptno
    FROM emp e1, emp e2
    WHERE e1.empno = e2.empno;
If a view is defined using the WITH CHECK OPTION clause and the keypreserved
table is repeated, then rows cannot be deleted from such a view:
CREATE VIEW emp_mgr AS
    SELECT e1.ename, e2.ename mname
    FROM emp e1, emp e2
    WHERE e1.mgr = e2.empno
    WITH CHECK OPTION;
No deletion can be performed on this view because the view involves a
self-join of the table that is key preserved.
INSERT Statements:
The following INSERT statement on the EMP_DEPT view succeeds:
INSERT INTO emp_dept (ename, empno, deptno)
VALUES ('KURODA', 9010, 40);
This statement works because only one key-preserved base table is being
modified (EMP), and 40 is a valid DEPTNO in the DEPT table (thus satisfying
the FOREIGN KEY integrity constraint on the EMP table).
An INSERT statement like the following would fail for the same reason that
such an UPDATE on the base EMP table would fail: the FOREIGN KEY integrity
constraint on the EMP table is violated.
INSERT INTO emp_dept (ename, empno, deptno)
VALUES ('KURODA', 9010, 77);
The following INSERT statement would fail with an ORA-1776 error (cannot
modify more than one base table through a view).
INSERT INTO emp_dept (empno, ename, loc)
VALUES (9010, 'KURODA', 'BOSTON');
An INSERT cannot, implicitly or explicitly, refer to columns of a
non-key-preserved table. If the join view is defined using the WITH CHECK
OPTION clause, then you cannot perform an INSERT to it.
Using the UPDATABLE_ COLUMNS Views
The following views can assist you when modifying join views:
View Name               Description
USER_UPDATABLE_COLUMNS Shows all columns in all tables and views in the
                        users schema that are modifiable.
DBA_UPDATABLE_COLUMNS   Shows all columns in all tables and views in the
                        DBA schema that are modifiable.
ALL_UPDATABLE_COLUMNS   Shows all columns in all tables and views that are
                        modifiable.

Problem of Materialized view become invalid

Hi,
I know that because of DML or DDL operation My Materialized view invalid.
But I want to know the from which table it become invalid.
Is there any dictionary view from which I can find ?

Hi,
I know that because of DML or DDL operation My Materialized view invalid.
But I want to know the from which table it become invalid.
Is there any dictionary view from which I can find ?

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.

Error creating materialized view log using DBlink

Hi guys,
I have 2 databases in diferent machines . (machine A and B)
Machine A is my production database and I have a database link in machine B accessing Machine A
CREATE MATERIALIZED VIEW vm_test
BUILD IMMEDIATE
REFRESH FAST ON commit as
select * from test@A
-- no problem in this first operation the materialized view was created sucessfully
Now I need to create the LOG
SQL> CREATE MATERIALIZED VIEW LOG ON test
2 PCTFREE 5
3 TABLESPACE prodemge_2006
4 STORAGE (INITIAL 10K NEXT 10K);
CREATE MATERIALIZED VIEW LOG ON test
ERROR at line 1:
ORA-02050: transaction 5.21.8771 rolled back, some remote DBs may be in-doubt
ORA-02068: following severe error from A
ORA-03113: end-of-file on communication channel
What could be causing this error ?
Thank you,
Felipe

ORA-02050 transaction string rolled back, some remote DBs may be in-doubt
Cause: Network or remote failure during a two-phase commit.
Action: Notify operations; remote databases will automatically re-sync when the failure is repaired.
ORA-02068 following severe error from stringstring
Cause: A severe error (disconnect, fatal Oracle error) was received from the indicated database link. See following error text.
Action: Contact the remote system administrator.
M.S.Taj

Roll back Materialized view

Hi
I have refreshed a view that now has a load of erros in the data. Is there any way to get back to the last refresh?
I am using Oracle 10g db
thanks

I tried flashback and got this error
FLASHBACK TABLE juniper_emea_tr_stand TO TIMESTAMP SYSTIMESTAMP - INTERVAL '120' MINUTE
Error report:
SQL Error: ORA-08194: Flashback Table operation is not allowed on materialized views
08194. 00000 - "Flashback Table operation is not allowed on materialized views"
*Cause: An attempt was made to perform Flashback Table operation on a
materialized view. This is not permitted.
*Action: Do not perform a Flashback Table operation on materialized views
or snapshot logs.
Data is being fixed at the moment but really need it now. So if I rollback do Ineed to get it off a tape or can I mport it from the datafile?

Will Materialized view log reduces the performance of DML statements on the master table

Hi all,
I need to refresh a on demand fast refresh Materialized view in Oracle 11GR2. For this purpose I created a Materialized view log on the table (Non partitioned) in which records will be inserted @ rate of 5000/day as follows.
CREATE MATERIALIZED VIEW LOG ON NOTES NOLOGGING WITH PRIMARY KEY INCLUDING NEW VALUES;
This table already has 20L records and adding this Mview log will reduce the DML performance on the table ?
Please guide me on this.

Having the base table maintain a materialised view log will have an impact on the speed of DML statements - they are doing extra work, which will take extra time. A more sensible question would be to ask whether it will have a significant impact, to which the answer is almost certainly "no".
5000 records inserted a day is nothing. Adding a view log to the heap really shouldn't cause any trouble at all - but ultimately only your own testing can establish that.

DML on materialized view

Hi,
I generated materialized view and will maintain data on it when I run delete statement that show below error
ORA-01732: data manipulation operation not legal on this view
So my question is How to maintain data on M View (delete old data)? because I need to keep data only 2 months but source table keep data 6 months.
Regards,
Hiko

taohiko wrote:
There have 8 tables but have only one table that have date/time column and others tables will use primary key from first table relate to data.
And source tables have total records around 300 million records but I want 2 months that around 90 million records.
So I plan to delete data every days that older than 2 months and delete others table with relation by primary from first table.
Can I do? and How to do that?
Regards,
HikoHi,
No you cannot delete the data from materialized view if the view is complex and does not statisfy some basic rules.
Even if you satisfy some of the basic rules still the thing/expectation you have with your MV is not provided by Oracle. If you delete any data from MV, it would be deleted from base table also.
Work around and a better implementation would be
Just include in your create mv a where clause stating
date/time column > trunc(sysdate)-60This would take care of all the other tables data also if they are joined with the main table.
Regards
Anurag

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

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

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+

Logical Standby Database - Materialized Views

Hi,
Are materialized views applied from the primary to the standby? They are not mentioned in the 9i documentation as being excluded, but I cannot get a simple one to apply. The standby database log file claims that it is running the DDL, but I do not see the MV. In previous tests, both table and view create statements have worked along with various DML statements.

The output is as follows .
SQL> SELECT APPLIED_SCN, NEWEST_SCN, READ_SCN, NEWEST_SCN-APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN READ_SCN NEWEST_SCN-APPLIED_SCN
179493 194423 179497 14930
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
no rows selected
SQL> select operation, options, object_name, cost
2 from v$sql_plan, v$session, v$logstdby
3 where v$sql_plan.hash_value = v$session.sql_hash_value
4 and v$session.serial# = v$logstdby.serial#
5 and v$logstdby.status_code=16113;
no rows selected

Materialized view showing red cross in front of it in SQL developer

we created a materialized view in oracle database,it works fine, and other views that select on it return results and work fine too. But it has a red cross in front of it in oracle developer.
I then refresh the view, or recreate the view, it shows green, but after a while when I come back, the red cross show up again.
What does it mean, any error message we can find?
Thanks

878566 wrote:
we created a materialized view in oracle database,it works fine, and other views that select on it return results and work fine too. But it has a red cross in front of it in oracle developer.
I then refresh the view, or recreate the view, it shows green, but after a while when I come back, the red cross show up again.
What does it mean, any error message we can find?
It means your system is working NORMALLY! There is no 'error message' to find because there is no error. What you describe is EXACTLY how MVs are designed to work.
It is NORMAL for MVs to be, and to become, invalid, especially if there refresh setting is ON DEMAND. Don't confuse 'validity' with 'staleness'; they are very different things.
See the section 'Invalidating Materialized Views' in the Data Warehousing Guide'
http://docs.oracle.com/cd/B28359_01/server.111/b28313/advmv.htm#i1007082
Invalidating Materialized Views
Dependencies related to materialized views are automatically maintained to ensure correct operation. When a materialized view is created, the materialized view depends on the detail tables referenced in its definition. Any DML operation, such as an INSERT, or DELETE, UPDATE, or DDL operation on any dependency in the materialized view will cause it to become invalid. To revalidate a materialized view, use the ALTER MATERIALIZED VIEW COMPILE statement.
A materialized view is automatically revalidated when it is referenced. In many cases, the materialized view will be successfully and transparently revalidated. However, if a column has been dropped in a table referenced by a materialized view or the owner of the materialized view did not have one of the query rewrite privileges and that privilege has now been granted to the owner, you should use the following statement to revalidate the materialized view:
ALTER MATERIALIZED VIEW mview_name COMPILE;
The state of a materialized view can be checked by querying the data dictionary views USER_MVIEWS or ALL_MVIEWS. The column STALENESS will show one of the values FRESH, STALE, UNUSABLE, UNKNOWN, UNDEFINED, or NEEDS_COMPILE to indicate whether the materialized view can be used. The state is maintained automatically. However, if the staleness of a materialized view is marked as NEEDS_COMPILE, you could issue an ALTER MATERIALIZED VIEW ... COMPILE statement to validate the materialized view and get the correct staleness state. If the state of a materialized view is UNUSABLE, you must perform a complete refresh to bring the materialized view back to the FRESH state. If the materialized view is based on a prebuilt table that you never refresh, you will need to drop and re-create the materialized view.
As the doc states Oracle will normally 'revalidate' an MV when it is referenced. You can do this manually by using 'ALTER . . . COMPILE'. For an ON DEMAND MV compiling it will NOT alter the contents of the MV - it may stil be STALE.
You don't need to REFRESH or recreate the MV to make it valid; just recompile it. If it doesn't become VALID after you compile it then there is usually an issue with one of the dependent objects that you need to resolve.

DML operations on Materialized view

Similar Messages

Maybe you are looking for