Materialized view to be optimized!!

The following materialized view is taking more than 1.5 hours. Any alternate suggestion/advise would be appreciated. Thanks in advance .
SELECT e.emp_key, trim(e.gid) gid, pcm.check_id, pcm.end_date, pcm.g_amt, pcm.net_amt, pedt.ded_amt, pedt.tax, pdm.ded_cd, trim(pdm.ded) ded, pcm.check_date
FROM employee e, check_mstr pcm, deduction_mstr pdm, deduction_tkn pedt, sys_parms sp
WHERE e.time_key = time_pkg.fx_time_key
AND e.emp_num = pcm.emp_num
AND pcm.LOAD_KEY = pedt.load_key
AND pcm.emp_num = pedt.emp_num
AND pcm.check_id = pedt.check_id
AND pdm.time_key = pedt.load_key
AND pdm.ded_key = pedt.ded_key
AND TO_CHAR(pcm.end_date, 'YYYY') = sp.run_year
--------------------------------------------------------------------------------------------------------------

When was the last time that statistics were computed
for these tables? Are you inadvertently missing a
join condition? Can you post an explain plan to see
if there are any bottlenecks?
HTH!Operation                         Object Name          Rows     Bytes     Cost
SELECT STATEMENT Optimizer Mode=CHOOSE                         1          3696
TABLE ACCESS BY INDEX ROWID               EMPLOYEE          1     26     103
NESTED LOOPS                                   1     224     3696
HASH JOIN                                        1     198     3593
NESTED LOOPS                                   1     195     3590
HASH JOIN                                   3     357     3587
TABLE ACCESS FULL               DEDUCTION_MSTR          271 K     12 M     322
TABLE ACCESS FULL               DEDUCTION_TKN          887 K     60 M     1046
TABLE ACCESS BY INDEX           ROWID     CHECK_MSTR     1     76     1
INDEX UNIQUE SCAN               CHECK_MSTR          1          
TABLE ACCESS FULL               SYS_PARMS          1     3     2
INDEX RANGE SCAN                    EMP_UIDX          1          102
----------------------------------------------------------------------------------------------------------------------

Similar Messages

  • Advantage of Materialized view on prebuilt table

    Could someone tell me the advantage of Materialized view on prebuilt table?. I'm unable to understand the concept from the Oracle documentation. I need to know the answers for following questions.
    1) Is the data stored in table and MV same?. Does the query retrive data from table or MV?. The query internally uses either table or a view as the names of both are same.
    2) Our DSS application is generating complicated queries and executing for long time. Is there any way I can optimize those queries using MV without rewriting the code in the application.

    It's a roughly analgous problem to figuring out what set of indexes to create to improve the performance of an application-- you need to understand the various queries, how the application is accessing data, and you need to balance a variety of competing needs in order to come up with a reasonable set of indexes.
    Fundamentally, Oracle can only use a materialized view to satisfy a query if a human could use just the data in the materialized view to answer the question. That generally means that the materialized view is going to have to be aggregated at a lower level or at the same level as the query. A materialized view that aggregates sales by day can be used for queries by year but a materialized view that aggregates sales by year cannot be used for queries that get sales by day. A materiailized view that aggregates sales by vendor and product can be used for queries that aggregate by vendor or by product, but a materialized view that aggregates by product cannot be used in a query that aggregates by product for a particular vendor.
    You'll have to balance what materialized views are ideal for a particular query, what materialized views are sufficient for a particular set of queries, and how to balance the space, managability, and refresh performance requirements between creating lots of somewhat redundant materialized views that provide optimal query performance at the cost of a lot of disk and a large refresh window vs creating fewer, more general materialized views that consume less disk and can be refreshed faster but that provide less query performance boosts.
    Justin

  • Spatial vs. materialized views/query rewrite

    Dear all,
    we are trying to use Spatial (Locator) functionality together with performance optimization using materialized views and query rewrite, and it does not seem to work. Does anybody has experience with this?
    The problem in more detail:
    * There is a spatial attribut (vom Typ GEOMETRY) in our table;
    * we define a materialized view on that table;
    * we run a query that could be better answered using the materialized view with query rewrite;
    *the optimizer does not choose the plan using the materialized view, query rewrite does not take place;
    This happenes, even if neither the materialized view, nor the query contains the spatial attribut.
    The explanation given by the procedure DBMS_MVIEW.Explain_Rewrite is:
    "QSM-01064 query has a fixed table or view Cause: Query
    rewrite is not allowed if query references any fixed tables or views"
    We are using Oracle 9R2, Enterprise Edition, with locator. Nevertheless, it would also be interesting, if there is any improvement in 10g?
    A more complicated task, using materialized views to optimize spatial operations (e.g., sdo_relate) would also be very interesting, as spatial joins are very expensive operations.
    Thanks in advance for any comments, ideas!
    Cheers,
    Gergely Lukacs

    Hi Dan,
    thanks for your rapid response!
    A simple example is:
    alter session set query_rewrite_integrity=trusted;
    alter session set query_rewrite_enabled=true;
    set serveroutput on;
    /* Creating testtable */
    CREATE TABLE TESTTABLE (
    KEY1 NUMBER (4) NOT NULL,
    KEY2 NUMBER (8) NOT NULL,
    KEY3 NUMBER (14) NOT NULL,
    NAME VARCHAR2 (255),
    X NUMBER (9,2),
    Y NUMBER (9,2),
    ATTR1 VARCHAR2 (2),
    ATTR2 VARCHAR2 (30),
    ATTR3 VARCHAR2 (80),
    ATTR4 NUMBER (7),
    ATTR5 NUMBER (4),
    ATTR6 NUMBER (5),
    ATTR7 VARCHAR2 (40),
    ATTR8 VARCHAR2 (40),
    CONSTRAINT TESTTABLE_PK
    PRIMARY KEY ( KEY1, KEY2, KEY3 ));
    /* Creating materialized view */
    CREATE MATERIALIZED VIEW TESTTABLE_MV
    REFRESH COMPLETE
    ENABLE QUERY REWRITE
    AS SELECT DISTINCT ATTR7, ATTR8
    FROM TESTTABLE;
    /* Creating statistics, just to make sure */
    execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE', cascade=>TRUE);
    execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE_MV', cascade=>TRUE);
    /* Explain rewrite procedure */
    DECLARE
    Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
    querytxt VARCHAR2(1500) :=
    'SELECT COUNT(*) FROM (
    SELECT DISTINCT
    ATTR8 FROM
    TESTTABLE
    i NUMBER;
    BEGIN
    DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
    FOR i IN 1..Rewrite_Array.count
    LOOP
    DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
    END LOOP;
    END;
    The message you get is:
    QSM-01009 materialized view, string, matched query text
    Cause: The query was rewritten using a materialized view, because query text matched the materialized view text.
    Action: No action required.
    i.e. query rewrite works!
    /* Adding geometry column to the testtable -- not to the materialized view, and not to the query! */
    ALTER TABLE TESTTABLE
    ADD GEOMETRYATTR mdsys.sdo_geometry;
    /* Explain rewrite procedure */
    DECLARE
    Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
    querytxt VARCHAR2(1500) :=
    'SELECT COUNT(*) FROM (
    SELECT DISTINCT
    ATTR8 FROM
    TESTTABLE
    i NUMBER;
    BEGIN
    DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
    FOR i IN 1..Rewrite_Array.count
    LOOP
    DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
    END LOOP;
    END;
    The messages you get are:
    QSM-01064 query has a fixed table or view
    Cause: Query rewrite is not allowed if query references any fixed tables or views.
    Action: No action required.
    QSM-01019 no suitable materialized view found to rewrite this query
    Cause: There doesn't exist any materialized view that can be used to rewrite this query.
    Action: Consider creating a new materialized view.
    i.e. query rewrite does not work!
    If this works, the next issue is to use materialized views for optimizing spatial operations, e.g., a spatial join. I can supply you with an example, if necessary (only makes sense, I think, after the first problem is solved).
    Thanks in advance for any ideas, comments!
    Cheers,
    Gergely

  • Can Oracle materialized view be used as crystal report datasource

    Hi,
    Can we use materialized view created in Orace 10g database as the data source of crystal reports.
    I'm using Crystal reports Server 2008 V1 version. I'm unable to find the materialized view under my data connection. I can see only tables, static views and stored procedures.
    Is there a way by which I can run my reports against a materialized view created in Oracle.
    Thanks
    Thomas EL

    Hi Thomas,
    Rather than doing all of this work around to access multiple databases/servers why not create a stored procedure to do all of this for you? Search the notes area for samples on how/what CR requires to use a SP in Oracle.
    Advantages is this is done all server side and CR simply waits for the data to be returned. Even if you are using a BVM or connecting directly to the SP, both cases are server side. Database servers are much more efficient and optimized to run queries and filtering data. CR has to do the filtering on it's second pass and that causes performance delays.
    Thank you
    Don

  • Please help on Materialized View

    Hello everyone,
    Our Oracle database is 11g Standard Edition, and need to create the Mviews for the data replication. We are going to use Refresh Fast, and manually to refresh Mviews with cron job.
    We have one Mview, which is created based on four master tables joined together. With "Refresh Fast" mode and join option, there are some restrictions. One of them is all ROWIDs of the base tables must be listed in SELECT statement. So that we have to add four extra ROWID columns in the MView. Is there a way to get rid of them? Please give some suggestions.
    Here is our test, and we do not want "e.rowid col1, d.rowid col2" in the MView.
    Thanks in advance!!!
    create table emp (empid number, name varchar2(10), deptno number);
    alter table emp add constraint emp_pk primary key (empid);
    create table dept (deptno number, name varchar2(10));
    alter table dept add constraint dept_pk primary key (deptno);
    alter table emp add constraint emp_fk foreign key (deptno)
    REFERENCES dept (deptno);
    create materialized view log on emp with rowid, sequence(empid, name, deptno) including new values;
    create materialized view log on dept with rowid, sequence(deptno, name) including new values;
    create materialized view emp_dept_mv
    refresh fast
    as
    select e.name
    from emp e, dept d
    where e.deptno=d.deptno;
    ERROR at line 5:
    ORA-12052: cannot fast refresh materialized view DBOWNER.EMP_DEPT_MV
    create materialized view emp_dept_mv
    refresh fast
    as
    select e.rowid col1, d.rowid col2, e.name name
    from emp e, dept d
    where e.deptno=d.deptno;
    Materialized view created.

    Hi,
    First thing is that, I could not able to understand what is the use of manual refresh.??
    As you have gone of Refresh Fast that is more than enough for your requirement, If am correct with the things what you stated in your post.
    Second, the problem is as you have joined to sources of tables where you have relation ship (exits) prior to Materialize view log, so ORACLE or Optimer getting confused form which rowid's it should give the preference for that.
    Either you remove the relations ship and carry out (or) go group Options further to your requirement.
    that would solve the Issue.
    - Pavan Kumar N

  • Performance consequences to adding materialized view logs to tables?

    I am writing a very complex query for a client of our transactional database system and this will require the creation of a materialized viewbecause all attempts at tuning to make performance acceptable have failed.
    I want to enable fast refresh of the MVIEW but I am confused regarding the consequences of the addition of adding materialized view logs to the base tables.
    Some of the tables are large and involved in alot of transactions and I am wondering if the performance of INSERT/UPDATES will be seriously affected by the presence of an mview log.
    This may be a simple question to answer but I was unable to find a clear cut answer in the literature.
    Thanks for any answers!!
    Chris Mills
    Biotechnology Data Management Consultant

    Last time i looked into this there were three cases to consider
    If you're doing conventional row-by-row DML then the impact is just one insert into a heap table per row modified.
    If you are modifying a high number of rows using bulk-binds then the overhead is very severe because modifying 1,000 rows on the base table causes 1,000 non-bulk bound inserts into the log table.
    Direct path inserts have extremely low overhead because the MV log is not touched. Instead, the range of new rowids added is logged in ALL_SUMDELTA
    http://oraclesponge.wordpress.com/2005/09/15/optimizing-materialized-views-part-ii-the-direct-path-insert-enhancement/

  • Preformance problem - Oracle does not choose the Materialized view

    Hi,
    Version 10204
    I have the following Materialized view :
    CREATE MATERIALIZED VIEW CRM.MV2_TUDWH_CRM_1201
    TABLESPACE DW_LARGE
    NOCACHE
    NOLOGGING
    COMPRESS
    PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
    BUILD IMMEDIATE
    REFRESH COMPLETE ON DEMAND
    WITH PRIMARY KEY
    ENABLE QUERY REWRITE        <<<<<<<======
    AS
    SELECT DISTINCT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
      FROM (   CRM.CI_CUST_INFO
            LEFT OUTER JOIN
               CRM.CM_CASE_DIM
            ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST));When running the following statment , the MV is used as you can see from 10053 trace file:
    Current SQL statement for this session:                                                                                            
    EXPLAIN PLAN FOR                                                                                                                   
    SELECT DISTINCT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM                                                                                  
      FROM (   CRM.CI_CUST_INFO                                                                                                        
            LEFT OUTER JOIN                                                                                                            
               CRM.CM_CASE_DIM                                                                                                         
            ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST))                                                                  
    ============                                                                                                                       
    Plan Table                                                                                                                         
    ============                                                                                                                       
    ----------------------------------------------------------------+-----------------------------------+-------------------------+    
    | Id  | Operation                           | Name              | Rows  | Bytes | Cost  | Time      |  TQ  |IN-OUT|PQ Distrib |    
    ----------------------------------------------------------------+-----------------------------------+-------------------------+    
    | 0   | SELECT STATEMENT                    |                   |       |       |    64 |           |      |      |           |    
    | 1   |  PX COORDINATOR                     |                   |       |       |       |           |      |      |           |    
    | 2   |   PX SEND QC (RANDOM)               | :TQ10001          | 4694K |   28M |    64 |  00:00:01 |:Q1001| P->S |QC (RANDOM)|    
    | 3   |    HASH UNIQUE                      |                   | 4694K |   28M |    64 |  00:00:01 |:Q1001| PCWP |           |    
    | 4   |     PX RECEIVE                      |                   | 4694K |   28M |    48 |  00:00:01 |:Q1001| PCWP |           |    
    | 5   |      PX SEND HASH                   | :TQ10000          | 4694K |   28M |    48 |  00:00:01 |:Q1000| P->P |HASH       |    
    | 6   |       PX BLOCK ITERATOR             |                   | 4694K |   28M |    48 |  00:00:01 |:Q1000| PCWC |           |    
    | 7   |        MAT_VIEW REWRITE ACCESS FULL | MV2_TUDWH_CRM_1201| 4694K |   28M |    48 |  00:00:01 |:Q1000| PCWP |           |    
    ----------------------------------------------------------------+-----------------------------------+-------------------------+    
    Predicate Information:                                                                                                             
    7 - access(:Z>=:Z AND :Z<=:Z)                                                                                                      
    Content of other_xml column                                                                                                        
    ===========================                                                                                                        
      db_version     : 10.2.0.4                                                                                                        
      parse_schema   : SYS                                                                                                             
      plan_hash      : 4066877073                                                                                                      
      Outline Data:                                                                                                                    
      /*+                                                                                                                              
        BEGIN_OUTLINE_DATA                                                                                                             
          IGNORE_OPTIM_EMBEDDED_HINTS                                                                                                  
          OPTIMIZER_FEATURES_ENABLE('10.2.0.4')                                                                                        
          OPT_PARAM('optimizer_dynamic_sampling' 3)                                                                                    
          OPT_PARAM('star_transformation_enabled' 'true')                                                                              
          ALL_ROWS                                                                                                                     
          OUTLINE_LEAF(@"SEL$C0C89B4D")                                                                                                
          REWRITE(@"SEL$9E43CB6E" "MV2_TUDWH_CRM_1201")                                                                                
          OUTLINE(@"SEL$9E43CB6E")                                                                                                     
          MERGE(@"SEL$58A6D7F6")                                                                                                       
          OUTLINE(@"SEL$3")                                                                                                            
          OUTLINE(@"SEL$58A6D7F6")                                                                                                     
          MERGE(@"SEL$1")                                                                                                              
          OUTLINE(@"SEL$2")                                                                                                            
          OUTLINE(@"SEL$1")                                                                                                            
          FULL(@"SEL$C0C89B4D" "MV2_TUDWH_CRM_1201"@"SEL$030DBFD9")                                                                    
        END_OUTLINE_DATA                                                                                                               
                            But when running more complex statment - the MV does not even considered by the optimizer as an option , and does not exists in the 10053 trace file:
    Current SQL statement for this session:
    EXPLAIN PLAN FOR
      SELECT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
        FROM (   CRM.CI_CUST_INFO
              LEFT OUTER JOIN
                 CRM.CM_CASE_DIM
              ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST))
       WHERE (CRM.CM_CASE_DIM.FIRST_PROVIDER_GRP_ID IN
                 ('2565', '2611', '1190', '2610', '2612')
              AND (CRM.CM_CASE_DIM.ROW_ADDED_DTTM >= (SYSDATE - 60)))
    ORDER BY CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
    ============
    Plan Table
    ============
    --------------------------------------------------+-----------------------------------+-------------------------+---------------+
    | Id  | Operation                   | Name        | Rows  | Bytes | Cost  | Time      |  TQ  |IN-OUT|PQ Distrib | Pstart| Pstop |
    --------------------------------------------------+-----------------------------------+-------------------------+---------------+
    | 0   | SELECT STATEMENT            |             |       |       |   13K |           |      |      |           |       |       |
    | 1   |  PX COORDINATOR             |             |       |       |       |           |      |      |           |       |       |
    | 2   |   PX SEND QC (ORDER)        | :TQ10002    |     1 |    56 |   13K |  00:01:26 |:Q1002| P->S |QC (ORDER) |       |       |
    | 3   |    SORT ORDER BY            |             |     1 |    56 |   13K |  00:01:26 |:Q1002| PCWP |           |       |       |
    | 4   |     PX RECEIVE              |             |     1 |    56 |   13K |  00:01:26 |:Q1002| PCWP |           |       |       |
    | 5   |      PX SEND RANGE          | :TQ10001    |     1 |    56 |   13K |  00:01:26 |:Q1001| P->P |RANGE      |       |       |
    | 6   |       HASH JOIN             |             |     1 |    56 |   13K |  00:01:26 |:Q1001| PCWP |           |       |       |
    | 7   |        PX RECEIVE           |             |     1 |    31 |   11K |  00:01:12 |:Q1001| PCWP |           |       |       |
    | 8   |         PX SEND BROADCAST   | :TQ10000    |     1 |    31 |   11K |  00:01:12 |:Q1000| P->P |BROADCAST  |       |       |
    | 9   |          PX BLOCK ITERATOR  |             |     1 |    31 |   11K |  00:01:12 |:Q1000| PCWC |           | 1     | 8     |
    | 10  |           TABLE ACCESS FULL | CM_CASE_DIM |     1 |    31 |   11K |  00:01:12 |:Q1000| PCWP |           | 1     | 8     |
    | 11  |        PX BLOCK ITERATOR    |             | 4694K |  115M |  2121 |  00:00:14 |:Q1001| PCWC |           | 1     | 6     |
    | 12  |         TABLE ACCESS FULL   | CI_CUST_INFO| 4694K |  115M |  2121 |  00:00:14 |:Q1001| PCWP |           | 1     | 6     |
    --------------------------------------------------+-----------------------------------+-------------------------+---------------+
    Predicate Information:
    6 - access("CI_CUST_INFO"."BO_ID"="CM_CASE_DIM"."BO_ID_CUST")
    10 - access(:Z>=:Z AND :Z<=:Z)
    10 - filter((INTERNAL_FUNCTION("CM_CASE_DIM"."FIRST_PROVIDER_GRP_ID") AND "CM_CASE_DIM"."ROW_ADDED_DTTM">=SYSDATE@!-60))
    12 - access(:Z>=:Z AND :Z<=:Z)Can one suggested a reason why the optimized did not choose the m.v ?
    After all as you can see the only change is adding more predicate to the statment , e.g:
    WHERE (CRM.CM_CASE_DIM.FIRST_PROVIDER_GRP_ID IN
    ('2565', '2611', '1190', '2610', '2612')
    AND (CRM.CM_CASE_DIM.ROW_ADDED_DTTM >= (SYSDATE - 60)))
    ORDER BY CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
    Thanks

    Hello Bob,
    Thanks for your replay.
    I just recreacted the MV and this time i REMOVED the DISTINCT and ADD two columns :
    CREATE MATERIALIZED VIEW CRM.MV2_TUDWH_CRM_1201
    TABLESPACE DW_LARGE
    NOCACHE
    NOLOGGING
    COMPRESS
    NOPARALLEL
    BUILD IMMEDIATE
    REFRESH COMPLETE ON DEMAND
    WITH PRIMARY KEY
    ENABLE QUERY REWRITE
    AS
    SELECT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM,
           CRM.CM_CASE_DIM.FIRST_PROVIDER_GRP_ID,
           CRM.CM_CASE_DIM.ROW_ADDED_DTTM
      FROM (   CRM.CI_CUST_INFO
            LEFT OUTER JOIN
               CRM.CM_CASE_DIM
            ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST));I rerun the first sql statment that in my first post.
    What happen now is as followed :
    - Optimizer choose to use MV , ONLY if i remove the DISTICT from the select statment.
    - If add the DISTINCT to the select statment , oracle choose a diffrent plan.
    Why ?
    sql_id=ffr3mkc6z8rsv.
    Current SQL statement for this session:
    EXPLAIN PLAN FOR
    SELECT DISTINCT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
      FROM (   CRM.CI_CUST_INFO
            LEFT OUTER JOIN
               CRM.CM_CASE_DIM
            ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST))
    ============
    Plan Table
    ============
    ---------------------------------------------------------+-----------------------------------+-------------------------+---------------+
    | Id  | Operation                      | Name            | Rows  | Bytes | Cost  | Time      |  TQ  |IN-OUT|PQ Distrib | Pstart| Pstop |
    ---------------------------------------------------------+-----------------------------------+-------------------------+---------------+
    | 0   | SELECT STATEMENT               |                 |       |       |   12K |           |      |      |           |       |       |
    | 1   |  PX COORDINATOR                |                 |       |       |       |           |      |      |           |       |       |
    | 2   |   PX SEND QC (RANDOM)          | :TQ10003        | 4691K |  197M |   12K |  00:01:19 |:Q1003| P->S |QC (RANDOM)|       |       |
    | 3   |    HASH UNIQUE                 |                 | 4691K |  197M |   12K |  00:01:19 |:Q1003| PCWP |           |       |       |
    | 4   |     PX RECEIVE                 |                 |   24M | 1030M |   12K |  00:01:18 |:Q1003| PCWP |           |       |       |
    | 5   |      PX SEND HASH              | :TQ10002        |   24M | 1030M |   12K |  00:01:18 |:Q1002| P->P |HASH       |       |       |
    | 6   |       HASH JOIN OUTER          |                 |   24M | 1030M |   12K |  00:01:18 |:Q1002| PCWP |           |       |       |
    | 7   |        PX RECEIVE              |                 | 4694K |  115M |  2121 |  00:00:14 |:Q1002| PCWP |           |       |       |
    | 8   |         PX SEND HASH           | :TQ10001        | 4694K |  115M |  2121 |  00:00:14 |:Q1001| P->P |HASH       |       |       |
    | 9   |          PX BLOCK ITERATOR     |                 | 4694K |  115M |  2121 |  00:00:14 |:Q1001| PCWC |           | 1     | 6     |
    | 10  |           TABLE ACCESS FULL    | CI_CUST_INFO    | 4694K |  115M |  2121 |  00:00:14 |:Q1001| PCWP |           | 1     | 6     |
    | 11  |        BUFFER SORT             |                 |       |       |       |           |:Q1002| PCWC |           |       |       |
    | 12  |         PX RECEIVE             |                 |   24M |  431M |   10K |  00:01:05 |:Q1002| PCWP |           |       |       |
    | 13  |          PX SEND HASH          | :TQ10000        |   24M |  431M |   10K |  00:01:05 |      | S->P |HASH       |       |       |
    | 14  |           INDEX FAST FULL SCAN | CM_CASE_DIM_IX_3|   24M |  431M |   10K |  00:01:05 |      |      |           |       |       |
    ---------------------------------------------------------+-----------------------------------+-------------------------+---------------+
    Predicate Information:
    6 - access("CI_CUST_INFO"."BO_ID"="CM_CASE_DIM"."BO_ID_CUST")
    10 - access(:Z>=:Z AND :Z<=:Z)

  • Refresh/Update data in a materialized view

    Hi,
    I have question about the data in a materialized view and how it is refreshed. My mat view has all my dimension-ids and my (for my specialize needs) aggregated measures from my fact table. I used the mat view wizard to create my view - which works perfectly. But now I wonder if I have to create some sort of mapping(?) or some sort of trigger to refresh the data in the mat view. Or is the data automatically refreshed when I start my fact table mappings. I use OWB 11gR2
    thx

    MVs have properties for refresh - you an refresh based on schedules or when dependent data is committed or manually.
    Cheers
    David

  • How can I fast refresh the  materialized view !!

    I created a MV base on some tables in order to improve the querey speed.
    but the mv I have created falied to refresh fast.
    because there are two same table in the from clause:
    jcdm jc1,jcdm jc2
    create materialized view temp_mv
    nologging
    pctfree 0
    storage (initial 2048k next 2048k pctincrease 0)
    parallel
    build immediate
    refresh force
    on demand
    as
    select
    TAB_GSHX.rowid hx_rid,
    TAB_GSHD.rowid hd_rid ,
    JC1.rowid jc1_rid ,
    JC2.rowid jc2_rid ,
    YSHD_ID     HXID,          
    JC1.JCDM     QFD,     
    JC2.JCDM     JLD     
    FROM
    TAB_GSHX,
    TAB_GSHD,
    jCDM JC1,
    JCDM JC2
    WHERE
    YSHD_ID=YSHX_ID
    AND YSHD_QFD=JC1.JBJC_ID
    AND YSHD_JLD=JC2.JBJC_ID
    AND TO_CHAR(YSHX_time,'YYYYMMDD')='20030101'
    the column msgtxt of the table MV_CAPABILITIES_TABLE is :
    "the multiple instances of the same table or view" and " one or more joins present in mv".
    How can I succeed in fast refresh the above temp_mv!!!
    thanks.

    lianjun,
    When you are using Oracle9i there is a procedure which can help you setup the materialized view. If some option isn't working it gives you hint why it doesn't work.
    The procedure is dbms_mview.explain_mview.
    Take a look at the documentation how to use it. (In the Oracle9i DWH guide the package is explained.)
    Hope this helps
    With kind regards,
    Bas Roelands

  • How to get Materialized View to ignore unused columns in source table

    When updating a column in a source table, records are generated in the corresponding materialized view log table. This happens even if the column being updated is not used in any MV that references the source table. That could be OK, so long as those updates are ignored. However they are not ignored, so when the MV is fast refreshed, I find it can take over a minute, even though no changes are required or made. Is there some way of configuring the materialized view log such that the materialized view refresh ignores these updates ?
    So for examle if I have table TEST:
    CREATE table test (
    d_id NUMBER(10) PRIMARY KEY,
    d_name VARCHAR2(100),
    d_desc VARCHAR2(256)
    This has an MV log MLOG$_TEST:
    CREATE MATERIALIZED VIEW LOG ON TEST with rowid, sequence, primary key;
    CREATE MATERIALIZED VIEW test_mv
    refresh fast on demand
    as
    select d_id, d_name
    from test;
    INSERT 200,000 records
    exec dbms_mview.refresh('TEST_MV','f');
    update test set d_desc = upper(d_desc) ;
    exec dbms_mview.refresh('TEST_MV','f'); -- This takes 37 seconds, yet no changes are required.
    Oracle 10g/11g

    I would love to hear a positive answer to this question - I have the exact same issue :-)
    In the "old" days (version 8 I think it was) populating the materialized view logs was done by Oracle auto-creating triggers on the base table. A "trick" could then make that trigger become "FOR UPDATE OF <used_column_list>". Now-a-days it has been internalized so such "triggers" are not visible and modifiable by us mere mortals.
    I have not found a way to explicitly tell Oracle "only populate MV log for updates of these columns." I think the underlying reason is that the MV log potentially could be used for several different materialized views at possibly several different target databases. So to be safe that the MV log can be used for any MV created in the future - Oracle always populates MV log at any update (I think.)
    One way around the problem is to migrate to STREAMS replication rather than materialized views - but it seems to me like swatting a fly with a bowling ball...
    One thing to be aware of: Once the MV log has been "bloated" with a lot of unneccessary logging, you may perhaps see that all your FAST REFRESHes afterwards becomes slow - even after the one that checked all the 200000 unneccessary updates. We have seen that it can happen that Oracle decides on full table scanning the MV log when it does a fast refresh - which usually makes sense. But after a "bloat" has happened, the high water mark of the MV log is now unnaturally high, which can make the full table scan slow by scanning a lot of empty blocks.
    We have a nightly job that checks each MV log if it is empty. If it is empty, it locks the MV log and locks the base table, checks for emptiness again, and truncates the MV log if it is still empty, before finally unlocking the tables. That way if an update during the day has happened to bloat the MV log, all the empty space in the MV log will be reclaimed at night.
    But I hope someone can answer both you and me with a better solution ;-)

  • Materialized View to run only once in a year...

    Hi everybody...
    I want to create a materialized view which will run only once in a year and specifically some minutes after 00:00 a.m. on new year's day,
    so i created the following:
    CREATE MATERIALIZED VIEW <mv_name>
    BUILD IMMEDIATE
    REFRESH START WITH TO_DATE('01/01/2007 00:15:00','DD/MM/RRRR HH24:MI:SS')
    NEXT SYSDATE+366
    I have two notes:
    1) how to declare the refresh to be done the first new year's day after the day it'll be created , i mean not static date (01/01/2007)
    2)some years are leap and some are not , so in order to run every new year's day how should i transform the above..????
    3)is there any view which displays the next run of a materialized view..???
    the view DBA_MV_REFRESH_TIMES displays the last refresh of mv's...
    I use Oracle 10.2.0.1 on XP ...
    Thanks , a lot
    Simon

    1).
    use the expression that evaluates to next january first.
    SQL> select sysdate, add_months(trunc(sysdate, 'yyyy'), 12) from dual ;
    SYSDATE     ADD_MONTHS(
    19-JUN-2006 01-JAN-2007
    1 row selected.
    SQL>2). for this also use the same expression that will evaluate to the january first of the year after that.

  • Is it possible to refresh the table from a Materialized view

    Hi,
    Is it possible to update the underlying table on which a Materialized view is created when some changes in a Materialized view is done.Is this reverse compatibility possible in Materialized View?
    Thanks in Advance,
    V.Dennis

    If you created the materialized view as UPDATEABLE then changes to it should automatically be relected in the underlying table. If this is not occurring I suggest you check the replication jobs. You probably have a stack of errors in DEFERROR.
    Cheers, APC

  • The data of my materialized view....in the while

    Hello
    We have problems with materialized views
    We have one wich re-build each a short period of time
    ¿Can i avoid the data to dissapear in the time process of refresh?
    Is so annoing to our clients to see that "from time to time" the data just dissapear for one period of time -the time while the materialized view is refreshing-
    Thank you in advance
    Bruno. Madrid. Spain

    > Is so annoing to our clients to see that "from time to time" the data just dissapear for
    one period of time -the time while the materialized view is refreshing-
    Have a similar problem. And dealing with large data volumes that makes the DELETE of the MV a very undesirable feature. Not as much a the resource footprint required, but the time it takes to do this - and the very tight processing windows that exist.
    The solution is a self-rolled and very likely not ideal for most - but it works well enough for us in production.
    No MV. Create a partition table. Create a staging table. Do a manual "full refresh" of the staging table (TRUNCATE and direct path INSERT). Follow this by a partition exchange with the partition table (no validation and including indexes). The result is that the data is replaced in the partitioned table within a second - no long running and expensive DELETE. End-users not effected by having a truncate pulling the data from beneath their reports.

  • Exporting data from a materialized view in Oracle 10g

    Can anybody tell me how to export data to a remote server and import data in that remote server without using ftp utility. Actually I want to export the data from a materialized view to the remote server and import the same in the remote server.
    If everything works well, I'll put the exporting and importing in a cronjob.
    Please let me know how can I do that if that's possible .
    Any reply would be appreciated.
    Thanks.

    Here is what I'm trying to do.
    I created materialized views using multiple base tables in my local server and the base tables got populated using a long process.
    Now I want to copy those data alone to some remote server since it doesn't have any base tables in it. For now, the remote server should depends on the localserver's data. I'm going to use the remote server's data for some testing purposes.
    I know it is easy to create mat.views in the remote server but it doesn't have I don't want to do that now. I just want to copy the snapshots from my local server to the remote server.
    Please let me know how to do that.
    Thanks.

  • Issue with creation of a materialized view

    Hi,
    I have a SQL query that works fine.
    But when I create a materialized view using the query, a few columns in the MV do not get populated at all.
    What could be the issue here?
    regards
    Prem

    Hi,
    Thanks for the reply. Here is the code.
    CREATE MATERIALIZED VIEW EDW.MV_OPPTY_ACTIVITY_AGG
    TABLESPACE EDW_DIM_DAT
    NOCACHE
    LOGGING
    NOCOMPRESS
    NOPARALLEL
    BUILD IMMEDIATE
    REFRESH COMPLETE ON DEMAND
    WITH PRIMARY KEY
    AS
    select
    OPPTY_ID OPPTY_ID,
    OPPORTUNITY_KEY OPPORTUNITY_KEY,
    oppty_number oppty_number ,
    SALES_CONSULTANT_HIST_KEY SALES_CONSULTANT_HIST_KEY ,
    company_add_source_key company_add_source_key,
    SALES_CONSULTANT_ID SALES_CONSULTANT_ID,
    ACTIVITY_TYPE ACTIVITY_TYPE ,
    activity_DATE activity_DATE ,
    LAST_MODIFIED_DATE LAST_MODIFIED_DATE ,
    CUSTOMER_FLAG CUSTOMER_FLAG,
    SALES_EMPLOYEE_HIST_KEY,
    milestone_KEY,
    oppty_milestone_name_hist stage_name,
    oppty_milestone_id_hist stage_id,
    milestone_prob prob_to_close,
    start_date oppty_start_date,
    oppty_close_date oppty_close_date,
    end_date oppty_end_date,
    sum(DURATION) TOTAL_DURATION,
    sum (CASE WHEN ACTIVITY_type IN ('CU14', 'CU15', 'CU16', 'CU17',
    'CU18', 'CU19', 'CU20', 'CU21') THEN DURATION ELSE 0 END ) CQM_DURATION,
    sum (CASE WHEN ACTIVITY_type = 'CU01' THEN DURATION ELSE 0 END ) TRADE_SEM_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU02' THEN DURATION ELSE 0 END ) RFP_RFI_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU03' THEN DURATION ELSE 0 END ) INFO_GATH_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU04' THEN DURATION ELSE 0 END ) PREP_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU05' THEN DURATION ELSE 0 END ) PRES_DEMO_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU06' THEN DURATION ELSE 0 END ) POC_DURATION,
    sum ( CASE WHEN ACTIVITY_type = 'CU07' THEN DURATION ELSE 0 END ) PRE_CUST_SUPP_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU08' THEN DURATION ELSE 0 END ) POST_CUST_SUPP_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU09' THEN DURATION ELSE 0 END ) PARTNER_SUPP_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU10' THEN DURATION ELSE 0 END ) TRAVEL_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU11' THEN DURATION ELSE 0 END ) KEYCODES_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU12' THEN DURATION ELSE 0 END ) SI_SUPP_DURATION,
    sum ( CASE WHEN ACTIVITY_type = 'CU13' THEN DURATION ELSE 0 END ) CHANNEL_SUPP_DURATION,
    sum( CASE WHEN ACTIVITY_type = 'CU23' THEN DURATION ELSE 0 END ) MIGRATION_DURATION ,
    max(LICENSE_USD) LICENSE_USD ,
    MAX(LICENSE_LOCAL) LICENSE_LOCAL,
    MAX(maintAINANCE_usd) maintAINANCE_usd,
    MAX(maintAINANCE_LOCAL) maintAINANCE_LOCAL,
    MAX(TRAINING_USD) training_usd,
    MAX(TRAINING_LOCAL) training_LOCAL,
    MAX(CONSULTING_USD) consulting_usd,
    MAX(CONSULTING_LOCAL) consulting_LOCAL,
    MAX(RENEWALS_USD) renewals_usd ,
    MAX(RENEWAL_local) RENEWAL_local,
    max(LOBANALYTICS2_LOCAL) epm_local,
    max(LOBDATAINTEGRATION2_LOCAL) eim_local,
    max(IDD_AMOUNT_LOCAL) idd_local,
    max(ONDEMAND_AMOUNT_LOCAL) ondemand_local,
    max(LOBANALYTICS2_usd) epm_usd,
    max(LOBDATAINTEGRATION2_usd) eim_usd,
    max(IDD_AMOUNT_usd) idd_usd,
    max(ONDEMAND_AMOUNT_usd) ondemand_usd
    FROM edw.sales_consulting_activity_fct t1 ,
    select
    o.oppty_id_number,
    o.oppty_id,
    O.OPPORTUNITY_KEY,
    LICENSE_USD LICENSE_USD ,
    LICENSE_LOCAL LICENSE_LOCAL,
    o.FYM_USD maintAINANCE_usd,
    o.FYM_LOCAL maintAINANCE_LOCAL,
    o.TRAINING_USD training_usd,
    o.TRAINING_LOCAL training_LOCAL,
    o.CONSULTING_USD consulting_usd,
    o.CONSULTING_LOCAL consulting_LOCAL,
    o.RENEWAL_USD renewals_usd ,
    o.RENEWAL_local RENEWAL_local ,
    o.LOBANALYTICS2_LOCAL,
    o.LOBANALYTICS2_usd,
    o.LOBDATAINTEGRATION2_LOCAL,
    o.IDD_AMOUNT_LOCAL,
    o.ONDEMAND_AMOUNT_LOCAL,
    o.LOBDATAINTEGRATION2_usd,
    o.IDD_AMOUNT_usd,
    o.ONDEMAND_AMOUNT_usd
    from edw.opportunity_hist_fact o
    where o.SOURCE_SYSTEM='SFDC'
    and upper(status)='ACTIVE'
    and o.last_modified_date = (select max(last_modified_date )from edw.opportunity_hist_fact o2 where o.opportunity_key = o2.opportunity_key))T2,
    ( Select activity_key,OPPTY_ID_NUMBER, MIL.milestone_KEY,MIL.milestone_name oppty_milestone_name_hist,milestone_id
    oppty_milestone_id_hist, milestone_prob,start_date,oppty_close_date,end_date FROM
    EDW.opportunity_hist_fact OPP,
    edw.milestone MIL,
    edw.sales_consulting_activity_fct act WHERE
    ACTIVITY_DATE >=start_date (+) and activity_date <=opp.last_modified_date(+)
    and OPP.OPPTY_ID_NUMBER (+) =act.OPPTY_NUMBER
    and OPP.milestone_key =MIL.milestone_key(+) ) T3
    where t1.oppty_NUMBER (+) =T2.OPPTY_ID_NUMBER
    and t1.activity_key=t3.activity_key
    --and oppty_number ='279749'
    GROUP BY OPPTY_ID,
    oppty_number,
    OPPORTUNITY_KEY,
    SALES_CONSULTANT_HIST_KEY ,
    company_add_source_key,
    SALES_CONSULTANT_ID,
    SALES_EMPLOYEE_HIST_KEY,
    ACTIVITY_TYPE ,
    ACTIVITY_DATE ,
    LAST_MODIFIED_DATE,
    CUSTOMER_FLAG,
    milestone_KEY,
    oppty_milestone_name_hist,
    oppty_milestone_id_hist,
    milestone_prob,
    start_date,
    oppty_close_date,
    end_date;
    Regards,
    Prem

Maybe you are looking for