Materialized views Refresh method and refresh option

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

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

• 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

• 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

• 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

• 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

• 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

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

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

• 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

• Create Materialized view and Materialized view log.

  I wanted to create a materialized view with option "REFRESH QUICKLY YOU COMMIT".

  (1) table 1 - it is partitioned range + list - added primary key

  (2) View1 - having primary keys on the base table of view

  Steps to follow:

  (1) create the materialized on Table1; view journal -primary key by default

  (2) create the materialized on view1 view log.  -It gives below error.

  ORA-00942: table or view does not exist

  I wanted to create Materialized view as below

  create a materialized view

  Quickly REFRESH ON validation

  as

  Select...

  ........

  ... from table1

  where c1 (select c1 from View1 which...);

  
  

  Question:

  (1) because I am getting above error when creating journal of MV on the view. Can one create log view MV or we create a MV newspaper on the base table of view?

  (2) to create the MV with "REFRESH QUICKLY YOU COMMIT' option, we need to have the primary key on the main tables?

  
  

  Pointers on this will be really useful.
  

  
  

  Thank you

  Prasad

  "When a materialized view is maintained by the ON COMMIT method, the time required to perform the validation can be slightly longer than usual." This is because the refresh operation is performed as part of the validation process. This is why this method may not be suitable if many users at the same time change the tables on which is based the materialized view. »

  See: basis of materialized views (refreshment options) for all the other options and how they work.