Materialized view index questions...

Hi all..


I created a view "" REFRESH FAST' "materialized on a '' remote database table' ' that has 100 million records.
Previously, I have a query that joins the local_db table and the remote_table via db_link.
After I created the MV, I use MV to joing in this query.



(1) the performance of the query has not much changed after I used MV. I was in the impression that the MV remains locally
and improves the peformace. What can I do?

(2) I intend to create indexes on the MV. It improves performance?
Should I drop and create the MV, if I create indexes on it?
I don't want to drop and create the MV all the time. Are there other options I have?


EXPLAIN THE PLAN WITH MV:
====================
SELECT STATEMENT, GOAL = ALL_ROWS      198190  45  2070
 FILTER          
  SORT AGGREGATE        1  23
   TABLE ACCESS BY INDEX ROWID  VP_OWNER  VIOLATORS  4  1  23
    INDEX RANGE SCAN  VP_OWNER  VLR_PLATE  3  1  
 HASH GROUP BY      198190  45  2070
  VIEW  SNALLADB    198189  45  2070
   HASH UNIQUE      198189  45  7245
    WINDOW SORT      198189  45  7245
     HASH JOIN OUTER      198187  45  7245
      PARTITION RANGE SINGLE      4520  44  6028
       TABLE ACCESS FULL  VP_OWNER  VIOLATIONS  4520  44  6028
      MAT_VIEW ACCESS FULL  VP_OWNER  PLATES_MV  193637  8310922  199462128
EXPLAIN THE PLAN WITH JOIN THE REMOTE TABLE:
==========================================
SELECT STATEMENT, GOAL = ALL_ROWS      4699  44  2024
 FILTER          
  SORT AGGREGATE        1  23
   TABLE ACCESS BY INDEX ROWID  VP_OWNER  VIOLATORS  4  1  23
    INDEX RANGE SCAN  VP_OWNER  VLR_PLATE  3  1  
 HASH GROUP BY      4699  44  2024
  VIEW  SNALLADB    4698  44  2024
   HASH UNIQUE      4698  44  7348
    WINDOW SORT      4698  44  7348
     NESTED LOOPS OUTER      4696  44  7348
      PARTITION RANGE SINGLE      4520  44  6028
       TABLE ACCESS FULL  VP_OWNER  VIOLATIONS  4520  44  6028
      REMOTE    PLATES  4  1  30
QUERY:
=====
 
 select viol_date, dmv_sts, lane_id, count(1) cnt, sum(rev) revenue
   from (select violation_id,
                trunc(viol_date) viol_date,
                lane_id,
                rev,
                'LP-' || (case
                  when dmv_sts in ('NDMV', 'NV-TIME') then
                   dmv_sts
                  when exists (select count(1)
                          from violators vr
                         where vr.lic_plate_nbr = vt.lic_plate_nbr
                           and vr.lic_plate_state = vt.lic_plate_state
                           and vt.viol_date between vr.usage_begin_date and
                               nvl(vr.usage_end_date, sysdate)
                         having count(1) > 1) then
                   'M-VLTR'
                  else
                   'OTHER'
                end) dmv_sts,
                business_type
           from (SELECT DISTINCT v.violation_id,
                                 v.viol_date,
                                 v.lane_id,
                                 v.toll_due rev,
                                 v.lic_plate_nbr,
                                 v.lic_plate_state,
                                 DECODE(v.origin_type,
                                        'F',
                                        'Z',
                                        v.origin_type) business_type,
                                 MIN(case
                                       when p.lic_plate_nbr is null THEN
                                        'NDMV'
                                       when p.start_date is not null and
                                            v.viol_date between p.start_date and
                                            nvl(p.end_date, sysdate) THEN
                                        'IN-DMV'
                                       ELSE
                                        'NV-TIME'
                                     end) over(PARTITION BY violation_id) dmv_sts
                   FROM violations v
                   LEFT OUTER JOIN --plates@home_dmv.world
                 vp_owner.plates_mv p -- *** I am using the MV over there
                     ON v.lic_plate_nbr = p.lic_plate_nbr
                    AND v.lic_plate_state = p.lic_plate_state
                  WHERE v.viol_date >= to_date('7/5/2007', 'MM/DD/YYYY')
                    AND v.viol_date < to_date('7/31/2007', 'MM/DD/YYYY') + 1
                    AND v.viol_status IN ('ZH', 'WJ', 'A')
                    and v.violator_id is null 
                    and v.lic_plate_state = 'TX') vt)
  group by viol_date, dmv_sts, lane_id, business_type
Thank you

You have posted more than enough times to know that you will need to provide your Oracle version 4-digit.
>
(1) the performance of the query has not much changed after I used MV. I was in the impression that the MV remains locally
and improves the peformace. What can I do?
>
Yes - drop the MV. Why did you create a MV if your tests showed that it did not provide an advantage?
>
(2) I intend to create indexes on the MV. It improves performance?
Should I drop and create the MV, if I create indexes on it?
I don't want to drop and create the MV all the time. Are there other options I have?
>
Why "do you plan to create indexes on the MV? Your statement in #1 said you that the MV will not provide any advantage.
>
Can someone help me please with this question...
>
What question? You have not presented any issue to help with.

We must STOP focusing on a solution and return to determine what the problem or even if you have a problem.

1. determine and document the existence of a problem.
2. determine the cause of the problem
3. identify possible solutions that will eliminate or alleviate the problem
4. Select one or two options for further evaluation and testing
5. implement your solution 'better '.

You seem to be in step #5 but have not posted something that indicates you did steps 1-4.

Display detailed information on steps 1 and 2.

Tags: Database

Similar Questions

  • MATERIALIZED view - index

    How can I check if a materialized view has a defined index (and what is the index)?

    Thank you.
    Leah

    Hello
    Go to the database and look at the object code.
    or run this select:

    Select * from
    dba_indexes one
    where a.table_name like '% name % MV '.

  • Questions on the tables of materialized views and MV newspaper

    Hi all

    Have some questions about Materialized View.

    (1) once the materialized view reads the records from the table MLOG, reviews the MLOG get purged. fix? or is that not the case? In some cases, I see still (old) records in the MLOG table even after updating MV.

    (2) how the table MLOG distinguishes between a reading which comes from a MV and a reading that comes from a user? If I execute manually
    "Select * < table MLOG > ' could get record of the table MLOG redacted all the same way as it does after a refresh of MV?

    (3) one of our MV updates crashes intermittently. Based on the events of waiting I noticed that it was a 'db file sequential read' against the main table. Finally I had to put an end to the update. I don't know why it was sequential reading on the main table when she should be reading the table MLOG. Any ideas?

    (4) I saw 'file db scattered read' (full table scan) usually on tables, but I was surprised to see 'db file sequential read' against the table. I thought sequential read occurs normally against the index. All the world has noticed this behavior?

    Thanks for your time.

    (1) once all the registered materialized views have read a particular line in a trunk of materialized view, it is removed, Yes. If there are multiple materialized views that are based on the same newspaper, they would all need to refresh before it would be safe to delete the log entry for MV. If one of the materialized views is no incremental updating, there may be cases where the log purge automatically.

    (2) No, your query does not cause anything be served (although you wouldn't see something interesting unless you get to implement a lot of code to analyze change vectors stored in the journal). I don't know the exact mechanism used by Oracle has been published, if you could go through and draw a session to get an idea of the moving parts. From a practical point of view, you just need to know that when you create an updatable materialized view fast, it will register as interested especially newspapers MV.

    (3) it depends on what is stored in the log of MV. The update process may need to recover specific table columns if your log stores just the fact that the data for a particular key changed. You can specify when you create a materialized view that you want to store specific columns or include the new clause values (with the NEW VALUES INCLUDING). It is perhaps beneficial (or necessary) for the refreshment quick process, but it would tend to increase the storage space for the materialized view log and increase the cost of the maintianing the materialized view log.

    (4) sequential reads on a table are perfectly normal - it just means that someone looking for a block of data in the table (i.e. looking a line in the table of ROWID based on the ROWID in an index or a materialized view log).

    Justin

  • 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

  • MATERIALIZED View Log Index Tablespace

    Is anyone aware of the syntax or a framework to be able to specify the index of a materialized view of the journal storage space?

    We chunk our objects by tablespace - index, tables, CLOB.

    Creating a materialized view log and specifying the storage space in which it should be created created the mv log in the correct location, but the index that is created uses the default tablespace for the user.

    And Yes, I Googled it. LMGTFY

    create materialized view log on MY_TEST tablespace my_tablespace ;
    

    select table_name, tablespace_name
      from user_tables
     where table_name like 'MLOG%';
    

    TABLE-NAMETABLESPACE_NAME
    MLOG$ _MY_TESTMY_TABLESPACE

    select table_name, index_name, tablespace_name
      from user_indexes
     where table_name like 'MLOG%';
    

    TABLE-NAMEINDEX_NAMETABLESPACE_NAME
    MLOG$ _MY_TESTI_MLOG$ _MY_TESTUSERS

    I found these documents:

    Index on MLOG$ (materialized view Log): difference in behavior between 11.2.0.3 and 11.2.0.4 (Doc ID 1959657.1)

    Materialized View Log (Mlog$) Index not created in its default Tablespace (Doc ID 1959658.1)

    I guess you are running 11.2.0.4, right?

    In previous versions, no index has been created automatically for the journal of MV.

    Kind regards

    Bashar

  • Materialized view questions...

    Hi all..

    Please help me with the following question on the materialized view.
    I need to create a MV on my LOCAL_DB on a table that is located on REMOTE_DB.
    Should I created the log of the view materialized in the '' REMOTE_DB".

    1)

    Are there disadvantages in using materialized views? I mean, there is no maintenance required
    When the database has stopped or

    2)
    «I create view materliazied as "" select * from table_name "»»
    If the base table changes, influence my materialized view.

    I have the following sqls to create the mv, please let me know if that is correct.


    -LOCAL_DATABASE
    Plates_mv CREATE MATERIALIZED VIEW
    REFRESH quickly
    START BY SYSDATE
    NEXT SYSDATE + 1
    AS SELECT * FROM plates@home_dmv.world;


    -REMOTE_DATABASE or LOCAL_DATABASE?
    CREATE MATERIALIZED VIEW LOG ON plates;

    I thank in advance.
  • Question of materialized view

    Hello
    EBS version 11.5.10.2

    I would like to know if the next materialized view is used by default EBS, or if it was built by one of our developers.
    Thank you
    select  OWNER , NAME , MASTER_OWNER , MASTER 
         from  dba_snapshot_refresh_times
         where TRUNC(last_refresh) = '13-MAR-11';
    
    OWNER      NAME                           MASTER_OWN MASTER
    ---------- ------------------------------ ---------- --------------------------------------------------
    APPS       CUST_CREDIT_MV                 AR         AR_PAYMENT_SCHEDULES_ALL

    I checked two 11.5.10 facilities. I can't find this mv. This is very probably a custom.

    Hope that answers your question,
    Sandeep Gandhi

  • How to create a complex organization Index Materialized View example

    Hello

    I have a database 11g that I'm trying to create a complex Materialized View I would make organization Index? How can I specify that I want for a primary key?
    CREATE THE RCS_STG MATERIALIZED VIEW. MV_NEXT_HOP_iot
    INDEX OF THE ORGANIZATION
    AS
    SELECT r1.resource_key, resource_key2, r2.resource_full_path_name, device_name, r2.resource_key, device_model,.
    service_telephone_number, service_package_name, telephone_number.telephone_number_key, c1.created_on
    OF network_resource r1 PARTITION (network_resource_subinterface).
    connection c1,
    network_resource r2 PARTITION (network_resource_subinterface),
    device d1,
    tn_network_resource,
    telephone_number
    WHERE r1.resource_key = c1.resource1_key
    AND c1.resource2_key = r2.resource_key
    AND d1.device_key = r2.device_key
    AND tn_network_resource.resource_key (+) = r2.resource_key
    AND telephone_number.telephone_number_key (+) = tn_network_resource.telephone_number_key
    UNION ALL
    SELECT r2.resource_key, resource_key2, r1.resource_full_path_name, device_name, r1.resource_key, device_model,.
    service_telephone_number, service_package_name, telephone_number.telephone_number_key, c1.created_on
    OF network_resource r1 PARTITION (network_resource_subinterface).
    connection c1,
    network_resource r2 PARTITION (network_resource_subinterface),
    device d1,
    tn_network_resource,
    telephone_number
    WHERE r1.resource_key = c1.resource1_key
    AND c1.resource2_key = r2.resource_key
    AND d1.device_key = r1.device_key
    AND tn_network_resource.resource_key (+) = r1.resource_key
    AND telephone_number.telephone_number_key (+) = tn_network_resource.telephone_number_key
    /

    I get an error ORA-25175: no PRIMARY KEY constraint found

    I want to say resource_key, resource_key2, and service_telephone_number as my primary key?

    user12002352 wrote:
    I'm not sure I understand your example.

    Should I do a create table iot_example in select * from 'my query above.

    Would not you other placed in front of the game that you are now (unless you can ETG and specify the index of the Organization, which I think is not the case).

    You know the query and the types of data required for the materialized view, you try to create it now. You know you want it impose a primary key constraint.

    Take this knowledge and create the table you normally create a table (columns, constraints, etc...) as I showed in my example. And then post your order to create materialized view as you now except use the syntax I have demonstrated to make use of the existing index organized table.

  • Materialized view Questions PLZ HELP!

    Hi all

    How to check the time required for a materialized view to run at a given time.
    My point of view materialized is a full refresh that runs automatically at 03:00.

    (a) I interviewed dba_jobs and dba_mview_refresh_times and matched the last_date and last_refresh to find the total time. How can I know that 80 JOBS matches my opinion MVIEW_UNION in a much easier way?

    SQL > select job, last_date, order dba_jobs total_time in last_date;
    WORK LAST_DATE TOTAL_TIME
    ---------- ----------------- ----------
    80 05/05/10 03:00:02 5255

    SQL > select name, last_refresh from dba_mview_refresh_times where owner
    NAME LAST_REFRESH
    ------------------------------ -----------------
    MVIEW_UNION 05/05/10 03:00:02



    (b) also is total_time time it took the request to run today at 03:00, that is to say he started at 03:00 and ended at all about 4:45(3+5255_msec) or is it the time it has taken since the day wherever it has been planned in dba_jobs (IE back of 1 week)

    (c) also my dosent table source contain all indexes and I created indexes on the materialized view, I want to know if the full update will recreate the indxes.

    Thanks in advance,
    Kind regards

    Index on the MV are independent of indexes on the tables in the source.

    The "container" for a MV is a table. Therefore, indexes can be created on this topic.
    A FULL refreshment made with ATOMIC_REFRESH set to FALSE would be a TRUNCATE and INSERT APPEND. The index may be updated at the end.
    A FULL refreshment made with ATOMIC_REFRESH set to TRUE would be a DELETE and INSERT. This, as it is, has notable requirements of Undo (and redo). Index, if any, would also add many more requirements Undo (and redo) and updating.
    A QUICK update is an UPDATE or INSERT. Again, the presence of indexes can have an impact. If the discount is small (ie. the proportion of the updates/news lines is low compared with the lines already present in the MV), then the index can be kept because they are (the overhead of recreating the index i would exceed overload time and undo/redo of the DML with the present indices). However, if the QUICK updates/inserts many rows update, a strategy of DROP and CREATE better index.

    Hemant K Collette
    http://hemantoracledba.blogspot.com

  • 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

  • question on MATERIALIZED VIEW and table

    Hello

    There is table (name is test123) and MATERIALIZED VIEW (the name is also test123) stored in the same pattern (the name is schema123).

    If I run sql: Select in schema123.test123; *

    I want to know the result I get data data table test123 or MATERIALIZED VIEW test123, which one of them?

    Thanks in advance!

    Hi Tao2,

    You will get the data in the table.

    Kind regards
    oraclekt

  • Question about the materialized view

    I read that Materialized Views should not be used to select the data. I thought that the whole purpose of materialized view to pre-computes joins and aggregation, so that we can recover more quickly. Please let me know your point of view. I'm working on a project of storage and using materialized in the queue views and data reports

    user637544 wrote:
    I read that Materialized Views should not be used to select the data.

    Where did you read that? As stone and others have tried to indicate, this is not the case. Note that the Data Warehousing Guide Peter links has several chapters on materialized views and their uses. Precomputing of aggregates is certainly one of these uses.

    Justin

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

  • Refresh materialized view

    Hello

    Version: Oracle 10g

    I'm not having any expertise on materialized views (now start reading about M views). A friend of mine asked this question. If we need updating the display of materialzied on ad hoc basis is all avialable API.

    For example materialized view the code (I changed the names of the objects)
    CREATE MATERIALIZED VIEW emp TABLESPACE sample NOCACHE LOGGING NOCOMPRESS NOPARALLEL BUILD IMMEDIATE USING INDEX
                TABLESPACE TS_SAMPLE_IX
    REFRESH FORCE ON DEMAND
    WITH PRIMARY KEY
    AS
    SELECT  empno
                 ,ename
              ,deptno
    FROM   [email protected];
    Thank you
    Suri

    dbms_mview?
    http://docs.Oracle.com/CD/E11882_01/AppDev.112/e25788/d_mview.htm#ARPLS027

  • Parameter DBMS_METADATA. GET_DDL out of materialized views

    Hi all.
    My version of Oracle's 10g.

    I am extracting DDL for all database objects using the DBMS_METADATA package. I use SET_TRANSFORM_PARAM to configure the output because I need a sql code simple, without information about the attributes of storage spaces, storage and segment. Everything works well except when I work with mviews object types. I can't remove the information about the attributes of the tablespace, storage or segment for materialized views.

    I would like to know if there is a problem related to this topic. Or there is something missing in my code?

    I tried to specify the type of object such as another parameter on DBMS_METADATA. SET_TRANSFORM_PARAM but not work too.
    The only parameter transform that works very well with materialized views is the SQLTERMINATOR.

    ------
    See how I did:

    declare
    CLOB vDDL;
    Start
    DBMS_METADATA.SET_TRANSFORM_PARAM (DBMS_METADATA. SESSION_TRANSFORM 'STORAGE', FALSE);
    DBMS_METADATA.SET_TRANSFORM_PARAM (DBMS_METADATA. SESSION_TRANSFORM, 'TABLESPACE', FALSE);
    DBMS_METADATA.SET_TRANSFORM_PARAM (DBMS_METADATA. SESSION_TRANSFORM, "SEGMENT_ATTRIBUTES", FALSE);
    DBMS_METADATA.SET_TRANSFORM_PARAM (DBMS_METADATA. SESSION_TRANSFORM 'SQLTERMINATOR', TRUE);

    Select dbms_metadata.get_ddl ('MATERIALIZED_VIEW', 'MV_STO020', 'HIS117_CHECK') in vDDL FROM DUAL;
    dbms_output.put_line (vDDL);
    end;
    -------
    and how the output is:

    CREATE A MATERIALIZED VIEW 'HIS117_CHECK '. "" MV_STO020 ".
    PCTFREE 10 BUNCH OF ORGANIZATION PCTUSED 40 INITRANS MAXTRANS 255 NOCOMPRESS LOGGING 1
    STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645)
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 DEFAULT USER_TABLES)
    TABLESPACE "TS_HIS117".
    IMMEDIATE CONSTRUCTION
    USING INDEX
    REFRESH THE STRENGTH TO DEMAND
    WITH A KEY PRIMARY WITH THE HELP OF DEFAULT LOCAL ROLLBACK SEGMENT
    DISABLE THE QUERY REWRITING
    IN SELECT
    STO020_MOVEMENT_LOG_ID STO020_MOVEMENT_LOG_ID
    STO020_QUANTITY STO020_QUANTITY
    STO020_DATE STO020_DATE
    STO020_BEFORE_BALANCE STO020_BEFORE_BALANCE
    STO011_PRODUCT_MOVEMENT_ID STO011_PRODUCT_MOVEMENT_ID
    ADM082_PRODUCT_ID ADM082_PRODUCT_ID
    ADM089_PRODUCT_PRESENTATION_ID ADM089_PRODUCT_PRESENTATION_ID
    STO010_MOVEMENT_TYPE_ID STO010_MOVEMENT_TYPE_ID
    STO001_STOCK_ID STO001_STOCK_ID
    STO001_TARGET_STOCK_ID STO001_TARGET_STOCK_ID
    STO003_PRODUCT_LOT_ID STO003_PRODUCT_LOT_ID
    SYS010_USER_ID SYS010_USER_ID
    EIR001_MPI EIR001_MPI
    ADM056_MEDICAL_ATTENTION_ID ADM056_MEDICAL_ATTENTION_ID
    ADM094_USE_UNIT_ID ADM094_USE_UNIT_ID
    Of
    STO020_MOVEMENT_LOG;

    Thank you in advance!

    Published by: lucporto on 08/28/2012 07:26

    The LONG data type conversion is explained on http://asktom.oracle.com if you use the search feature.
    I could not find real pointers to your original question it.

Maybe you are looking for