Materialized view refresh issue

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 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!

  See also Oracle documentation: http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_mview.htm#i997194

• 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

• 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

• 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.

• Fast refresh materialized view problems

  I have two databases (A and B).
  
  In A database, user NICK has a table called COLOUR_MASTER.
  Also in this database, NICK issues creating materialized command newspaper view colour_master with the primary key, including the new values (and Yes, there is a primary key defined for this table)
  In database B, there is a link of database called A_LINK, connect, Nick, identified by password using 'dbA ';
  In database B, user IAN also creates a materialized view CM_MV cool off quickly in select * from colour_master@A_LINK
  
  This statement is done correctly, and there are several million lines in CM_MV when it's done.
  
  Immediately, IAN issued this command:
  
  Start
  dbms_mview. Refresh ('CM_MV');
  end;
  
  .. .and after a small pause, it gets the error
  
  ORA-12008: error path refresh materialized view
  ORA-02068: following sever error of A_LINK
  ORA-03113: end of file on communication channel
  
  One more + "select count (*) of colour_master@A_LINK" + subject immediately manages to return the correct number of records in the database so A 3113 is a bit misleading, I think that, in this case have crash, the database remains accessible at all times, there is no network problem (database A and B are both located in the same server so it of not like I'm trying of) connect to halfway around the globe).
  
  The only thing I can think is that there is a permissions issue causes this error. The creation of MV because is made via a link, it is not a problem of IAN see all appropriate, but once the updates come into play, it is perhaps.
  
  Any who can shed light on why I can't do the fast refresh from the view, I can create joyfully, please?

  I'm surprised no one asked you to do what is obvious: try to do a select * from colour_master@A_LINK, without that being wrapped in a create materialized MATERIALIZED view. Just do a simple select * from...

  My bet is that you will get an error ORA_22992 can not use selected from the remote tables LOB Locators . And if you can't do a simple select * in a remote table, I suspect that you can reasonably expect Fireworks when you try to create or refresh a view materialized on such a thing!

  Here's a quick test:

  In the 1 database:
  =========

  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 the 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 reproduce your problem rather well, I think.

  I don't know if there is no work around for this. I mean, obviously you can't miss the CLOB column in your statement of 'create a MV' as I just did, but I don't know if you're still allowed or expected to be able to create a MV on lob columns and that such and such correction will allow you to do. Maybe someone else can provide this information.

  But at least you won't have to play Russian roulette with your init.ora parameters!