Implementation of materialized view (10.2.0.5) - more than an hour to create

A distributed query (remote several tables, several spaces), all refresh on demand. Note that I have no control over remote tables (impossible to create logs of MV, etc.) and I ask really just the difference in performance between the direct request and the MV.

My MV script:

CREATE MYSCHEMA MATERIALIZED VIEW. PRE-MEDICATION
STORAGE)
DEFAULT USER_TABLES
DEFAULT FLASH_CACHE
DEFAULT CELL_FLASH_CACHE
)
NOCACHE
NOLOGGING
NOCOMPRESS
NOPARALLEL
IMMEDIATE CONSTRUCTION
FULL REFRESH ON DEMAND
AS
< my query >

The query takes less than 2 seconds to turn, return of 600 lines. When you try to create the MV, I gave up after an hour. There is no index on the MV (of course, as I have not yet even created). The only hint in the query is to specify the table driven as the remote source.

I did not request (I'll do it if necessary) because I'm not as interested tuning the query as I am to determine why the MV would be so ridiculously slow compared to the query itself.

>
The disappointing aspect of all this is that the query is essentially made of 3 tables remote (all from the same source, probably less than 1 k lines when joined to the top) and 1 local table (table of correspondence of line 37) while straight equi-joins.
>
Your solution is obvious.

Create a local MV based ONLY on these 3 remote tables.

Then create your required local MV based on this new local MV first and your local table.

If these 3 remote lookup tables are even of the very useful by themselves and then create THREE local MVs, one for each of the remote tables.

And build your local MV required on the three new local VM and your local table.

You can add the MVs local to a group of refresh to refresh all at once with two approaches

An approach fracture rule often works well especially with as small as your tables.

Tags: Database

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)

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

  • Scalability of materialized views

    Hi all

    We strive to replicate some tables (5 Tables) in our database to a different database.
    These tables have data around 25 million records each.

    I intend to implement a Materialized view in our database pointing to the database source and fast refresh.

    The Source database will have a lot of inserts and updates on these 5 tables on a daily basis (on an average of 100K in the worst cases, inserts or updates on the source tables).

    Can anyone suggest this is the right way to do the sync to the top of the tables or is it possible to synchronize to the top.

    Appreciate your suggestions on this.

    Thank you and best regards,
    Madhu K.

    River is a part of the database as materialized views. So there is no separate download.

    Justin

  • Oracle Warehouse builder or materialized views

    I have a requirement as follows:

    Requirement:
    We must create a Reporting DB to be used for information and a transactional database will be in separate host. Fundamentally, he need to extract data from a set of transactional DB tables and move to the Reporting DB schema at adequate intervals.

    We may have to get a different column data in different tables and store it in a single table / several reports DB tables.


    Can someone whether to go with Oracle Warehouse builder or the materialized views for this offer please?
    Or use OWB to create and maintain the MVs.

    Also please me a link point to what features are available with OWB

    Our Oracle is installed in Solaris 10 and one who is perfect either generator warehouse Oracle or materialized views

    Thank you
    APPU

    Published by: user12094414 on October 25, 2009 21:52

    Published by: user12094414 on October 25, 2009 22:17

    user12094414 wrote:
    Can someone whether to go with Oracle Warehouse builder or the materialized views for this offer please?
    Or use OWB to create and maintain the MVs.

    The two are not exclusive. OWB is a tool for designing the data movement and implement updates to the warehouse.

    MVs are a tool integrated into the database in support of materialization of the current request to speed up some types of applications related to data that is availoable, perhaps after transport OWB.

    >

    Also please me a link point to what features are available with OWB

    Normal (to allow the future of mutual aid) access is

    http://OTN.Oracle.com
    -> Products (perma menu on the left): database (link)
    -> Warehouseing Bi & data (link in the middle section)
    -> Related products (product menu on the right): Warehouse Builder
    where you can get a Viewlet, whitepapers, docs, demos, tutorials, etc.

    Direct access to the page above is http://www.oracle.com/technology/products/warehouse/index.html

  • Materialized view - Alter

    Hello gurus,


    How to alter a materialized view question him with out droping? give me a small example




    Kind regards
    A friend :)

    You reference 10.1 documentation. Please see the latest version 11.2

    A MV query cannot be changed. The MV should be deleted and rebuilt.
    (think about it... How do you change a MV as the query on what is built is changed and/or columns are added/removed)?

    The documentation that you reference says:
    Use the ALTER MATERIALIZED VIEW statement to alter a materialized view existing in one or more of the following ways:

    To change its storage features

    To change its refresh, mode or time method

    To change its structure to make it another type of materialized view

    To enable or disable the query rewriting.

    Hemant K Collette

  • Create materialized view

    Hello
    I found that when oracle executes the create materialized view statement it must be longer than the duration of execution of the actual query.
    I do an IMMEDIATE CONSTRUCTION.
    Is there a reason for this?

    For example. the query in the create statement took 25 minutes and did not create the MV for 2 hours.
    The following query, which took 10 seconds was not created during more than 11 minutes and is still ongoing.
    So I want to know what the reason is behind this? pls share if you know... Thank you.

    PS:
    I have advice in the select query. Oracle uses it advice during the creation of MV too or is this the reason why it's taking the time to build the MV?

    any suggestion is appreciated. thnks!

    Published by: user254668 on January 11, 2011 08:08

    How do measure you queries?

    http://jonathanlewis.WordPress.com/2010/08/29/fair-comparison/

    Re: Question Performace and Order by
    Re: receiving ORA-01722 invalid number mistake while creating a materialized view
    Re: long term with ORDER by clause
    Re: Improve the performance of the query with the order of

  • feature not enabled: rewrite of materialized view

    Greetings,
    I created materialized views of XE by using the following code:
    CREATE materialized VIEW log ON airplane_type_list
    WITH
      rowid
      (max_seat
      ) including NEW VALUES;
    
    CREATE materialized VIEW log ON airplane
    WITH
      rowid
      (airplane_type, number_seat_booked
      ) including NEW VALUES;
    
    CREATE materialized VIEW airport_mv build immediate refresh fast ON COMMIT enable query rewrite
    AS
      SELECT 
        a.rowid "airplane_type_list_rowid",
        b.rowid "airplane_rowid",
        a.max_seat,
        b.number_seat_booked 
      FROM airplane_type_list a,
        airplane b
      WHERE b.airplane_type  = a.airplane_type
      AND b.number_seat_booked<=a.max_seat
    When I run the script, I got the following error:
    Error starting at line 11 in command:
    CREATE materialized VIEW airport_mv build immediate refresh fast ON COMMIT enable query rewrite
    AS
      SELECT a.rowid,b.rowid,
      a.max_seat,
        b.number_seat_booked 
      FROM airplane_type_list a,
        airplane b
      WHERE b.airplane_type  = a.airplane_type
      AND b.number_seat_booked<=a.max_seat
    Error at Command Line:16 Column:7
    Error report:
    SQL Error: ORA-00439: feature not enabled: Materialized view rewrite
    00439. 00000 -  "feature not enabled: %s"
    *Cause:    The specified feature is not enabled.
    *Action:   Do not attempt to use this feature.
    But when I delete "activate the rewrite of the query", the script works fine.
    Is it because I can't use the rewrite of the query to the XE?

    Kind regards
    Valerie

    Is it because I can't use the rewrite of the query to the XE?

    That is right.

    * Cause: The specified feature is not enabled.
    * Action: Try not to use this feature.

  • the materialized view error

    Hello

    Here I create a Magnier and I want to update this validation


    create materialized view log on emp
    with primary key
    including new values;
    
    create materialized view log on dept
    with primary key
    including new values;
    
    create materialized view  emp_dept_new
    refresh fast on commit 
    as select deptno from emp
    union all
    select deptno from dept;
    When I execute the last script, I get an error.


    Please help me in this issue

    Thank you
    Reddy.

    After the already mentioned restrictions, you can make it work like this:

    SQL> create table myemp as select * from emp
      2  /
    
    Tabel is aangemaakt.
    
    SQL> create materialized view log on myemp with rowid
      2  /
    
    Snapshotlog is aangemaakt.
    
    SQL> create table mydept as select * from dept
      2  /
    
    Tabel is aangemaakt.
    
    SQL> create materialized view log on mydept with rowid
      2  /
    
    Snapshotlog is aangemaakt.
    
    SQL> create materialized view emp_dept_new
      2    refresh fast on commit
      3  as
      4  select rowid rid
      5       , deptno
      6       , 1 umarker
      7    from myemp
      8   union all
      9  select rowid
     10       , deptno
     11       , 2
     12    from mydept
     13  /
    
    Snapshot is aangemaakt.
    
    SQL> select * from emp_dept_new
      2  /
    
    RID                    DEPTNO    UMARKER
    ------------------ ---------- ----------
    AAAStLAAEAAAALTAAA         20          1
    AAAStLAAEAAAALTAAB         30          1
    AAAStLAAEAAAALTAAC         30          1
    AAAStLAAEAAAALTAAD         20          1
    AAAStLAAEAAAALTAAE         30          1
    AAAStLAAEAAAALTAAF         30          1
    AAAStLAAEAAAALTAAG         10          1
    AAAStLAAEAAAALTAAH         20          1
    AAAStLAAEAAAALTAAI         10          1
    AAAStLAAEAAAALTAAJ         30          1
    AAAStLAAEAAAALTAAK         20          1
    AAAStLAAEAAAALTAAL         30          1
    AAAStLAAEAAAALTAAM         20          1
    AAAStLAAEAAAALTAAN         10          1
    AAAStNAAEAAAALjAAA         10          2
    AAAStNAAEAAAALjAAB         20          2
    AAAStNAAEAAAALjAAC         30          2
    AAAStNAAEAAAALjAAD         40          2
    
    18 rijen zijn geselecteerd.
    
    SQL> insert into mydept values (50, 'IT', 'UTRECHT')
      2  /
    
    1 rij is aangemaakt.
    
    SQL> insert into myemp values (7777, 'VAN WIJK', 'JANITOR', 7839, date '1995-12-01', 500, null, 30)
      2  /
    
    1 rij is aangemaakt.
    
    SQL> commit
      2  /
    
    Commit is voltooid.
    
    SQL> select * from emp_dept_new
      2  /
    
    RID                    DEPTNO    UMARKER
    ------------------ ---------- ----------
    AAAStLAAEAAAALTAAA         20          1
    AAAStLAAEAAAALTAAB         30          1
    AAAStLAAEAAAALTAAC         30          1
    AAAStLAAEAAAALTAAD         20          1
    AAAStLAAEAAAALTAAE         30          1
    AAAStLAAEAAAALTAAF         30          1
    AAAStLAAEAAAALTAAG         10          1
    AAAStLAAEAAAALTAAH         20          1
    AAAStLAAEAAAALTAAI         10          1
    AAAStLAAEAAAALTAAJ         30          1
    AAAStLAAEAAAALTAAK         20          1
    AAAStLAAEAAAALTAAL         30          1
    AAAStLAAEAAAALTAAM         20          1
    AAAStLAAEAAAALTAAN         10          1
    AAAStNAAEAAAALjAAA         10          2
    AAAStNAAEAAAALjAAB         20          2
    AAAStNAAEAAAALjAAC         30          2
    AAAStNAAEAAAALjAAD         40          2
    AAAStNAAEAAAALmAAA         50          2
    AAAStLAAEAAAALWAAA         30          1
    
    20 rijen zijn geselecteerd.
    

    Kind regards
    Rob.

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

  • the materialized view query

    Hello

    I had created a materialized view, it refreshes every 3 minutes. At the end of 3 minutes next time we are accessing the old records of materialized view should be deleted. Can someone help me with this query...
    create or replace materialized view deptd_mvu
         refresh fast on commit
         start with sysdate
         next sysdate + 3/(60*24)
         as select *
            from deptd;

    969052 wrote:
    No, my query shows all data are there is no error in my query? can u help me

    # It is not a mistake on your part of the implementation or Oracle. Error lies in understanding.

    Materialized view appeared in SELECT * FROM DEPT; So, it must take all the data that are available in the Dept table each time it is regenerated.

    What you intend to do is force the MView to choose the data "Modified" of table DEPT. Is not possible, unless you have some distinctive sign that the MView should be checked.

    For Eg :-(just an idea that I did not test this)

    Adding another column to identify records updated the: -.

    alter table dept add is_modified varchar2(1) default 'N';
    

    MView create instruction me altered as

    select *
      from dept
    where is_modified = 'Y';
    

    Write a trigger that sets the column IS_MODIFIED 'Y', each time that a record is inserted or updated. Don't worry about the deleted records (if this isn't a Soft Delete) as MView does not see records that are not present in the master table.

    You simply need to ensure that, whenever the MView is refreshed, the IS_MODIFIED the Department table must be set to 'n', so that it does not display a false positives.

  • 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

  • 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

  • Materialized view takes to refresh

    On Oracle 11 g 2, I created a fast refresh materialized on the validation view
    CREATE MATERIALIZED VIEW mv_case
    PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
    SELECT p.jperson_id,offense_id,CASE_SENTENCE_DATE,court_ref,CASE_COURT_ORI,
      c.CASE_VERDICT_DATE,CASE_DOCKET,c.CASE_EXPUNGED,c.jcase_id,cc.CYCLEID_ID,
      p.rowid p_rowid,xc.rowid xc_rowid,c.rowid c_rowid,cxo.rowid cxo_rowid,cc.rowid cc_row_id
    FROM jperson p,jperson_x_jcase xc,jcase c,jcase_x_offense cxo,jcase_x_cycleid cc
    where p.jperson_id = xc.jperson_id(+) and xc.jcase_id = c.jcase_id(+) 
      and c.jcase_id = cxo.jcase_id(+) and c.jcase_id=cc.jcase_id;
    create index idx_mv_case_pid on mv_case(jperson_id);
    ALTER TABLE mv_case ADD (CONSTRAINT PK_MV_CASE PRIMARY KEY(jcase_id,offense_id)) ;
    create index idx_mv_case_p_rowid on mv_case(p_rowid);
    create index idx_mv_case_xc_rowid on mv_case(xc_rowid);
    create index idx_mv_case_c_rowid on mv_case(c_rowid);
    create index idx_mv_case_cxo_rowid on mv_case(cxo_rowid);
    create index idx_mv_case_cc_rowid on mv_case(cc_row_id);
    I inserted a single line into one of the main table
    insert into jcase_x_offense (offense_id,jcase_id) values ('test_row3','test_row3');
    commit;
    The tooks to commit a fairly long. I looked in the trace file and the actual insertion took 0.01 seconds but the internel DML took most of the time. I copy the TKPROF output that is relevant for the internal DML below
    INSERT INTO QAPF.MV_CASE SELECT /*+ NO_MERGE(JV$) */ 
      MAS$4.JPERSON_ID,JV$.OFFENSE_ID,MAS$2.CASE_SENTENCE_DATE,
      MAS$2.COURT_REF,MAS$2.CASE_COURT_ORI,MAS$2.CASE_VERDICT_DATE,
      MAS$2.CASE_DOCKET,MAS$2.CASE_EXPUNGED,MAS$2.JCASE_ID,
      MAS$0.CYCLEID_ID,MAS$4.ROWID,MAS$3.ROWID,MAS$2.ROWID,JV$.RID$,
      MAS$0.ROWID 
      FROM ( SELECT MAS$.ROWID RID$  ,  MAS$.*  FROM  QAPF.JCASE_X_OFFENSE MAS$ WHERE ROWID IN 
              (SELECT  /*+ HASH_SJ */ CHARTOROWID(MAS$.M_ROW$$) RID$ 
               FROM QAPF.MLOG$_JCASE_X_OFFENSE MAS$ WHERE MAS$.XID$$ = :1 )) JV$,
      JCASE_X_CYCLEID AS OF SNAPSHOT(:B_SCN)  MAS$0, JCASE AS OF SNAPSHOT(:B_SCN)  MAS$2, 
      JPERSON_X_JCASE AS OF SNAPSHOT(:B_SCN)  MAS$3, JPERSON AS OF SNAPSHOT(:B_SCN)  MAS$4 
      WHERE (MAS$4.JPERSON_ID=MAS$3.JPERSON_ID(+) 
      AND MAS$3.JCASE_ID=MAS$2.JCASE_ID(+) 
      AND MAS$2.JCASE_ID=JV$.JCASE_ID(+) 
      AND MAS$2.JCASE_ID=MAS$0.JCASE_ID) 
      AND NOT EXISTS ( 
        SELECT 1 FROM QAPF.MV_CASE SNA2$ 
        WHERE (SNA2$.P_ROWID = MAS$4.ROWID) 
        AND (SNA2$.XC_ROWID = MAS$3.ROWID OR MAS$3.ROWID IS NULL ) 
        AND (SNA2$.C_ROWID = MAS$2.ROWID OR MAS$2.ROWID IS NULL ) 
        AND (SNA2$.CC_ROW_ID = MAS$0.ROWID OR MAS$0.ROWID IS NULL ) 
        AND JV$.RID$ IS NULL) 
      AND NOT EXISTS ( 
        SELECT 1  FROM JCASE_X_OFFENSE MAS_INNER$, JCASE AS OF SNAPSHOT(:B_SCN)  MAS_OUTER$ 
        WHERE MAS$2.ROWID = MAS_OUTER$.ROWID AND JV$.RID$ IS NULL 
        AND MAS_OUTER$.JCASE_ID=MAS_INNER$.JCASE_ID)
    
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1     99.51     364.87     377012   17412972          1           0
    Fetch        0      0.00       0.00          0          0          0           0
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        2     99.51     364.87     377012   17412972          1           0
    
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          0  LOAD TABLE CONVENTIONAL  (cr=17412968 pr=377012 pw=120527 time=0 us)
          0   FILTER  (cr=17412968 pr=377012 pw=120527 time=0 us)
    3363837    HASH JOIN RIGHT OUTER (cr=264914 pr=280254 pw=120527 time=35845080 us cost=299444 size=1029332286 card=3363831)
          1     VIEW  (cr=112490 pr=180864 pw=119722 time=0 us cost=30743 size=78 card=1)
          1      HASH JOIN SEMI (cr=112490 pr=180864 pw=119722 time=0 us cost=72627 size=208 card=1)
    11354346       TABLE ACCESS FULL JCASE_X_OFFENSE (cr=112488 pr=112447 pw=0 time=4814838 us cost=30703 size=749386770 card=11354345)
          1       TABLE ACCESS BY INDEX ROWID MLOG$_JCASE_X_OFFENSE (cr=2 pr=0 pw=0 time=0 us cost=1 size=142 card=1)
          1        INDEX RANGE SCAN IDX_MLOG$_XID_JCASE_X_OFFENSE (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 98375)
    3363837     HASH JOIN  (cr=152424 pr=99390 pw=805 time=29973970 us cost=268690 size=766953468 card=3363831)
    2994042      INDEX FAST FULL SCAN JPERSON_I0 (cr=18134 pr=0 pw=0 time=772990 us cost=17450 size=134731845 card=2994041)(object id 83738)
    3363837      HASH JOIN  (cr=134290 pr=99390 pw=805 time=25292580 us cost=212128 size=615581073 card=3363831)
    3363837       HASH JOIN  (cr=69008 pr=34127 pw=805 time=4750330 us cost=101637 size=393568929 card=3363837)
    3363837        TABLE ACCESS FULL JCASE_X_CYCLEID (cr=33337 pr=33322 pw=0 time=2942460 us cost=33569 size=222013242 card=3363837)
    6586646        TABLE ACCESS FULL JCASE (cr=35671 pr=0 pw=0 time=1584102 us cost=35988 size=335918895 card=6586645)
    6586635       TABLE ACCESS FULL JPERSON_X_JCASE (cr=65282 pr=65263 pw=0 time=5446686 us cost=65632 size=434717844 card=6586634)
    3363837    FILTER  (cr=17148054 pr=96758 pw=0 time=0 us)
    3363837     MAT_VIEW ACCESS BY INDEX ROWID MV_CASE (cr=17148054 pr=96758 pw=0 time=0 us cost=7 size=40 card=1)
    32464070      INDEX RANGE SCAN IDX_MV_CASE_P_ROWID (cr=4489770 pr=15250 pw=0 time=19576798 us cost=3 size=0 card=7)(object id 98467)
          0    FILTER  (cr=0 pr=0 pw=0 time=0 us)
          0     NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=4 size=78 card=1)
          0      TABLE ACCESS BY USER ROWID JCASE (cr=0 pr=0 pw=0 time=0 us cost=1 size=45 card=1)
          0      INDEX RANGE SCAN JCASE_X_OFFENSE_I0 (cr=0 pr=0 pw=0 time=0 us cost=3 size=33 card=1)(object id 83623)
    Issues related to the:
    (1) what are the objects as JCASE OF SNAPSHOT(:B_SCN)? Can I index? I tried to access it, but received the error
    Select * from SNAPSHOT(:B_SCN) JCASE;
    ORA-08187: snapshot expression not allowed here
    08187 00000 - "expression of unauthorized snapshot here.
    * Cause: An expression that uses snapshot AS of a specified when not allowed.
    * Action: Do not use the ACE OF the clause

    (2) in the inline view more trees, he used ROWID in where clause. I tried to create an index on the ROWID and error
    create index idx_jcase_offense_rid on JCASE_X_OFFENSE (rowid)
    *
    ERROR on line 1:
    ORA-00904: invalid identifier

    Note: I checked that I have the index of all the areas in which all the clauses contained in the DML except rowid.

    Thanks for help.

    1 apparently Oracle Flashback technology is used when no newspaper materialized view have been implemented

    2 rowid is the external representation of the physical location of a line. The rowid points to a file and a block and a rowid in this block.
    The nodes of an index comprised of a key and the corresponding rowid.
    As a rowid is never stored, you also can't index.

    Your performance issue is the result of outerjoining all tables.
    It is a design error. Outer joins always lead to table scan complete and joins of hash for obvious reasons.

    As your MV is a MV complex is not a candidate for FAST REFRESH ON COMMIT.

    ---------------
    Sybrand Bakker
    Senior Oracle DBA

  • How to improve the materialized view Refresh speed?

    Hello


    Are there tips to improve the speed of refresh of the materialized views?
    All documentation or advice are appreciated!

    Thank you!

    Agree with S_Lindenmayr, if possible, the fast refresh should be used to speed up the update because it syncs MV with only the changes since the previous update (instead of the refresh). To implement the Fatst update, fortunately, with 10 g +, Oracle provides a counselor with the TUNE_MVIEW procedure. Step by step to find in week 12 of the Top 20 features the famous Arup Nanda 10 g for the series of DBA http://www.oracle.com/technology/pub/articles/10gdba/week12_10gdba.html

    Tarraf

Maybe you are looking for