How to improve the materialized view Refresh speed?

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)

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

• How to get a materialized view can freshen up after the job is 'broken '.

  We have created a materialized view some time ago with the following statement:

  create a materialized view SXV_PUB_EMPLOYEE_CERT_ALL_M

  full refresh on demand

  Start with to_date (August 30, 2009 04:00 ',' dd-mm-yyyy hh24:mi:ss') next trunc (sysdate) + (28/24)

  as

  Select sxv_emp_cert_all.*

  of sxv_employee_certification_all sxv_emp_cert_all;

  This week, we found that it had not been updated for about a month

  In dba_jobs the broken column was 'Y', next_date time something like 01-01-4000 and failures 16

  When I ran it manually by running

  DBMS_MVIEW BEGIN. REFRESH ("SXV_PUB_EMPLOYEE_CERT_ALL_M", "C"); END;

  I found that one of the columns was too small (probably one of the underlying tables columns had been extended since the creation of the materialized view)

  After the correction of what I ussied yesterday (29/08/2013) education:

  change the SXV_PUB_EMPLOYEE_CERT_ALL_M materialized view

  full refresh on demand

  Start with to_date (August 30, 2009 04:00 ',' dd-mm-yyyy hh24:mi:ss') next trunc (sysdate) + (28/24)

  After that the table dba_jobs showed me the 04:00 08/30/2013 as the date of the next

  I expected to run that night at 04:00, but there is no

  last_date column value was still of a month ago, the broken column still shows 'Y '.

  and the next date 08/30/2013 04:00 (whereas it would have been set to the 01:00 08/31/2013

  Freezes

  DBMS_MVIEW BEGIN. REFRESH ("SXV_PUB_EMPLOYEE_CERT_ALL_M", "C"); END;

  has given no mistake this time

  and in User_Mview_Analysis, the last_refresh_date column showed the time that I had run

  No idea how to do the job "unbroken" again for the view refreshes every night?

  the database is Oracle Database 10g Release 10.2.0.4.0

  Kind regards

  Remco

  Thanks for all your useful and accurate answers. but finally I found it myself

  exec dbms_job.broken (, false);

• Refresh the Materialized View constructed from an external table commit?

  Is it possible to create a materialized with Refresh view on commit built from an external table?
  
  I think the answer is "no, because there is no way for the outer table report to the view materialized it has been changed," but I would like to be sure before I tell my client who has requested the opportunity to do this (or, Alternatively, to learn how Oracle hoops I have to cross in order to operate).
  
  I can create a Refresh on demand, it is not a question of not having the necessary permissions to create the materialized view itself.

  No, you can't. The outer table is not modified in a transactional way and there no materialized view logs, so there is no event to hang in and no delta to apply.

  However, you can use dbms_scheduler observer file that will ask for the presence of a file and load the data in a table or refresh a materialized view based on the external table.

  Justin

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

• Refresh of the materialized view; Process flow

  I was wondering if anyone has used process flow to refresh the materialized view.
  
  I'm trying to use a process flow for it, either run something similar to below
  EXECUTE Dbms_refresh.Refresh ('"ODW_SRC".) "MV_SERVICE_DAILY_AUDIT" ');
  
  I try to avoid using the Scheduler of DB because I want to make sure that the process flow is not conflict with the update of a materialized view possible cause conflict more execution time of the work expected will refresh window.
  
  I guess I could use a transformation and build. but I was wondering if there is an easier way in the execution of it just line... an idea
  
  Thanks in advance for your help

  Sorry, I think that the term OWB is post mapping process, its actually an operator in an OWB mapping where you can add a procedure for example call. The procedure can do pretty much what he wants.

  See you soon
  David

• Trigger on the materialized view

  Hello

  I have the scenario based (Database 11 g):

  There is a view materialized (PERSON), which contains the ID and NAME fields. This MV is update daily with a fast refresh.

  I have a second array (NAMES), with ID and NORM_NAME. This table contains the name of the person, without special characters.

  For example, for recording / * 1 BJORN * / in the PERSON table

  I would check * 1 BJORN * / in table NAMES.

  
  

  Problem is how to fill the NAME table after the filling of the materialized view.

  I used a trigger AFTER INSERT or update, as described below, but even if I update the master table (for this purpose, update the MV), I have only to trigger inserts.

  
  

  Is there a way to implement a trigger "after update" on a materialized view, or do I need another approach?
  

  
  

  /*

  
  

  create or replace TRIGGER TRG_TESTE_MV

  AFTER INSERT OR UPDATE ON THE PERSON

  REFERENCING OLD AS OLD AGAIN AS NEW

  FOR EACH LINE

  BEGIN

  IF THE INSERTION

  INSERT THE NAMES

  VALUES

  (: NEW.id,:NEW.NAME);

  END IF;

  IF THE UPDATE CAN

  UPDATE OF NAMES

  SET NAME =: NEW.NAME WHERE ID =: NEW.id;

  END IF;

  END;

  */

  Thanks for any help

  Your trigger fires, but I doubted that you will be satisfied with the results. You really need to understand how to refresh process works before you begin creating triggers of MV:

  SQL > create table emp1 in select * from EMP
  2.

  Table created.

  SQL > create materialized view emp1 with rowid journal
  2.

  Materialized view log that is created.

  SQL > create materialized view emp1_mv
  2 fast refresh
  3 on request
  4 with rowid
  5 as
  6 select * from emp1
  7.

  Materialized view created.

  SQL > create or replace
  trigger 2 emp1_mv_biudr
  3 before inserting
  4 or update
  5 or delete
  6 on emp1_mv
  7 for each line
  Start 8
  9 insert then dbms_output.put_line ('INSERT' |: new.ename); end if;
  10 if the deletion then dbms_output.put_line ('REMOVE' |: old.ename); end if;
  11 end;
  12.

  Trigger created.

  SQL > insert
  2 in emp1 (empno, ename, sal)
  3 values(1,'X',1000)
  4.

  1 line of creation.

  SQL > validation
  2.

  Validation complete.

  SQL > set serveroutput on
  SQL > exec dbms_mview.refresh ('emp1_mv', 'f');
  INSERTION OF X

  PL/SQL procedure successfully completed.

  SQL > update emp1
  2 set sal = sal + 1
  3 where ename ('King', 'JONES')
  4.

  2 lines to date.

  SQL > validation
  2.

  Validation complete.

  SQL > set serveroutput on
  SQL > exec dbms_mview.refresh ('emp1_mv', 'f');
  INSERTION OF JONES
  INSERTION OF KING

  PL/SQL procedure successfully completed.

  SQL > delete emp1
  2 where in ename ('ALLEN', 'SMITH')
  3.

  2 deleted rows.

  SQL > validation
  2.

  Validation complete.

  SQL > set serveroutput on
  SQL > exec dbms_mview.refresh ('emp1_mv', 'f');

  PL/SQL procedure successfully completed.

  SQL >

  As you can see, refresh MV updates ever. Results update underlying table to remove/insert in MV. That's why your trigger will not give the results that you expected.

  SY.

• Re: view opaque and the materialized view

  Hi Experts,

  I want some clarification of opaque and view view in the physical layer OBIEE materialized

  -> what is the main difference between the opaque view and materialized in the RPD perspective view, we have to do this at the level of the RPD or DB.

  -> I want the list of opaque opinion and materialized in the RPD view how I should do.

  -> How opaque views will degrade the performance and how a materialized view will improve performance at the level of the report.

  -> In scenarios that we use view opaque and the view materialized (if possible with a scenario for the best permanent basis).

  Thanks in advance.

  I want some clarification of opaque and view view in the physical layer OBIEE materialized

  -> What is the main difference between opaque view and create the materialized view in the RPD point of view, we have to do this at the level of the RPD or DB.

  Opaque views is a SQL statement that is defined in the physical layer, OBIEE will use all in the construction of a SQL query. In a way it's not different from a database view, except it is set in OBIEE only. Alternatively, you can deploy an Opaque view, which pushes its definition in the database. Read more about it here: work with physical tables, Cubes and joins - 11 g Release 1 (11.1.1)

  A materialized view (MV) is a database concept where the results of a SQL statement are physicalised like a table, and therefore as OBIEE is a MV is just another physical array

  -> If I want a list of the opaque views and materialized in the RPD view how I should do.

  To find opaque views, use the function «Repository of applications» administration tool Search physical Tables and set up a filter on the Type = Select

  Screenshot: https://www.evernote.com/shard/s16/sh/5c843e47-bff1-4d4b-b847-be98f3a2ec09/cf060a6cd9805f687fa0b5b46f3f0020

  To find materialized views, you will need to query the catalog in your database (for example select object_name, object_type from user_objects where type_objet = "MATERIALIZED VIEW" ;) and compare it to the list of tables in your SPR)

  -> How opaque views will degrade the performance and how a materialized view will improve performance at the level of the report.

  A materialized view is materialized, in other words, the results are already stored in the database. This means usually there will be more efficient because all the joins and aggregations, etc. will be settled in advance.

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

• 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

• question on the materialized view unregistered on the main site

  Hello
  
  you know how one knows, on the main site, on the existence of a materialized view another site referring to other tables to a primary site. It seems registration is not required.
  
  the site main orcl1: I have a table, and a materialized view log defined on A table.
  another site orcl2: have a link db orcl1 and rapid updatable view SCOTT materialized. A_MVW (create a materialized view A_MVW cool off quickly in select * from A@orcl1)
  
  on orcl1 I perform: exec DBMS_MVIEW. UNREGISTER_MVIEW (mviewowner = > 'SCOTT', mviewname = > mviewsite, 'A_MVW' = > 'ORCL2');
  so the materialized view seems to be correctly set aside (because it no longer appears in: select * from DBA_REGISTERED_MVIEWS ;))
  But, to my surprise, I can still perform refreshes fast on A_MVW, which also remove rows from the materialized view log. So how is site orcl1 always aware of the existence of the materialized view?
  
  It seems that, registered or not to the main site, a materialized view has the same... or is not? where is it stored, on the main site, information about materialized views (especially those of quickly updatable) as local tables reffer?
  
  Thank you

  See DocIDs 258634.1, 67371.1, 1031924.6
  on Oracle's Support website.

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

• Difference between the view and the materialized view

  Hi all
  
  Can someone tell me exactly the difference between the view and materialized views?

  Hello

  View:-this is a virtual table means table is there, but in fact is not there...
  see how to create a view...

   create or replace view aaa as select * from emp; 
  

  Now, when we choose the AAA, he will show me all the data that would be returned by running a query "Select * from emp"... Thus, all data will come from table iteself.
  View in itself is nothing but just a Sql statement that is used to create the view, in this case definition is "select * from emp.
  Any update in the database table Emp which is in our case, would automatically result in the view...
  Any changes (all dml) will actually update the base table (conditions apply *)

  Now the materialized view:-this is the same as except that it is not a virtual table... This will be created separately and it will acutally hold the result of the query that is used to create it. Any subsequent changes in the base table only will be included in the opinion of M M view is refreshed...

• 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