Mview Fast Refresh Problem

Hello,
We run a fast refresh for a particular mview. I have the mview log created on the primary db (base table) and the mview created on another reporting database.
The fast refresh seems to be fine throughout the day but at the end of a day it fails to do the fast refresh and i'm forced to do a complete refresh everyday which fixes it but this cycle continues until the end of day when it breaks again.
If you notice in the next date column the refresh date turns to 01-JAN-00, not sure why this happens and this is causing the problem.
JOB REFRESH_JOB LAST_DATE NEXT_DATE NEXT_SEC BROKEN
70 CON_SYS"."MV_BRICKNW" 04-AUG-10 01-JAN-00 00:00:00 Y
75 CON_SYS"."MV_BRICKNWCAN" 04-AUG-10 01-JAN-00 00:00:00 Y
Could someone please tell me what the problem is.

The Refresh Date gets reset when the job is Broken (which you see as BROKEN='Y'). The job is Broken when 16 consecutive attempts have failed (which you would see in FAILURE_COUNT).
You have to find out why it fails -- fails 16 times. There seems to be an issue with the date/time logic OR one of the source objects probably gets dropped or becomes unavailable close to the end of the day.
Hemant K Chitale

Similar Messages

Mview fast refresh taking longer than complete refresh

Hi there,
We have a mview which takes about an hour to refresh in complete mode. Created all the mview logs and refreshing via fast method but this takes longer.
When all the mview logs empty works fine as fast refresh and far far quicker as would expect. Tried upadting one of records on base table called todays_date which simply stores todays date to get around fast refresh restriction with sysdate.
Anybody any idea why so slow?
Also wondering if better approach. Thought about just having an aggregate table and processing the inserts in MLOG$_TRANS_TABLE via a merge statement. Also heard about change data capture.
Any thoughts/suggestions welcome.
Many Thanks

Well, search with your post subject on this forum. There are a lot of threads discussing the same.

Materialized View fast refresh problems

I have two databases (A and B).
In database A, user NICK has a table called COLOUR_MASTER.
Also in that database, NICK issues the command create materialized view log on colour_master with primary key including new values (and yes, there is a primary key defined for this table)
In database B, there is a database link called A_LINK, connect to nick identified by password using 'dbA';
Also in database B, user IAN creates a materialized view CM_MV refresh fast as select * from colour_master@A_LINK
That statement completes successfully, and there are several million rows in CM_MV when it's done.
Immediately, IAN issues this command:
begin
dbms_mview.refresh('CM_MV');
end;
...and after a slight pause, he gets the error
ORA-12008: error in materialized view refresh path
ORA-02068: following sever error from A_LINK
ORA-03113: end-of-file on communication channel
Yet a +'select count(*) from colour_master@A_LINK'+ submitted immediately manages to return the correct number of records in database A -so that 3113 is a bit misleading, I think, in that instance A did not crash, the database remains accessible at all times, there are no networking issues (database A and B are both located in the same server room, so this isn't like I'm trying to connect half way round the globe).
The only thing I can think of is that there's a permissions problem causing this error. That because the MV creation is done via a link, there's no problem in IAN seeing the appropriate objects, but that once refreshes come into play, maybe there is.
Can anyone shed any light on why I can't do the fast refresh of the view I can happily create, please?

I'm surprised that no-one has asked you to do the obvious: try doing a select * from colour_master@A_LINK, without that being wrapped up in a create materialized view statment. Just do a plain select * from...
My bet is that you'll get an ORA_22992 cannot use LOB locators selected from remote tables error. And if you can't do a simple select * from a remote table, I suspect that you can reasonably expect fireworks when you try to create or refresh a materialized view on such a thing!
Here's a quick test:
In Database 1:
=========
SQL> create table A (col1 varchar2(2), col2 clob);
Table created.
SQL> alter table A add constraint A1 primary key (col1);
Table altered.
SQL> insert into A values ('AA','This is an entry into a clob column');
1 row created.
SQL> commit;
Commit complete.
SQL> create materialized view log on A with primary key including new values;
Materialized view log created.In Database 2
=========
SQL> connect ims_global/v0yager1@ussd
Connected.
SQL> create materialized view B refresh fast as
2 select * from A@remotedb_link;
Materialized view created.
SQL> exec dbms_mview.refresh('B');
BEGIN dbms_mview.refresh('B'); END;
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-02068: following severe error from REMOTEDB_LINK
ORA-03113: end-of-file on communication channel
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2251
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2457
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2426
ORA-06512: at line 1
SQL> drop materialized view B;
Materialized view dropped.
SQL> create materialized view B refresh fast as
2 select col1 from A@ims_link;
Materialized view created.
SQL> exec dbms_mview.refresh('B');
PL/SQL procedure successfully completed.Which seems to replicate your problem rather well, I think.
I don't know if there are any workarounds for this. I mean, obviously you can miss out the CLOB column in your 'create MV' statement as I just did, but I don't know whether you are even allowed or supposed to be able to create an MV on lob columns and that patch such-and-such will let you do it. Maybe someone else can provide that information.
But at least you won't have to play Russian roulette with your init.ora parameters!

Fast Refresh mview performance

Hi,
I'm actually facing with Fast Refresh Mview performace problems and i would like to know what is the possible improvments for the fast refresh procedure:
- base table is 1 500 000 000 rows partitions by day , subparttion by has (4)
- mlog partition by hash (4) with indexes on pk and snaptime
- mview partition by day subpartition by hash (4)
10 000 000 insertions / day in base table/mlog
What improvment or indexes can i add to improve fast refresh ?
Thanks for help

Hi,
Which DB version are you using?
Did you have a look at the MV refresh via Partition Change Tracking (PCT)?
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/advmv.htm#sthref575
If it's possible to use PCT, it would probably improve a lot the performance of the refresh of your MV.
Regards
Maurice

Fast Refreshable MVIEW

Trying to create a fast refresh materialized view based on a simple join of two tables over a database link oracle gives a 'COMPLEX QUERY' error (ORA-12015).
Logging on the origin tables should be ok as creating the MVIEW based on the same select but in the database where the origin tables are poses no problem. The logging tables are created based on primary key and include rowid.
The select on which the MVIEW should be created is someting like:
select
tab1.rowidn id1,
tab2.rowidn id2,
tab1.key_idn key1,
tab2.key_idn key2
from table1@other_db tabl,table2@other_db tab2
where tab1.key_idn = tab2.key_idn)
Does this mean it is impossible to create a fast refresh materialized view over a database link when a join condition is involved?

Replace the ANSI Joins with Conventional Joins.
Change this :
SELECT * FROM V_FIRST VF
LEFT JOIN R4
ON VF.ID=R4.ID
LEFT JOIN R5
ON VF.ID=R5.IDto this :
SELECT VF.* FROM V_FIRST VF, R4, R5
WHERE VF.ID=R4.ID
AND VF.ID=R5.IDHemant K Chitale

Problem in fast refreshing nested materialized views

Hi all,
While developing an ODS(Operational Data Store) system, i've created base materialized views from production database to ODS database which would use fast refresh. Now, i need to create nested Materialized views on these base MViews which contains joins and aggregations which should refresh on FAST mechanism.
But while doing so, got several problems though Nested materialized views can be built using Complete Mechanism. The reporting queries is important and we want it should not hit the production database, rather it should hit the ODS db. But we are failing to build the Nested Materialized views which works on FAST.
I tried google, oracle docs but all in vain. i tried to do a simple testing which also failed. I would be grateful if anyone can help in in this regard. I'm attaching the test case experimented,
SCOTT >CREATE MATERIALIZED VIEW LOG ON EMP
2 WITH ROWID, SEQUENCE(EMPNO, ENAME, JOB,
3 MGR, HIREDATE, SAL,
4 COMM, DEPTNO)
5 INCLUDING NEW VALUES;
Materialized view log created.
Elapsed: 00:00:00.03
SCOTT >
SCOTT >CREATE MATERIALIZED VIEW LOG ON DEPT
2 WITH ROWID, SEQUENCE(DEPTNO, DNAME, LOC)
3 INCLUDING NEW VALUES;
Materialized view log created.
Elapsed: 00:00:00.06
SCOTT >
SCOTT >CREATE MATERIALIZED VIEW MV_EMP
2 NOCACHE
3 ENABLE ROW MOVEMENT
4 NOLOGGING
5 NOCOMPRESS
6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
7 BUILD IMMEDIATE
8 REFRESH FAST ON DEMAND
9 WITH ROWID
10 ENABLE QUERY REWRITE
11 AS
12 SELECT * FROM EMP;
Materialized view created.
Elapsed: 00:00:00.21
SCOTT >
SCOTT >CREATE MATERIALIZED VIEW MV_DEPT
2 NOCACHE
3 ENABLE ROW MOVEMENT
4 NOLOGGING
5 NOCOMPRESS
6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
7 BUILD IMMEDIATE
8 REFRESH FAST ON DEMAND
9 WITH ROWID
10 ENABLE QUERY REWRITE
11 AS
12 SELECT * FROM DEPT;
Materialized view created.
Elapsed: 00:00:00.14
SCOTT >CREATE MATERIALIZED VIEW LOG ON MV_EMP
2 WITH ROWID, SEQUENCE(EMPNO, ENAME, JOB,
3 MGR, HIREDATE, SAL,
4 COMM, DEPTNO)
5 INCLUDING NEW VALUES;
Materialized view log created.
Elapsed: 00:00:00.04
SCOTT >
SCOTT >CREATE MATERIALIZED VIEW LOG ON MV_DEPT
2 WITH ROWID, SEQUENCE(DEPTNO, DNAME, LOC)
3 INCLUDING NEW VALUES;
Materialized view log created.
Elapsed: 00:00:00.03
SCOTT >
SCOTT >CREATE MATERIALIZED VIEW MV_EMP_DEPT
2 NOCACHE
3 ENABLE ROW MOVEMENT
4 NOLOGGING
5 NOCOMPRESS
6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
7 BUILD IMMEDIATE
8 REFRESH FAST ON DEMAND
9 WITH ROWID
10 ENABLE QUERY REWRITE
11 AS
12 SELECT D.ROWID DEPT_ROWID, E.ROWID EMP_ROWID, E.ENAME, D.DNAME, D.LOC, E.JOB, E.SAL
13 FROM MV_EMP E,
14 MV_DEPT D
15 WHERE E.DEPTNO=D.DEPTNO;
FROM MV_EMP E,
ERROR at line 13:
ORA-12053: this is not a valid nested materialized view
Elapsed: 00:00:00.17
SCOTT >
SCOTT >CREATE MATERIALIZED VIEW MV_EMP_DEPT
2 NOCACHE
3 ENABLE ROW MOVEMENT
4 NOLOGGING
5 NOCOMPRESS
6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
7 BUILD IMMEDIATE
8 REFRESH FORCE ON DEMAND
9 WITH ROWID
10 ENABLE QUERY REWRITE
11 AS
12 SELECT D.ROWID DEPT_ROWID, E.ROWID EMP_ROWID, E.ENAME, D.DNAME, D.LOC, E.JOB, E.SAL
13 FROM MV_EMP E,
14 MV_DEPT D
15 WHERE E.DEPTNO=D.DEPTNO;
Materialized view created.
Elapsed: 00:00:00.25
SCOTT >
SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_EMP','F');
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.04
SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_DEPT','F');
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.04
SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_EMP_DEPT','F');
BEGIN DBMS_MVIEW.REFRESH('MV_EMP_DEPT','F'); END;
ERROR at line 1:
ORA-12004: REFRESH FAST cannot be used for materialized view "SCOTT"."MV_EMP_DEPT"
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2254
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2460
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2429
ORA-06512: at line 1
Elapsed: 00:00:00.11
SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_EMP_DEPT','C');
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.35
SCOTT >

Sorry,
By mistake this got posted in the CERTIFICATION forum,
you can view the same question in the following link:
Problem in fast refreshing nested materialized views

IS ORACLE HELPLESS IN REFRESHING COMPLEX MVIEW FAST??

I have a mview with a complicated query.But I need to refresh it fast on commit.I would be grateful if you people could solve this prob anyway.My mview script is given below..
SELECT TAS.ANSWER_SET_ID ALGORITHM_ID,
          TAS2.ANSWER_SET_ID RULE_ID, TAS2.CODEVAL1 SEQUENCE_NO,
     DE.EFFECTIVE_FROM_DATE EFFECTIVE_DATE,
          DE.ALPHANUMERIC_CODE_VALUE STATUS,
     MN1.MESSAGE_TEXT STAT_CODE,
          MN2.MESSAGE_TEXT CREDIT_PERCENTAGE,
          MN3.MESSAGE_TEXT DEBIT_PERCENTAGE,
     MN4.MESSAGE_TEXT CREDIT_DOLLAR,
          MN5.MESSAGE_TEXT DEBIT_DOLLAR,
          MN6.MESSAGE_TEXT ELEMENT_INCLUDED_IN,
     MN7.MESSAGE_TEXT PREMIUM_BASED_ON,
          MN8.MESSAGE_TEXT PREM_RATING_ELEMENT,
     EXP1.MESSAGE_TEXT EXPIARY_DATE
FROM T_RULE_CONTEXT RC,
          T_ANSWER_SET TAS,
          T_ANSWER_SET TAS1,
     T_ANSWER_SET TAS2,
     T_DECISION_PARAMETER DP,
          T_DECISION_EXPRESSION DE,
     T_DECISION_MESSAGE DM1,
          T_DECISION_MESSAGE DM2,
          T_DECISION_MESSAGE DM3,
     T_DECISION_MESSAGE DM4,
          T_DECISION_MESSAGE DM5,
          T_DECISION_MESSAGE DM6,
     T_DECISION_MESSAGE DM7,
          T_DECISION_MESSAGE DM8,
     (SELECT MESSAGE_NOTE_ID, DM4.ANSWER_SET_ID FROM T_DECISION_MESSAGE DM4, T_ANSWER_SET TAS2 WHERE DM4.ANSWER_SET_ID = TAS2.ANSWER_SET_ID AND MESSAGE_NAME='EXPIARY_DATE') EXP,
     T_MESSAGE_NOTE MN1,
          T_MESSAGE_NOTE MN2,
          T_MESSAGE_NOTE MN3,
     T_MESSAGE_NOTE MN4,
          T_MESSAGE_NOTE MN5,
          T_MESSAGE_NOTE MN6,
          T_MESSAGE_NOTE MN7,
          T_MESSAGE_NOTE MN8,
     (SELECT DM5.MESSAGE_NOTE_ID A, DM5.ANSWER_SET_ID, MN4.MESSAGE_NOTE_ID B, MESSAGE_TEXT FROM T_DECISION_MESSAGE DM5, T_ANSWER_SET TAS3, T_MESSAGE_NOTE MN4 WHERE DM5.ANSWER_SET_ID = TAS3.ANSWER_SET_ID AND DM5.MESSAGE_NAME='EXPIARY_DATE' AND DM5.MESSAGE_NOTE_ID = MN4.MESSAGE_NOTE_ID(+)) EXP1
WHERE      RC.CONTEXT_NAME = 'ALGORITHMS'
AND      RC.QUESTION_SET_ID = TAS.QUESTION_SET_ID_PARENT
AND      TAS1.CODEVAL1 = 'NO'
AND      TAS1.QUESTION_SET_ID_PARENT(+) = TAS.QUESTION_SET_ID_CHILD
AND      TAS1.QUESTION_SET_ID_PARENT IN
                         (SELECT QUESTION_SET_ID_CHILD
                         FROM T_RULE_CONTEXT , T_ANSWER_SET
                         WHERE RC.CONTEXT_NAME = 'ALGORITHMS'
                         AND QUESTION_SET_ID = QUESTION_SET_ID_PARENT)
AND      TAS2.QUESTION_SET_ID_PARENT = TAS1.QUESTION_SET_ID_CHILD
AND      DP.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DE.DECISION_PARAMETER_ID = DP.DECISION_PARAMETER_ID
AND      DM1.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DM2.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DM3.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DM4.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DM5.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DM6.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DM7.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      DM8.ANSWER_SET_ID = TAS2.ANSWER_SET_ID
AND      TAS2.ANSWER_SET_ID = EXP.ANSWER_SET_ID(+)
AND      DM1.MESSAGE_NAME = 'STAT_CODE'
AND      DM2.MESSAGE_NAME = 'CREDIT_PERCENTAGE'
AND      DM3.MESSAGE_NAME = 'DEBIT_PERCENTAGE'
AND      DM4.MESSAGE_NAME = 'CREDIT_DOLLAR'
AND      DM5.MESSAGE_NAME = 'DEBIT_DOLLAR'
AND      DM6.MESSAGE_NAME = 'ELEMENT_INCLUDED_IN'
AND      DM7.MESSAGE_NAME = 'PREMIUM_BASED_ON'
AND      DM8.MESSAGE_NAME = 'PREM_RATING_ELEMENT'
AND      MN1.MESSAGE_NOTE_ID = DM1.MESSAGE_NOTE_ID
AND      MN2.MESSAGE_NOTE_ID = DM2.MESSAGE_NOTE_ID
AND      MN3.MESSAGE_NOTE_ID = DM3.MESSAGE_NOTE_ID
AND      MN4.MESSAGE_NOTE_ID = DM4.MESSAGE_NOTE_ID
AND      MN5.MESSAGE_NOTE_ID = DM5.MESSAGE_NOTE_ID
AND      MN6.MESSAGE_NOTE_ID = DM6.MESSAGE_NOTE_ID
AND      MN7.MESSAGE_NOTE_ID = DM7.MESSAGE_NOTE_ID
AND      MN8.MESSAGE_NOTE_ID = DM8.MESSAGE_NOTE_ID
AND      EXP.MESSAGE_NOTE_ID = EXP1.A(+)
IS THERE ANY WAY TO DO THIS OR ITS A LIMITATION OF ORACLE??

Hi,
Take a look on restrictions applied on fast refresh of materialized views:
General Restrictions:
1.) The materialized view must not contain references to non-repeating expressions like SYSDATE and ROWNUM.
2.) The materialized view must not contain references to RAW or LONG RAW data types.
Restrictions on Fast Refresh on Materialized Views with Joins Only:
1.) All restrictions from "General Restrictions on Fast Refresh".
2.) They cannot have GROUP BY clauses or aggregates.
3.) If the WHERE clause of the query contains outer joins, then unique constraints must exist on the join columns of the inner join table.
4.) If there are no outer joins, you can have arbitrary selections and joins in the WHERE clause. However, if there are outer joins, the WHERE clause cannot have any selections. Furthermore, if there are outer joins, all the joins must be connected by ANDs and must use the equality (=) operator.
5.) Materialized view logs must exist with rowids for all the base tables in the FROM list of the query.
In your case look on point 3 and 4. This might cause problems. Sort out issues relating to point 3 & 4. Then i hope that fast refreshing should work with your view.

Fast Refresh Nested Materialized View problem in ORACLE 9i 9.2.0.7

Hello
My problem is in creating fast refresh nested materialized view in oracle 9i
In below is an example of my problem
( I need to say when I run this example in Oracle 11g all things is OK )
create table ali.alitest1(id number primary key,n1 number,n2 number);
create table ali.alitest2(id number primary key,n3 number);
CREATE MATERIALIZED VIEW LOG ON ali.alitest1 WITH ROWID,PRIMARY KEY ,SEQUENCE
(n1,n2)
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LOG ON ali.alitest2 WITH ROWID,PRIMARY KEY ,SEQUENCE
(n3)
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW ali.alitest1_mv
REFRESH WITH PRIMARY KEY FAST
AS
select id,n1 from ali.alitest1;
CREATE MATERIALIZED VIEW LOG ON ali.alitest1_mv WITH ROWID,PRIMARY KEY ,SEQUENCE
(n1)
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW ali.alitest2_mv
REFRESH WITH PRIMARY KEY FAST
AS
select t1.id,t1.n1,t2.n3,t1.rowid "t1_rowid",t2.rowid "t2_rowid" from ali.alitest1_mv t1,ali.alitest2 t2 where t1.id=t2.id;
SQL Error: ORA-12053: this is not a valid nested materialized view
12053. 00000 - "this is not a valid nested materialized view"
*Cause: The list of objects in the FROM clause of the definition of this
materialized view had some dependencies upon each other.
*Action: Refer to the documentation to see which types of nesting are valid.
do you know what is problem ?
thanks

Take look for this link :
http://rwijk.blogspot.com/2009/08/fast-refreshable-materialized-view.html

Fast refreshable mviews vs. cdc

im currently working on a new data warehouse environment. i need to create an ods schema for each of the operational systems in my warehouse.
i've looked at two of 10gR2 prefered technologies for this task:
fast refreshable materialized view and change data capture.
i would to know what is the difference between this two approaches.
in my understanding, there both cause a performance overhead and require some amount of additional work on each dml operations. in addition , there both work on the method of capturing changes from a table and applying them on a target database.
the only difference i could think of is that cdc capture changes from the redo log so that commit time on the operational system wont be affected (as much as it would when logging a dml operation in a mview log).

dba_snapshot_refresh_times or dba_mview_refresh_times would help.
select job, last_date last_refresh, next_date next_refresh, total_time,what from dba_jobs where what like '%dbms_refresh%'
This will work only if the refresh is scheduled to run through job queue.

Error when try to Fast Refresh Mview ......

Guys d u have an idea .....
why when I running job that fast refresh an mview.
I alwayas got error :
ORA-12008: error in materialized view refresh path
ORA-01555: snapshot too old: rollback segment number 2268 with name
"_SYSSMU2268$" too small
undo_management set to AUTO.
undo tablespace has enough space.
I have mview log on master database.
regards,
indrajati

damorgan's request for more information is completele relevant.
However, "Snapshot to old" is often due to insufficient rollback/undo space. What happens (grossly simplified) is that when re-reading stored data the database finds it has been overwritten and raises the error. The suggested fix is usually to increase rollback/undo space.

How much time My FAST refreshable MVIEWS taken to refresh in last refresh?

How to find the DURATION of last FAST refresh of MVIEWS?
Refresh duration will vary depends on data change on base table. I would like to find the duration of last refresh

dba_snapshot_refresh_times or dba_mview_refresh_times would help.
select job, last_date last_refresh, next_date next_refresh, total_time,what from dba_jobs where what like '%dbms_refresh%'
This will work only if the refresh is scheduled to run through job queue.

Fast refresh Mview

hi
plz tell me why am not able to create a Fast refresh materialized View
SQL> CONNECT SCHEMA1/SCHEMA@HOST;
Connected.
SQL> CREATE MATERIALIZED VIEW LOG ON COMPANY WITH PRIMARY KEY;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW LOG ON EMPLOYEE WITH PRIMARY KEY;
Materialized view log created.
SQL> GRANT SELECT ON MLOG$_COMPANY TO SCHEMAREP;
Grant succeeded.
SQL> GRANT SELECT ON MLOG$_EMPLOYEE TO SCHEMAREP;
Grant succeeded.
SQL> CONNECT SCHEMAREP/REPORTS@HOST;
Connected.
SQL>
SQL> CREATE MATERIALIZED VIEW mview_1
2 REFRESH fast on DEMAND
3 AS
4 SELECT EMPLOYEE.EMPLOYEE_num
5 FROM schema1.COMPANY company,schema1.EMPLOYEE EMPLOYEE
6 WHERE COMPANY.COMPANY_ID=EMPLOYEE.COMPANY_ID;
FROM schema1.COMPANY company,schema1.EMPLOYEE EMPLOYEE
ERROR at line 5:
ORA-12052: cannot fast refresh materialized view SCHEMAREP.MVIEW_1
SQL>

You would be able to answer yourself your question, if you
a) read the restrictions for fast refresheable materialized view at
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/basicmv.htm#sthref537
b) make you familiar with the packaged procedure dbms_mview.explain_mview
Best regards
Maxim

Fast refreshable Mview question.

Hi All,
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
"CORE 11.1.0.7.0 Production"
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production
Can't we make a Fast refresh materialized view which has UNIONALL operator on REMOTE DATA BASE..?
REMOTEDB: R
TARGETDB:T
Note: all these tables are in Remote DB(R) and I want to create a Mat view on Target DB (T).
create or replace view V_FIRST
As
select * from R1
UNION ALL
select * from R2
UNION ALL
select * from R3Now i am creating a Fast refresh Mat view
CREATE MATERIALIZED VIEW REMOTE_MV
REFRESH FAST ON DEMAND AS
SELECT * FROM V_FIRST VF
LEFT JOIN R4
ON VF.ID=R4.ID
LEFT JOIN R5
ON VF.ID=R5.IDHere i am getting error can not create a fast refreshable mat view on a complex query.
I think we can create a fast refreshable Mat view which has UNION ALL operator... I don't know about remote tables.
How to achieve this... with out splitting the Mat view ?. Is there any way..?
Appreciate your help.
Thanks,
Mike

Replace the ANSI Joins with Conventional Joins.
Change this :
SELECT * FROM V_FIRST VF
LEFT JOIN R4
ON VF.ID=R4.ID
LEFT JOIN R5
ON VF.ID=R5.IDto this :
SELECT VF.* FROM V_FIRST VF, R4, R5
WHERE VF.ID=R4.ID
AND VF.ID=R5.IDHemant K Chitale

MLOGS not purge after a fast refresh (Materialized view) ...

Hi,
I have a database on my own site (Quebec) that has 36 materialized views refresh by a master table site that is physically at Montreal. The MVIEWs are refreshed every day of the week (monday to friday) at 7h00 until 19h00. We use the "fast refresh" technic to refresh the materialized views.
Last weekend, I transfered this database on a new server. So, I created a new SID (I rename the old SID "ORCL" by "ATQP") and I created this instance with a DB_BLOCK_SIZE of 16k rather than 8k. It's the only difference between the two instances (the old one and the new one). I also created the owner schema "ATQP" and I made an Export on the old server followed by an Import of the schema that owned the Materialized views (not a Full import) on the new server. The export was made many hours (saturday morning) after the last refresh of the week (friday, at 19h00) on the old server.
After the successul import on my new server, I'm looking for the information about the creation of the MVIEW. Everything seems OK. I can see that the last refresh date indicated "2008-02-22 19:00" (date / time of the last refresh of the week). I made a quick test on a small MVIEW (a fast refresh) and it worked, no error.
Yesterday morning, the DBA of the master table site mentionned us that the DELETE on the MLOGS didn't work on the master site. The refresh was made successfully but the MLOGS continue to grow up, again and again ... On my database, I'm looking in the SYS.SNAP$ table and I saw that the SNAPTIME date is '1950-01-01 12:00' rather than '2008-02-25 19:00'. In the SYS.SNAP_REFTIME, the SNAPTIME is OK but the LOADERTIME column contains the same strange date '1950-01-01 12:00'.
I made a quick check on my old server and the SYS.SNAP$ table is empty !!! I think it's normal because the last refresh on this node was made last friday night and I made the transfert last saturday (I shutdown the old database after).
I know how to solve the problem, by recreate the MVIEW, but it causes a big problem for us. We are in PRODUCTION and we don't want to refresh many millions of records. I think it will take a couple of days to refresh all the materialized views of my schema. And it doesn't sound good by the master table site management team ...
The master table site "rush" us to solve the problem before the weekend. They don't want that we overcharge the network link between them and us by refreshing those MVIEWS.
So, is it possible to make something simple to resynchronized the SNAPTIME date without refreshing completely all the materialized views ?
If the master site table recreate the MLOG (purge manually), is it possible that it will solve our problem ?
Is it also possible to recreate the MVIEW without refreshing the data (specify to Oracle to recreate the MVIEW but indicate that the table associated already exist) ?
All of my materialized view are up to date concerning the data. I don't want to refresh all of it.
Thank's in advance ...

Hi Justin,
The DBA of the master table site sent me a email about the fact he unregistered the MVIEW. He told me that the script for the unregistered worked well. He tried to purge the MLOG and he got the error ORA-23424 but I think it's normal (It's what you said yesterday about the fact that the UNREGISTER command also purge the MLOGS).
So, it seems that the MLOGS are still not purged (that's what the DBA of the master table site said). I ran the following query:
SQL> select * from [email protected];
LOG_OWNER MASTER LOG_TABLE LOG_TRIGGER ROW PRI OBJ FIL SEQ INC
ATQ ALIAS_ANILOTS MLOG$_ALIAS_ANILOTS NO YES NO YES NO YES
ATQ ALIAS_INTERVENANTS MLOG$_ALIAS_INTERVENANTS NO YES NO YES NO YES
ATQ ANILOTS MLOG$_ANILOTS NO YES NO YES NO YES
ATQ CATEGORIES MLOG$_CATEGORIES NO YES NO YES NO YES
ATQ CODES_POSTAUX MLOG$_CODES_POSTAUX NO YES NO YES NO YES
ATQ COMMANDES MLOG$_COMMANDES NO YES NO YES NO YES
ATQ COMMUNICATIONS MLOG$_COMMUNICATIONS NO YES NO YES NO YES
ATQ DEPLACEMENTS MLOG$_DEPLACEMENTS NO YES NO YES NO YES
ATQ DETAILS_STATUTS_COMMANDES MLOG$_DETAILS_STATUTS_COMM NO YES NO YES NO YES
ATQ DOMAINES MLOG$_DOMAINES NO YES NO YES NO YES
ATQ ENREGISTREMENT_LOGS MLOG$_ENREGISTREMENT_LOGS NO YES NO YES NO YES
ATQ ENREGISTREMENT_NOTES MLOG$_ENREGISTREMENT_NOTES NO YES NO YES NO YES
ATQ ESPECES MLOG$_ESPECES NO YES NO YES NO YES
ATQ EVENEMENTS MLOG$_EVENEMENTS NO YES NO YES NO YES
ATQ EVENE_DIFFERES MLOG$_EVENE_DIFFERES NO YES NO YES NO YES
ATQ IDENTIFIANTS MLOG$_IDENTIFIANTS NO YES NO YES NO YES
ATQ INTERVENANTS MLOG$_INTERVENANTS NO YES NO YES NO YES
ATQ INTERVENANTS_CLIENTS MLOG$_INTERVENANTS_CLIENTS NO YES NO YES NO YES
ATQ INTERVENANTS_SITES MLOG$_INTERVENANTS_SITES NO YES NO YES NO YES
ATQ MAX_EVENE_DIFFERES MLOG$_MAX_EVENE_DIFFERES NO YES NO YES NO YES
ATQ MESSAGES MLOG$_MESSAGES NO YES NO YES NO YES
ATQ MUNICIPALITES MLOG$_MUNICIPALITES NO YES NO YES NO YES
ATQ NEW_ANILOTS MLOG$_NEW_ANILOTS NO YES NO YES NO YES
ATQ NEW_EVENEMENTS MLOG$_NEW_EVENEMENTS NO YES NO YES NO YES
ATQ NEW_IDENTIFIANTS MLOG$_NEW_IDENTIFIANTS NO YES NO YES NO YES
ATQ NEW_SITES MLOG$_NEW_SITES NO YES NO YES NO YES
ATQ PAYS MLOG$_PAYS NO YES NO YES NO YES
ATQ PRODUCTIONS MLOG$_PRODUCTIONS NO YES NO YES NO YES
ATQ PROPRIETES_ANILOTS MLOG$_PROPRIETES_ANILOTS NO YES NO YES NO YES
ATQ PROVINCES MLOG$_PROVINCES NO YES NO YES NO YES
ATQ SITES_EXPLOITATIONS MLOG$_SITES_EXPLOITATIONS NO YES NO YES NO YES
ATQ TYPES_IDENTIFIANTS MLOG$_TYPES_IDENTIFIANTS NO YES NO YES NO YES
ATQ UTILISATEURS MLOG$_UTILISATEURS NO YES NO YES NO YES
ATQ VALEURS MLOG$_VALEURS NO YES NO YES NO YES
ATQ VALEURS_DETAILS MLOG$_VALEURS_DETAILS NO YES NO YES NO YES
ATQ VEHICULES MLOG$_VEHICULES NO YES NO YES NO YES
36 ligne(s) sélectionnée(s).
SQL>
I supposed that is the result of the MLOG of the MVIEW associated with my new server. How can I be sure that the MLOG associated with the old one are really deleted ?
Thank you

Materialized view refresh problem

Hi,
I have a materialized view which refreshes every 12 hour. Very often (not always) the refresh fails with the following error in the alert log.
What could be the reason behind this and how to rectify this?
Errors in file /d1/oracle/proddb/9.2.0/admin/PROD_d1/bdump/prod_j000_844222.trc:
ORA-12012: error on auto execute of job 624
ORA-12008: error in materialized view refresh path
ORA-08103: object no longer exists
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 860
ORA-06512: at "SYS.DBMS_IREFRESH", line 683
ORA-06512: at "SYS.DBMS_REFRESH", line 195
ORA-06512: at line 1
Regards,
Anand

Important error descriptions are as follows. Follow actions here.
ORA-12008 error in materialized view refresh path
Cause: Table SNAP$_mview_name reads rows from the view MVIEW$_mview_name, which is a view on the master table (the master may be at a remote site). Any error in this path will cause this error at refresh time. For fast refreshes, the table master_owner.MLOG$_master is also referenced.
Action: Examine the other messages on the stack to find the problem. See if the objects SNAP$_mview_name, MVIEW$_mview_name, mowner.master@dblink, mowner.MLOG$_master@dblink still exist.
ORA-08103 object no longer exists
Cause: The object has been deleted by another user since the operation began.
Action: Remove references to the object.
-aijaz

Mview Fast Refresh Problem

Similar Messages

Maybe you are looking for