Materialized view option

Similar Questions

• 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

• Materialized view fast refresh option

  Dear all,

  I have a vision materilized which refreshes every 5 minutes and his works well, but one of the base tables has 300 fields and I need this view refresh only when 3 of the fields of 300 has evolved.

  If anyone can help me, I understand that

  The script of my VM is:

  CREATE MATERIALIZED VIEW SCHEMA1. INVM_TARJETADEBITO_SALDOS_VM

  N OCACHE

  LOGGING

  NOCOMPRESS

  NOPARALLEL

  BUILD IMMEDIATE

  REFRESH FAST START WITH SYSDATE NEXT SYSDATE + 5/1440

  WITH THE PRIMARY KEY

  AS

  SELECT CHAMP_1, CHAMP_2, FIELD_3, FIELD_4

  OF SCHEMA1. TABLE_1 has, SCHEMA1. TABLE_2 b

  WHERE a.PK_1 = b.PK_1;

  Best regards

  Diego Nuñez

  > but one of the base tables has 300 fields and I need from this point of view, refresh only when 3 of the fields of 300 has evolved.

  You cannot set this "restriction".  If a row is updated - know if 1 single byte in a column or 300 columns are updated - the line qualifies to be propagated to the MV.

  That you can set is * that * columns are replicated in the MV.

  For the journal of MV, you can also specify which columns are referenced as columns of filter (with the WITH clause).  It is usually of the columns that use the MV and/or is the joining columns for a MV that has a join.

  Hemant K Collette

• 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

• I get "failed to set the refresh attribute COMMIT for the materialized view" when I try to create a MV using a table and another MV

  Experts,

  I'm trying to create a YOUNG refreshable ON COMMIT MV (xyz) using a table (circuit) and quickly updateable on validation MV (abc), but get an error:

  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 requirements for update to

  moment of validation.

  * Action: Specify only valid options.

  1] MV abc
  = MV abc defined as below =.

  CREATE MATERIALIZED view abc_MV

  Immediate CONSTRUCTION

  REFRESH QUICKLY YOU COMMIT using constraints of trust

  WITH ROWID AS SELECT n.*,.

  n.ROWID noderowid

  node n

  where n.nodetype in (1610000069,1610007267);

  
  

  -Above works OK and MV connect you on table node is created successfully

  =====================================================

  [ 2] Circuit Board

  ======================================================

  CREATE MATERIALIZED VIEW LOG ON Cramer.Circuit WITH SEQUENCE, ROWID ( ) -all columns of table ofcircut parentheses

  INCLUDING THE NEW VALUES;

  -More top works OK and MV connect you on table circuit is created successfully

  ======================================================
  

  
  

  
  

  [3] trying to create MV xyz
  

  ======================================================

  CREATE MATERIALIZED VIEW LOG ON cramer.abc_MV WITH SEQUENCE, ROWID ( ) -all columns of abc_MV brackets

  INCLUDING THE NEW VALUES;

  -Above works OK and log on ABC MV MV gets created successfully

  -Problematic step below

  Xyz_MV CREATE MATERIALIZED VIEW

  IMMEDIATE CONSTRUCTION

  REFRESH QUICKLY YOU COMMIT using constraints of trust

  AS

  SELECT c., c.rowid circuit_rowid, n.rowid tr_rowid

  the circuit c, abc_mv n

  where circuit2startnode = n.nodeid

  and c.rpplanId = n.rpplanId;
  ==========================================================

  Clues on how to solve this problem and make quickly updatable ON Commit MV xyz

  Thanks in advance.

  Chanchal,

  If you can read my original post carefully you may have noticed that all these restrictions will not apply in my case.

  All,

  In any case I found the solution to my problem.

  There are a few additional restrictions for materialized views multilayer

  Additional Restrictions for master materialized views

  The following types of materialized views may not be masters of editable materialized views:

  • ROWIDmaterialized views
  • Complex materialized views
  • Read-only materialized views

  I've updated the underlying MV abc below and everything worked like a charm

  CREATE MATERIALIZED view abc_MV

  Immediate CONSTRUCTION

  REFRESH QUICKLY YOU COMMIT using constraints of trust

  IN SELECT

  n.*, n.rowid noderowid, nt.rowid nodetyperowid

  the node n, nodetype_m nt

  where n.node2nodetype = nt.nodetypeid

  and nt.nodetypeid in (1610000069,1610007267);

  Note: To ADD a join without which I was getting error below (although had primary key on the table of the node)

  SQL error: ORA-23415: materialized view log for "NODE" does not save the primary key

  23415 00000 - "view the log for materialized \"%s\".\"%s\"does not save the primary key.

  * Cause: A primary key materialized view is refreshed quickly, but the

  The materialized view log does not record the primary key information.

  * Action: Use CREATING MATERIALIZED VIEW LOG... Command to add a PRIMARY KEY to

  start recording of the primary key information in the materialized view

  Newspaper.

• The Materialized View - ORA-12052: is unable to fast refresh materialized view

  Hello

  I was hitting my head all day trying to create materialized views. I have made some progress, but have hit a brick wall, unfortunately!

  Basically, I have been invited to take a view and see if I can get the benefits of performance by transforming all or part of it in materialized views. Because the underlying tables of the config is updated quite frequently, I want to fast refresh materialized views on commit. However, when I try to create a materialized view containing an outer join in an aggregated materialized view table, I get ORA-12052: is unable to fast refresh materialized view.

  I went through the documentation and also Rob van Wijkvery useful series of blogs on the topic (especially http://rwijk.blogspot.co.uk/2009/09/fast-refreshable-materialized-view.html) but have not found anything that matches. Maybe I missed something somewhere along the line, or maybe I'm asking just something completely impossible?

  My db is 11.2.0.2.

  Here's the test scripts, I've worked with that:

  drop materialized view test1_test2_mv;
  Drop materialized view test2 journal;
  drop table test2;
  Drop materialized view test1_mv newspaper;
  drop materialized view test1_mv;
  Drop materialized view test1 journal;
  drop table test1;

  create table test1 (identification number,
  type varchar2 (10),
  number of Val,
  update_time date,
  constraint t1_pk primary key (id, type, val));
  
  Insert into test1
  Select 1, 'a', 1001, sysdate - 10/24 Union double all the
  Select 1, 'b', 1003, sysdate - 9/24 Union double all the
  Select 1, 'c', 1002, sysdate - 8/24 Union double all the
  Select 1, had ', 1004, sysdate - 7/24 Union double all the
  Select 1, 'e', 1005, sysdate - 6/24 Union double all the
  Select 1, 'c', 1006, sysdate - 5/24 Union double all the
  Select 2, 'a', 1002, sysdate - 4/24 Union double all the
  Select 2, 'b', 1005, sysdate - 3/24 Union double all the
  Select 3, 'a', 1001, sysdate - 2/24 Union double all the
  Select 3, 'c', 1006, sysdate - 1/24 Union double all the
  Select 3, 'e', 1008, sysdate - 2/24 Union double all the
  Select option 4, has ', 1004, sysdate - 3/24 Union double all the
  Select 5, 'b', 1002, sysdate - 4/24 Union double all the
  Select 5, 'g', 1001, sysdate - 5/24 Union double all the
  Select 6, 'h', 1004, sysdate - 6/24 Union double all the
  Select 7, 'b', 1007, sysdate - 7/24 Union double all the
  Select 7, had ', 1001, sysdate - 8/24 double;

  commit;

  Select * from test1;

  
  CREATE MATERIALIZED VIEW LOG ON test1
  WITH rowid, primary key (update_time)
  including the new values;

  
  Test1_mv CREATE MATERIALIZED VIEW
  IMMEDIATE CONSTRUCTION
  COOL OFF QUICKLY ON COMMIT
  Did YOU SELECT id,
  MAX (case when type = "there" end of val) THAT col_a,.
  MAX (case when type = 'b', then val end) AS col_b,.
  MAX (case when type = 'c' then end val) AS col_c,.
  MAX (case when type = ' then end of val) AS col_d,
  MAX (update_time) AS update_time
  OF test1
  WHERE TYPE in ('a',
  « b »,
  « c »,
  a ')
  GROUP BY id;

  CREATE MATERIALIZED VIEW LOG ON test1_mv
  WITH rowid
  including the new values;

  
  create table test2 (identification number,
  col2 number,
  COL3 varchar2 (10),
  number of COL4,
  constraint t2_pk primary key (id));
  
  Insert into test2
  Select 1, 1, 'bob', 1 double Union all
  Select 2, 1, "sue", 1 double Union all
  Select 3, 1, 'tom', 1 double Union all
  Select 4, 1, 'jay', 1 double Union all
  Select 5, 1, 'art', 1 double Union all
  Select 6, 1, 'kay', 1 double Union all
  Select 7, 1, 'max', 1 double Union all
  Select 8, 1, 'tim', 1 double Union all
  Select 9, 1, "liz", 1 from dual;

  commit;

  
  CREATE MATERIALIZED VIEW LOG ON test2
  WITH rowid, primary key
  including the new values;

  
  Test1_test2_mv CREATE MATERIALIZED VIEW
  IMMEDIATE CONSTRUCTION
  COOL OFF QUICKLY ON COMMIT
  LIKE SOME t2.rowid,.
  T1.ID,
  T1.col_a,
  T1.col_b,
  T1.col_c,
  T1.col_d,
  T1.update_time,
  T2.col2,
  T2. COL3
  OF test1_mv t1,.
  Test2 t2
  WHERE (+) t1.id = t2.id; -symbol of outer join is not correctly displayed on the forums without space, grr!

  ORA-12052: is unable to fast refresh materialized view TEST1_TEST2_MV

  Y at - it any way I can get the materialized view fast refresh on commit or I asking the impossible?

  Add t1.rowid:

  SQL > CREATE MATERIALIZED VIEW test1_test2_mv

  2 BUILD IMMEDIATE

  3 QUICK REFRESH YOU COMMIT

  4 AS t2.rowid SELECT rid2,

  5 t1.rowid rid1,

  6 t1.id

  T1.col_a 7,.

  T1.col_b 8,.

  T1.col_c 9,.

  T1.col_d 10,

  T1.update_time 11,

  T2.col2 12,

  13 t2.col3

  14 OF test1_mv t1,

  15 test2 T2

  16 WHERE t1.id = t2.id

  17.

  Materialized view created.

  SQL > select * from test1_test2_mv

  2.

  RID2 RID1 ID COL_A, COL_B, COL_C COL_D UPDATE_TIME COL2 COL3

  ------------------ ------------------ ---------- ---------- ---------- ---------- ---------- ------------------- ---------- ----------

  AAAYB6AANAAAANDAAA AAAYB/AANAAAAN/AAA 1 1001 1003 1006 1004 25 / 06 / 2014 12:54:16 1 bob

  AAAYB6AANAAAANDAAB AAAYB/AANAAAAN/AAB 2 1002 1005 25 / 06 / 2014 1 sue 14:54:16

  AAAYB6AANAAAANDAAC AAAYB/AANAAAAN/AAC 3 1001 1006 25 / 06 / 2014 16:54:16 1 tom

  AAAYB/AANAAAAN/AAD AAAYB6AANAAAANDAAD 4 1004 25/06/2014 14:54:16 1 jay

  AAAYB6AANAAAANDAAE AAAYB / AANAAAAN / AAE 5 1002 2014/06/25 13:54:16 1 art

  AAAYB6AANAAAANDAAF AAAYB/AANAAAAN/AAG 7 1007 1009 25 / 06 / 2014 10:54:16 max 1

  AAAYB/AANAAAAN/AAH                                                                                                        1 tim

  AAAYB/AANAAAAN/AAF                                                                                                        1 kay

  AAAYB/AANAAAAN/AAI                                                                                                        1 liz

  9 selected lines.

  SQL > update of test2

  2 set col3 = "fly."

  3 where id = 7

  6 m

  1 line update.

  SQL > validation

  2.

  Validation complete.

  SQL > select * from test1_test2_mv

  2.

  RID2 RID1 ID COL_A, COL_B, COL_C COL_D UPDATE_TIME COL2 COL3

  ------------------ ------------------ ---------- ---------- ---------- ---------- ---------- ------------------- ---------- ----------

  AAAYB6AANAAAANDAAA AAAYB/AANAAAAN/AAA 1 1001 1003 1006 1004 25 / 06 / 2014 12:54:16 1 bob

  AAAYB6AANAAAANDAAB AAAYB/AANAAAAN/AAB 2 1002 1005 25 / 06 / 2014 1 sue 14:54:16

  AAAYB6AANAAAANDAAC AAAYB/AANAAAAN/AAC 3 1001 1006 25 / 06 / 2014 16:54:16 1 tom

  AAAYB/AANAAAAN/AAD AAAYB6AANAAAANDAAD 4 1004 25/06/2014 14:54:16 1 jay

  AAAYB6AANAAAANDAAE AAAYB / AANAAAAN / AAE 5 1002 2014/06/25 13:54:16 1 art

  AAAYB/AANAAAAN/AAH                                                                                                        1 tim

  AAAYB/AANAAAAN/AAF                                                                                                        1 kay

  AAAYB/AANAAAAN/AAI                                                                                                        1 liz

  AAAYB6AANAAAANDAAF AAAYB/AANAAAAN/AAG 7 1007 1009 25 / 06 / 2014 10:54:16 1 rob

  9 selected lines.

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

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

• ORA-12008: error path refresh materialized view... Bug?

  SQL> select * from v$version;
  
  BANNER
  --------------------------------------------------------------------------------
  Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
  PL/SQL Release 11.2.0.3.0 - Production
  CORE    11.2.0.3.0      Production
  TNS for Linux: Version 11.2.0.3.0 - Production
  NLSRTL Version 11.2.0.3.0 - Production
  
  SQL> drop materialized view log on test_tbl;
  
  Materialized view log dropped.
  
  SQL> drop materialized view mv_test_tbl;
  
  Materialized view dropped.
  
  SQL> drop table test_tbl;
  
  Table dropped.
  
  SQL> create table test_tbl(
    2   test_id   number(10)   primary key,
    3   test_name varchar2(10) not null)
    4  ;
  
  Table created.
  
  SQL> insert into test_tbl values (1,'bob');
  
  1 row created.
  
  SQL> insert into test_tbl values (2,'joe');
  
  1 row created.
  
  SQL> insert into test_tbl values (3,'john');
  
  1 row created.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> create materialized view log on test_tbl
    2  with primary key , rowid, sequence
    3  (
    4   test_name
    5  )
    6  including new values;
  
  Materialized view log created.
  
  SQL> create materialized view mv_test_tbl
    2  refresh fast on commit
    3  as
    4  select test_id,
    5         test_name
    6  from   test_tbl;
  
  Materialized view created.
  
  SQL> update test_tbl set test_name = 'hello' where test_id = 1000;
  
  0 rows updated.
  
  SQL> commit;
  
  Commit complete.

  OK, so it's all good. Now, if I create the log of the materialized with the possibility of COMMETTRE SNA view:
  

  SQL> drop materialized view log on test_tbl;
  
  Materialized view log dropped.
  
  SQL> drop materialized view mv_test_tbl;
  
  Materialized view dropped.
  
  SQL> create materialized view log on test_tbl
    2  with primary key , rowid, sequence
    3  (
    4   test_name
    5  ),
    6  commit scn
    7  including new values;
  
  Materialized view log created.
  
  SQL> create materialized view mv_test_tbl
    2  refresh fast on commit
    3  as
    4  select test_id,
    5         test_name
    6  from   test_tbl;
  
  Materialized view created.
  
  SQL> update test_tbl set test_name = 'hello' where test_id = 1000;
  
  0 rows updated.
  
  SQL> commit;
  commit
  *
  ERROR at line 1:
  ORA-12008: error in materialized view refresh path
  ORA-01006: bind variable does not exist
  
  
  SQL>

  Commit an update that updates no line against a main table for a single table quickly updatable materialized view results in the error above when the log of the materialized on the main table view is created with the option of COMMETTRE YVERT. I'm guessing that's not how things are supposed to work. Or am I missing something here? Someone else has encountered this before?
  
  See you soon.
  
  Published by: task on 25 January 2013 13:27

  Hi, detaching,

  Looks like that Bug ID 13910043

  Concerning
  Peter

• Refreshin materialized view

  We have created the MV in the database, how can I automatically refresh with any tool-

  Soloman simply uses a shortcut:

  1 day = 24 hours

  So he decided he wants to start tomorrow at 8. am

  That's so trunc (sysdate) = midnight + 1 day + 8 hrs

  but 1 day = 24/24
  and 8 = 8/24

  So what did = 32/24

  What factors down (divide by 8)
  4/3

  P.S. According your materialized view, you can also use the update on the validate option. Soloman gave you an option to perform a full refresh of the data.

  Published by: Keith Jamieson December 21, 2012 17:03

• Constraint in Materialized View behave oddly

  Environment
  Oracle Database 11 g Enterprise Edition Release 11.2.0.1.0 - 64 bit Production
  With partitioning, OLAP, Data Mining and Real Application Testing options
  Sagna: windows 7. on laptop computer Intel core i7.
  --------------------------------------------------------------------------------------------------------------------------
  
  create the table product_type
  (product_type_id VARCHAR2 (3) constraint product_type_pk primary key,)
  product_type_name varchar2 (100) constraint product_type_name_nn not null,
  move_inv varchar2 (1) default product_type_move_inv_nn 'Y' constraint not null,.
  generate_abc varchar2 (1) default product_type_generate_abc_nn "n" constraint not null,.
  constraint product_type_move_inv_check check (move_inv in ('Y', ' don't)).
  constraint product_type_gen_abc_check check (generate_abc in ('Y', ' don't))
  );
  
  create the table product_class
  (product_type_id VARCHAR2 (3) constraint product_class_type_id_nn not null,)
  product_class_id VARCHAR2 (3) constraint product_class_id_nn not null,
  product_class_name varchar2 (50) constraint product_class_name_nn not null,
  inv_negative varchar2 (1) default product_class_inv_negative_nn "n" constraint not null,.
  primary key constraint product_class_pk (product_type_id, product_class_id),
  Constraint product_class_by_product_type foreign key (product_type_id) refers to product_type (product_type_id).
  constraint product_class_inv_negative_chk check (inv_negative in ('Y', ' don't))
  );
  
  Create materialized view log on product_type with rowid, primary key, sequence (move_inv), including the new values;
  Create materialized view log on product_class with rowid, primary key, sequence (inv_negative), including the new values;
  
  Create materialized view prd_type_val_prd_class
  fast on validation as refresh
  Select count (*) tot_rows
  of product_type pt
  Join product_class pc
  on (pt.product_type_id = pc.product_type_id)
  where pt.move_inv = ' n and pc.inv_negative = 'Y ';
  
  ALTER table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check (tot_rows, 1);
  
  -1st sentence, expected to works
  Insert into product_type values('SAR','FARMA','N','N');
  
  commit; -WORKS fine.
  
  -sentence 2, for work
  insert into values product_class ('SAR', 'SCRIPT', 'LIQUID ', ' n');
  
  commit; -WORKS fine
  
  -sentence 3, should fail due materialized view constraint
  insert into product_class values('SAR','CAP','CAPSULES','Y');
  
  commit; -> See the constraint of the materialized view error FINE!
  
  
  Update move_inv set product_type = 'Y '; -Updated product type to allow barely 3 be ok
  
  commit; -> works very well
  
  -Re enforce the sentence to 3-> success FINE!
  
  -sentence 4, unscheduled WORK. -it supposed to show the error, due to the constraint of the materialized view, as did only 3 (first try)
  Update move_inv set product_type = 'n';
  
  commit; -WORK:(depuis ce point de l'erreur de contrainte vue matérialisée est ne montrent aucuns plus...:()
  
  
  insert into product_class values('SAR','TAB','TABLETS','Y');
  
  commit;
  
  insert into product_class values('SAR','ABC','ABCZXY','Y');
  
  commit;
  
  Select count (*) tot_rows
  of product_type pt
  Join product_class pc
  on (pt.product_type_id = pc.product_type_id)
  where pt.move_inv = ' n and pc.inv_negative = 'Y ';
  
  tot_rows
  --------------
  3
  
  No idea why it does not work as expected? Maybe I'm missing something or is this a problem? hope is not.
  
  Thank you

  Luis,

  I do not understand why your mv failed, but I tried one way I would, using an empty MV rather than with a single RWO with 0 in there. that is to say:

  create materialized view prd_type_val_prd_class
  refresh fast on commit
   as
  select pt.product_type_id
        ,pc.product_type_id pc_bc_product_type_id
        ,pc.product_class_id
        ,pc.rowid pc_row_id
        ,pt.rowid pt_row_id
  from product_type pt
     , product_class pc
  where pt.bc_product_type_id = pc.bc_product_type_id
  AND  pt.move_inv = 'N' and pc.inv_negative = 'Y';
  

  and changed the constraint to keep empty:

  alter table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check(1=0);
  

  Is it seemed to spend all of your tests

• Failure of the materialized view

  Hello
  
  I am facing problem with materialized views with full refresh option. When I run the query for the duration when Materialized view Refresh happens below:
  Select * from USER_JOBS;
  
  I see a numeric value in the chess column. How can I get more information about the failure?
  
  Thank you.

  Please check the alert.log file.

• Create Materialized View ORA-01723: columns of length zero are not allowed

  I am trying to create a materialized view that derives from a column of a function and I get: ORA-01723: columns null are not allowed.
  
  I use 10 gr 2 with the following definition (simple version):
  
  CREATE MATERIALIZED VIEW ACES
  SELECT
  function_name (column_name) alias_de_colonne
  FROM table_name;
  
  I even tried to cast it as below:
  
  CREATE MATERIALIZED VIEW ACES
  SELECT
  Cast (function_name (column_name) AS VARCHAR2 (200)) alias_de_colonne
  FROM table_name;
  
  My function has an exception to return a value, even if no value are.
  
  I looked everywhere for the solution. Someone at - there a way around this problem? I really need my function to calculate the column because it has business rules that I can't join in my definition of the materialized view. My only hope around this is to insert values into a table and then create a materialized table view, I don't want to do that if someone has a solution around this.
  
  Any help would be greatly appreciated.
  
  Thank you
  
  Kyle
  
  Published by: Kyle Miller on April 19, 2011 08:28

  Have you tried to create a table with the correct structure and then by creating the view materialized, based on the predefined table as described here...

  http://www.oaktable.NET/content/ultra-fast-MV-alteration-using-prebuilt-table-option

  ?

  See you soon

  Ben

• Materialized views or water courses

  I'm working on 11 GR 2 on Red Hat Linux
  
  I have a TBL_ADDRESS table on the DB1 database and it is an OLTP database
  

  SQL> desc TBL_ADDRESS
  
   Name                                      Null?    Type
  
   ----------------------------------------- -------- --------------------
  
  
  
   CODE_ID                                   NOT NULL NUMBER(19)
  
   ADDRESS_LINE_1                            NOT NULL VARCHAR2(100)
  
   ADDRESS_LINE_2                            NOT NULL VARCHAR2(100)
  
   CITY                                      NOT NULL VARCHAR2(40)
  
   COUNTRY                                   NOT NULL VARCHAR2(40)

  I'm working on a data warehouse that needs these details, and also must capture changes (Dimension to slow variation).
  So I'm looking at a similar to that on the DB2(Data Warehouse) database table design
  

  SQL> desc TBL_ADDRESS_HISTORY
  
   Name                                      Null?    Type
  
   ----------------------------------------- -------- --------------------
  
   CODE_ID                                   NOT NULL NUMBER(19)
  
   ADDRESS_LINE_1                            NOT NULL VARCHAR2(100)
  
   ADDRESS_LINE_2                            NOT NULL VARCHAR2(100)
  
   CITY                                      NOT NULL VARCHAR2(40)
  
   COUNTRY                                   NOT NULL VARCHAR2(40)
  
   FROM_DATE                                 NOT NULL TIMESTAMP
  
   TO_DATE                                            TIMESTAMP

  The From_Date and To_Date fields will help me determine if the data is current and also it will help me to identify the changes that have occurred in the past.
  
  To get the data in the TBL_ADDRESS table in DB1, I have two options, configuration of the watercourse or using materialized views.
  
  (1) in the case of option 1, I have the same table (TBL_ADDRESS stream) on the DB2 database configured using the replication flow from DB1 to DB2. Then I can create triggers (on TBL_ADDRESS in DB2) in order to identify changes and have full accordingly TBL_ADDRESS_HISTORY table.
  
  (2) in the case of option 2, I have materialized view implemented using the links of db that will be refreshed every few hours. Also I will have TBL_ADDRESS in the populous initially DB2 table when DW is built. Until no refreshment of the MV, I'm having a procedure that checks the data in TBL_ADDRESS and the view materialized to see if there is no change and updates another table TBL_ADDRESS_HISTORY with the old data, if there is any change, so TBL_ADDRESS will have current data and TBL_ADDRESS_HISTORY will have the old data.
  
  It seems that Option 1 is better but I have about 8 tables (which have to be met to obtain the relevant data) so I thought having 8 process of watercourse would be a little complex to maintain.
  In the case of MV, I have 1 MV who joined all the tables of 8 and is updated twice a day.
  
  Any suggestions/advice?

  What do you mean by "8 workflow process? You would have a capture process, a propagation process, and a process applies that everything that happened to work with ADR of 8 different tables. Once you have configured streams, there is no increase in complexity to add additional tables in the replication process.

  If you use feeds, why would you use the triggers for copy of changes to the ADDRESS table in the ADDRESS_HISTORY table? If it's the process that you are considering, you would be better with a custom apply Manager who just applied the LCR ADDRESS from the source system to the ADDRESS_HISTORY table in the data warehouse. Of course, in a data warehouse, I would refrain usually the ADDRESS table are replicated in place and that a separate process ETL (is not a trigger) the processed data.

  Justin

• Are materialized views in Oracle OLAP licenses. ?

  Hi all
  We use the EE Oracle 10 g 2. We try to find the list of products of Oracle 10gEE. License part materialized views in Oracle OLAP or that come with the Standard edition.
  
  Thank you

  Commerce 10.2 has a table of availability of the editing features (a SE, SE, EE) which establishes good enough differences:
  http://download.Oracle.com/docs/CD/B19306_01/license.102/b14199/editions.htm#BABJICBB

  However I don't see, documentation, its use of MV (license) is clearly defined. Basically, it seems it depends of the use of MVs.

  See, for example, Data Warehouse (syntheses) and integration - based replication. Sometimes, the documentation uses the phrase "materialized views to...» ». SQL aggregation / analytical seems to be a missing piece as well (in the current doc sets).
  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14200/statements_6002.htm
  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14223/basicmv.htm#i1006193
  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14226/repmview.htm

  The new 11g Cube materialized views feature is of course an OLAP option.

  And, as usual, you can find in the documentation, forums etc is almost irrelevant when it comes to licensing issues. You should see your specific contract. Talk to your sales person.

  "License issues really, really, really should be addressed to your representative commercial Oracle." Nothing we say here links to Oracle. We don't know other agreements, your organization may have with Oracle. ... explaining that "a guy on the internet with a card to play said logo is OK," probably won't do more good. »
  (borrowed from Oracle licenses VMware + Quadcore

  Published by: orafad on January 27, 2011 20:39