Monitoring materialized view refresh mode.

Hello

How can I tell if a mview (which was created with REFRESH FORCE) is being updated using quick or full mode?
Are there any v$ or similar, where I can see this info?

Oracle 10.2.0.3 is

Thanks in advance.

Hello

Select LAST_REFRESH_TYPE in the ALL_MVIEWS. This field contains the following information:

Method used for the most recent update:

-COMPLETE - last update has completed
-FAST - most recent update was fast (incremental)
-NA - materialized view don't have not yet been updated (for example, if it was created to DEFERRED payment)

Select last_refresh_type
from all_mviews
where owner = 'XXXX'
and mview_name = 'XXXXXX'
and refresh_method = 'FORCE';

Have a look here for more details:

-http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/statviews_1105.htm#i1582466

See you soon,.

Francisco Munoz Alvarez
http://www.oraclenz.com

Tags: Database

Similar Questions

PX Deq Credit: send blkd hang while the materialized view Refresh

Hi all

When we are materialized view refreshing. It takes more than 2.30 minutes. Initially, it took 1.40 minutes.

We use parallel and base are partitioned. When I checked the tkprof report I see a lot of insert query expects especially PX Deq Credit: send blkd event. When I check the ASH report that I find not just any question about MV was running but always refresh MV was going on

TKPROF: Release 11.2.0.1.0 - Development on Wed Jun 5 16:27:29 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Trace file: CHDFCI_p001_43384918_PARALLEL.trc
Sort options: exeela  prsela  fchela  
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************


EXPLAIN PLAN option disabled.
********************************************************************************

SQL ID: 2x210q5g30m4t
Plan Hash: 2058446196
INSERT /*+ BYPASS_RECURSIVE_CHECK APPEND  */ INTO 
  "APPS"."GL_BAL_MV" SELECT * FROM 
  GL_BAL_V


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2    362.20    9372.04    1158765          0          0           0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 175     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  LOAD AS SELECT  (cr=0 pr=0 pw=0 time=0 us)
      0   PX COORDINATOR  (cr=0 pr=0 pw=0 time=0 us)
      0    PX SEND QC (RANDOM) :TQ10003 (cr=0 pr=0 pw=0 time=0 us cost=1041298 size=389555904 card=2028937)
78448967     HASH JOIN BUFFERED (cr=0 pr=1158765 pw=1158765 time=276842112 us cost=1041298 size=389555904 card=2028937)
 410944      BUFFER SORT (cr=0 pr=0 pw=0 time=492466 us)
 410944       PX RECEIVE  (cr=0 pr=0 pw=0 time=34526636 us cost=64715 size=147944250 card=1643825)
      0        PX SEND HASH :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
      0         PARTITION RANGE ALL PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
      0          TABLE ACCESS FULL GL_CODE_COMBINATIONS PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
78448967      PX RECEIVE  (cr=0 pr=0 pw=0 time=2453949696 us cost=976582 size=395060280 card=3873140)
      0       PX SEND HASH :TQ10002 (cr=0 pr=0 pw=0 time=0 us cost=976582 size=395060280 card=3873140)
      0        HASH JOIN  (cr=0 pr=0 pw=0 time=0 us cost=976582 size=395060280 card=3873140)
      0         BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0          PX RECEIVE  (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0           PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0            HASH JOIN  (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0             TABLE ACCESS FULL GL_SETS_OF_BOOKS (cr=0 pr=0 pw=0 time=0 us cost=7 size=108 card=6)
      0             TABLE ACCESS FULL GL_PERIODS (cr=0 pr=0 pw=0 time=0 us cost=24 size=44640 card=1240)
      0         PX BLOCK ITERATOR PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=976550 size=30099548160 card=627073920)
      0          TABLE ACCESS FULL GL_BALANCES PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=976550 size=30099548160 card=627073920)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PX Deq: Execution Msg                           3        0.16          0.17
  PX Deq Credit: send blkd                  1061004        1.99       5084.61
  PX Deq: Table Q Normal                     250856        2.00       2306.87
  asynch descriptor resize                        1        0.00          0.00
  Disk file operations I/O                       10        0.23          0.26
  direct path write temp                       3608        1.20        958.39
  latch free                                     26        0.02          0.19
  PX qref latch                             7647924        0.05         11.85
  direct path read temp                         578        0.43         35.19
  PX Deq Credit: need buffer                   4037        0.08          5.84



********************************************************************************

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        0      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PX Deq: Execution Msg                           3        0.47          0.75
  PX Deq: Slave Session Stats                     1        0.15          0.15


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2    362.20    9372.04    1158765          0          0           0

Misses in library cache during parse: 0

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PX Deq: Execution Msg                           3        0.16          0.17
  PX Deq Credit: send blkd                  1061004        1.99       5084.61
  PX Deq: Table Q Normal                     250856        2.00       2306.87
  asynch descriptor resize                        1        0.00          0.00
  Disk file operations I/O                       10        0.23          0.26
  direct path write temp                       3608        1.20        958.39
  latch free                                     26        0.02          0.19
  PX qref latch                             7647924        0.05         11.85
  direct path read temp                         578        0.43         35.19
  PX Deq Credit: need buffer                   4037        0.08          5.84

    1  user  SQL statements in session.
    0  internal SQL statements in session.
    1  SQL statements in session.
    0  statements EXPLAINed in this session.
********************************************************************************
Trace file: CHDFCI_p001_43384918_PARALLEL.trc
Trace file compatibility: 11.1.0.7
Sort options: exeela  prsela  fchela  
       1  session in tracefile.
       1  user  SQL statements in trace file.
       0  internal SQL statements in trace file.
       1  SQL statements in trace file.
       1  unique SQL statements in trace file.
 8986825  lines in trace file.
    9372  elapsed seconds in trace file.

When I checked the ASH report during this period. I don't see anything related to MV running.
I use parallel degree 8 to GL_BALANCES.
Please suggest.

Sarah wrote:
Hi all

When we are materialized view refreshing. It takes more than 2.30 minutes. Initially, it took 1.40 minutes.

You are showing much more than 2.30 minutes in this result tkprof - did you mean hours?

We use parallel and base are partitioned. When I checked the tkprof report I see a lot of insert query expects especially PX Deq Credit: send blkd event.

In your case, it seems as if the "PX Deq Credit: send blkd" is an inactive waiting (despite comments in the manual, which is not always true).
Plan execution tells you that you are not loading in the GL_BAL_MV at the same time (even if you select it in parallel). This means a single process must collect all the data of all the slaves of PX to insert it, so anytime 7 slaves will wait for you "PX Deq Credit: send blkd" while the eighth sends data to the query Coordinator to write to the table. (The timeout on these waiting 2 seconds - which is consistent with the max wait the values you see.)

If you can ensure that the MV and its index is declared as parallel, and you can enable parallel DML for updating, you may find that things go a lot faster.

When I check the ASH report that I find not just any question about MV was running but always refresh MV was going on

Ash can be a bit flakey with some of its reports in 11.2.0.1 - perhaps you were simply unlucky.

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2    362.20    9372.04    1158765          0          0           0

It is possible, moreover, that your plan has changed over time - there are a couple of "HASH JOIN TAMPONNÉE" in the plan, which means that the table "probe" the hash join arrives on the assembling process and is dumped to disk (if it does not fit in memory) to be reread and joined. This can consume a lot of IO and the time - as seen by the "pr = 1158765 pw = 1158765" on line 4 of your plan. It is possible that a previous plan has used a method of dissemination for the table of 'building' avoid this overload - but that the optimizer has switched plans as all data has increased.

Concerning
Jonathan Lewis

Published by: Jonathan Lewis on June 5, 2013 16:20 (formatting)

Materialized view - REFRESH to CLERK a mistake
I'm changing the mode to refresh a materialized view ON demand to COMMIT ON and I get an error:

Error in the command line: 4 column: 9
Error report:
SQL error: ORA-12054: cannot set the attribute ON COMMIT refresh for the materialized view
12054 00000 - "cannot set the refresh attribute COMMIT for the materialized view.
* Cause: The materialized view did not meet the conditions for release at the time.
* Action: Specify only valid options.

The original DDL is

--------------------
CREATE THE TEST_MV MATERIALIZED VIEW
REFRESH THE STRENGTH TO DEMAND
LIKE SOME a.field1, MAX (DECODE (a.field2, 1, field3, NULL)) lbl
FROM (SELECT field1, Field2, field3 FROM table_source GROUP BY Field1, Field2, field3) a
GROUP BY a.field1;
--------------------

and I tried

--------------------
CREATE THE TEST_MV MATERIALIZED VIEW
REFRESH FORCE THE COMMIT
LIKE SOME a.field1, MAX (DECODE (a.field2, 1, field3, NULL)) lbl
FROM (SELECT field1, Field2, field3 FROM table_source GROUP BY Field1, Field2, field3) a
GROUP BY a.field1;
--------------------

WITH ROWID option

How can I change the mode of a materialized view Refresh?

Thank you.
His 10g (10.2)

10.2.?. ?

You probably use a wrong syntax to pass through. Try using something like the following. I changed the query to use Scott emp and dept tables. You can pass your own tables and queries using them.
```
VARIABLE task_cust_mv VARCHAR2(30);
VARIABLE create_mv_ddl VARCHAR2(4000);
EXECUTE :task_cust_mv := 'cust_mv';

EXECUTE :create_mv_ddl := 'CREATE MATERIALIZED VIEW cust_mv REFRESH FAST DISABLE QUERY REWRITE AS SELECT e.empno, d.deptno, SUM(e.sal) sum_amount FROM scott.emp e, scott.dept d WHERE e.deptno = d.deptno GROUP BY d.deptno,e.empno ';

EXECUTE DBMS_ADVISOR.TUNE_MVIEW(:task_cust_mv, :create_mv_ddl);
```
I am that running on 11106 on Win xp professional SP 2.

HTH
Aman...

Materialized view refresh issue
Hi all

Oracle Version 11.1.0.7

I created a materialized view with 'FORCE' of the Refresh method and created Materialized view logs all the master tables (which are remote DB). I want to refresh this view mast too FAST. After the creation of view mast I want to manually update QUICKLY. But he gives me errors...
```
ORA-12008: error in materialized view refresh path
ORA-00942: table or view does not exist
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2545
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2751
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2720
ORA-06512: at line 2
```
But he made a FULL refresh. This time I don't get any errors. How is it, I get this error ("ORA-00942: table or view does not exist" "")... because it can successfully refreshed (COMPLETE).

y at - it something wrong with Mat view logs... ? How hard to pull of this scenario. ?... guide me.

Thank you
Mike
Your MV using a DBLink to connect to the remote DB. Should what account I use to connect remote DB? This account has right to SELECT on the MV log on the source table? A SELECT on the journal of MV in the source table must be granted explicitly.

Hemant K Collette

Materialized views Refresh method and refresh option

Hi Experts,

According to the docs, If the MV contains the following, MV is considered complex. I wonder is there any view data dictionary that indicates the type of MV? Because is very easy to the candidate a complex type mv. Because many queries contains the properties below.

http://docs.Oracle.com/CD/B28359_01/server.111/b28326/repmview.htm#i52501

http://docs.Oracle.com/CD/B28359_01/server.111/b28313/basicmv.htm

Specifically, a materialized view is considered complex if the materialized view definition query contains:

A CONNECT BY clause

An INTERSECT , MINUS , or UNION ALL operation

he DISTINCT or UNIQUE keyword

In some cases, an aggregate function, although it is possible to have an aggregation function in the query definition and always have a simple materialized view

In some cases, joins other than those in a subquery, although it is possible to have joins in the definition to interrogate and still have a simple materialized view

In some cases, a UNION operation

After that I kept going to read that I learned that when a VM is created, the refresh mode is specified according to the type of the MV. That means, using ON-DEMAND refresh mode is widespread. The documentation mentions that there isa also refresh option. My question is, is it possible to specify

ON REQUEST and FAST together?

Also, what are the differences between FULL and FAST. Ends truncate the table and fill it up again?

ON COMMIT

Refresh product automatically when a transaction which changed one of the paintings of the materialized view's retail is committed. This can be specified as the materialized view is quickly updatable (in other words, not complex). The ON COMMIT privilege is required to use this mode.

ON DEMAND

Refresh occurs when a user manually executes one of the procedures available refresh contained in the DBMS_MVIEW package ( REFRESH , REFRESH_ALL_MVIEWS , REFRESH_DEPENDENT ).

`COMPLETE`	Refreshes and recalculating the materialized view query definition.
`FAST`	Applies incremental changes to refresh the materialized view using the information recorded in the papers of the materialized view, or an SQL * Loader direct-path access or a partition maintenance operation.

FORCE

Applies FAST update if possible; otherwise, it applies COMPLETE Refresh.

NEVER

Indicates that the materialized view will not be updated with updating mechanisms.

Select * from version of v$.

Oracle Database 11 g Release 11.2.0.4.0 - 64 bit Production

Thank you

Çaglar wrote:

...

Also, what are the differences between FULL and FAST. Ends truncate the table and fill it up again?

...

Thank you

I just want to answer the truncated question. Seems that nobody covered that yet.

Answer: It depends.

If you do a full refresh, then the default is to use ATOMIC_REFRESH = TRUE.

This means that the update is done via an insert, delete , and ... Select.

You can change it to ATOMIC_REFRESH = FALSE (parameter dbms_mview.refresh).

This means that is a TRUNCATE and insert a ... Select with APPEND peak (path direct insert).

Refresh if Atomic = FALSE is considerably faster than the default. Also way less Archives of newspapers are written.

The downside is however that, during the update the MV is empty, is no longer an atomar operation!

tabletop pre-constructed - materialized view Refresh

Hi all
Please help me to learn how to work with the materialized on pre-constructed table view.
I created the table predefined:
CREATE TABLE 'MISS '. "" TMP003 ".
(
"ITEM_ID" NUMBER (10.0)
) ;
I created a materialized on predefined table view:
CREATE A MATERIALIZED VIEW "MISS." "' TMP003 ' ('ITEM_ID')
ON PREBUILT TABLE
AS SOME "COST_DETAIL_ITEMS". "' ITEM_ID ' 'ITEM_ID' TO 'MISS '. "COST_DETAIL_ITEMS"@EFLP2. EFLATBED.COM 'COST_DETAIL_ITEMS ';
I checked the amount of lines to the original source object:
SELECT count (1) you cnt OF 'MISS '. "COST_DETAIL_ITEMS"@EFLP2. EFLATBED.COM 'COST_DETAIL_ITEMS ';
CNT
-----
61047571
I checked the amount of lines to the object of my result:
Select count (1) cnt of 'MISS '. "" TMP003 ".
CNT
----------
0
I tried to update the object with the result:
DBMS_MVIEW exec. REFRESH('RATER.) TMP003');
anonymous block filled
I checked the amount of lines to my profitability after trying to update:
Select count (1) cnt of 'MISS '. "" TMP003 ".
CNT
----------
0
Please help me understand how to refresh my result object properly.
Thank you.

You will need to start by filling out the basic pre-built using table create table in select

concerning

Pravin

Randomization of materialized view refresh rate

Hi, I have several materialized view is refreshed every hour.
Now, I add a few more, and when the refresh occurs, it must now once more because it made the 9 materialized view update.
I like to shoot at random a little time between refresh.
I thought I would try something like this:

NEXT sysdate+(round(dbms_random.value(0.8,1.2),2)/24)

in my create materialized view, instruction, but it seems that such a method is not allowed.
Is there another way to do it or to take care of the performance of refresh in other ways?

Not sure what you mean.

I'll change the frequency of refresh a bit, so I will not wait too long to see an effect ;):

SQL> select * from v$version where rownum = 1
/
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
1 row selected.

SQL> create or replace view timer
as
   select sysdate + (round (dbms_random.value (0.8, 1.2), 2) / 24/60) t
     from dual
/
View created.

SQL> create materialized view mv_emp
refresh complete on demand
start with sysdate
as
select * from emp
/
Materialized View created.

SQL> declare
   x   number := 100;
begin
   sys.dbms_job.
   isubmit (job         => x,
            what        => 'dbms_refresh.refresh(''MV_EMP'');',
            next_date   => sysdate,
            interval    => '(select * from timer)',
            no_parse    => false
           );
   sys.dbms_output.put_line ('Job Number is: ' || to_char (x));
   commit;
end;
/
Job Number is: 100
PL/SQL procedure successfully completed.

SQL> select sysdate, mview_name, last_refresh_date  from user_mviews where mview_name = 'MV_EMP'
/
SYSDATE               MVIEW_NAME                     LAST_REFRESH_DATE
--------------------- ------------------------------ ---------------------
03.03.2010 14:53:49   MV_EMP                         03.03.2010 14:53:49
1 row selected.

SQL> exec dbms_lock.sleep(30) ---- wait a bit and see
PL/SQL procedure successfully completed.

SQL> select sysdate, mview_name, last_refresh_date  from user_mviews where mview_name = 'MV_EMP'
/
SYSDATE               MVIEW_NAME                     LAST_REFRESH_DATE
--------------------- ------------------------------ ---------------------
03.03.2010 14:54:19   MV_EMP                         03.03.2010 14:53:53
1 row selected.

Indexed full Materialized view Refresh
Hi Forum,

I can see materialized with a complete refresh automatically every morning.

I have 3 clues on this MV. My question is these clues will be generate automatically each time that the MV refreshes or do I need to write a script to rebuild the indexes separately?

Thanks in advance!
The index on a materialized view, like the index on a table, will be maintained when DML such as refresh occurs. You could potentially improve a full refresh speed by removing the index before the update and re-create them after the update (especially if you do a transactional refresh). But if the update happens the morning before that people are around and you have a window refresh reasonable, can you get any.

Justin

How to improve the materialized view Refresh speed?
Hello

Are there tips to improve the speed of refresh of the materialized views?
All documentation or advice are appreciated!

Thank you!
Agree with S_Lindenmayr, if possible, the fast refresh should be used to speed up the update because it syncs MV with only the changes since the previous update (instead of the refresh). To implement the Fatst update, fortunately, with 10 g +, Oracle provides a counselor with the TUNE_MVIEW procedure. Step by step to find in week 12 of the Top 20 features the famous Arup Nanda 10 g for the series of DBA http://www.oracle.com/technology/pub/articles/10gdba/week12_10gdba.html

Tarraf

Materialized view refresh all day in another database uisng link Public DB?
Hi all

Can update us the view materialized from a different database using DB link? is this possible?
I'm planning for this update of Shell scripts.
If so can also post you the code for update example.

Thank you
1. Yes, it is.
2º the best is to use a refresh Group.
3º DBMS_MVIEW. REFRESH();
or
DBMS_REFRESH. REFRESH();

http://download.Oracle.com/docs/CD/B19306_01/server.102/b14223/basicmv.htm
http://download.Oracle.com/docs/CD/B10500_01/server.920/a96567/repmview.htm
and more in tahiti and otn docs.

. :-) to help with my English is wellcome :-).

MATERIALIZED view refresh duration
All,

We have Oracle Enterprise Edition - 10.2.0.4.0 version.

We have a view, materialized with full refresh option.
We want to know how long does take to update. How is it, I can find the time to update.

I asked DBA_MVIEW_REFRESH_TIMES. It is indicative of the last updated date and time. but I need time to refresh.
Even in the DBA_MVIEWS also not able to locate the duration.
You can check how total_time increases each time it is run. Flashback query can help see the previous values.

Or you could run and time.

SQL > set timing on
SQL > exec dbms_mview.refresh ('EMP_MV');

PL/SQL procedure successfully completed.

Elapsed time: 00:00:00.29

Materialized view Refresh

Hi all
Every time I do refresh of the materialized re newspapers are themselves created, if again journal entry is off it is possible to refresh the mview?

Maybe it's worth noting that atomic_refresh-online results during surgery followed by truncation of an insertion append: so you do not have access to data so that the MV is updated - if that's ok, then the option improves performance. If you need permanent access you will need to use the standard mechanism (i.e. the followed removal of insertion).

A materialized view Refresh
appreciate your help.

How to restrict execution of the following query for an instance, to avoid going through the interconnection in a DB of RAC,
exec dbms_mview.refresh ('schema.mat_view', parallelism = > 10);

in other words, to enable all the parallel of the slaves to be run on a node.
That should do it,
```
alter session set parallel_force_local=true;
```
--
John Watson
Oracle Certified Master s/n
http://skillbuilders.com

Materialized - view Refresh in 10g FAST... update in 11g SLOW
Sorry I'm not able to stick whatever it is.

The customer left their database 10g to a database of GR 11, 2.
They created the MV in the new system and now it takes 26 hours to refresh
instead of 15 min in the old database 10 g.

Looking for a game plan for troubleshooting.

I know that I only am not much providing so please forgive me.

Where could you look first? Explain plan... Control Panel...? Let me know.

If you have a good reference that would work. The docs do not work.

Thanks in advance.

BB
>
I know that I only am not much providing so please forgive me.
>
Sorry - but this is unforgivable. ;)
>
The customer left their database 10g to a database of GR 11, 2.
>
Do you mean that they have improved their existing database to 10g to 11 GR 2? Or do you mean that they load the data into a new database of 11 GR 2?

Unless you provide more information there is no way to provide specific suggestions. What kind of MV? Are the source and MV on the same server?

If this is a new database, it can fail to indexes or constraints. The MV may initially be empty and the first update will be COMPLETED which will take much more than a differential.

Some of the objects or constraints might be invalid.

Materialized view automatically refresh? If the updating of the means how?

Materialized view refresh automatically? If the updating of the means how?

It is expected is not to ask questions of the basic documentation.

Refresh Options

When you define a materialized view, you can specify three update options: how to refresh, what kind of update and can trust constraints be used. If not specified, default values are considered as ON DEMAND , FORCE , and ENFORCED forced respectively.

The two execution modes are ON COMMIT and ON DEMAND . According to the materialized view, you create, some options may be unavailable. Update modes are described in table 8-4 .

Table 8-4 Modes of discount

Refresh the Mode	Description
`ON COMMIT`	Refresh product automatically when a transaction which changed one of the paintings of the materialized view's retail is committed. This can be specified as the materialized view is quickly updatable (in other words, no complex). The `ON` `COMMIT` privilege is required to use this mode.
`ON DEMAND`	Refresh occurs when a user manually executes one of the procedures available refresh contained in the `DBMS_MVIEW` package ( `REFRESH` , `REFRESH_ALL_MVIEWS` , `REFRESH_DEPENDENT` ).

http://docs.Oracle.com/CD/B28359_01/server.111/b28313/basicmv.htm#i1006193

Monitoring materialized view refresh mode.

Similar Questions

Refresh Options

Maybe you are looking for