Nested Materialized View in 8.1.7

Hi, I am attempting to create a nested materialized view as per metalink doc id 212533 and I am hitting ORA-12015: cannot create a fast refresh snapshot from a complex query.
Please see my test script below:
Any help would be greatly appreciated
Thanks,
Brad
** Filename: test_mv.SQL
** Author: Brad Scrivens
** Creation: January 2006
** Purpose:Test example of nested materialized view
** CHANGE History
** List environment details
DATABASE_NAME
FVOL1
1 row selected.
Elapsed: 00:00:00.03
USER
OPUS_CORE
1 row selected.
Elapsed: 00:00:00.02
RUNDATE
07-FEB-2006 16:16:56
1 row selected.
Elapsed: 00:00:00.03
1* SELECT * FROM v$version
BANNER
Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
PL/SQL Release 8.1.7.4.0 - Production
CORE     8.1.7.0.0     Production
TNS for VMS: Version 8.1.7.4.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
5 rows selected.
Elapsed: 00:00:00.04
1* ALTER SESSION ENABLE PARALLEL DML
Session altered.
Elapsed: 00:00:00.01
1* ALTER SESSION SET SORT_AREA_SIZE = 209715200
Session altered.
Elapsed: 00:00:00.01
1* DROP TABLE emp
DROP TABLE emp
ERROR at line 1:
ORA-00942: table or view does not exist
1* DROP TABLE dept
DROP TABLE dept
ERROR at line 1:
ORA-00942: table or view does not exist
1 CREATE TABLE emp
2 (EMPNO NUMBER(4) NOT NULL
3 , ENAME VARCHAR2(10)
4 , JOB VARCHAR2(9)
5 , MGR NUMBER(4)
6 , HIREDATE DATE
7 , SAL NUMBER(7,2)
8 , COMM NUMBER(7,2)
9* , DEPTNO NUMBER(2))
Table created.
1 alter table emp
2 add constraint emp_pk
3 primary key (EMPNO)
4* novalidate
Table altered.
1 CREATE TABLE dept(
2 DEPTNO NUMBER(2) NOT NULL
3 , DNAME VARCHAR2(14)
4 , LOC VARCHAR2(13)
5* )
Table created.
1 alter table dept
2 add constraint dept_pk
3 primary key (DEPTNO)
4* novalidate
Table altered.
1* create materialized view log on emp with primary key,rowid
Materialized view log created.
1* create materialized view log on dept with primary key,rowid
Materialized view log created.
1 create materialized view empmv1
2 refresh fast on demand
3 with primary key
4 as select e.empno,d.deptno,e.ename,d.dname, e.rowid erowid,d.rowid drowid
5 from emp e, dept d
6* where e.deptno=d.deptno
from emp e, dept d
ERROR at line 5:
ORA-12015: cannot create a fast refresh snapshot from a complex query
1* alter table empmv1 add primary key(empno)
alter table empmv1 add primary key(empno)
ERROR at line 1:
ORA-00942: table or view does not exist
1 create materialized view log on empmv1 with primary key,rowid(deptno)
2* including new values
create materialized view log on empmv1 with primary key,rowid(deptno)
ERROR at line 1:
ORA-00942: table or view does not exist
1 create materialized view empmv2
2 refresh fast on demand
3 with primary key
4 as select empno,deptno , count(*)
5 from empmv1
6* group by empno,deptno
from empmv1
ERROR at line 5:
ORA-00942: table or view does not exist
END OF @test_mv.SQL
*****************************************************************************************

I have managed to execute my test script successfully in a different schema in the same database I was working with. Am I missing a grant?
I have been working as the schema owner in each of these schemas.
thanks,
Brad

Similar Messages

  • Fast Refresh Nested Materialized View problem in ORACLE 9i 9.2.0.7

    Hello
    My problem is in creating fast refresh nested materialized view in oracle 9i
    In below is an example of my problem
    ( I need to say when I run this example in Oracle 11g all things is OK )
    create table ali.alitest1(id number primary key,n1 number,n2 number);
    create table ali.alitest2(id number primary key,n3 number);
    CREATE MATERIALIZED VIEW LOG ON ali.alitest1 WITH ROWID,PRIMARY KEY ,SEQUENCE
    (n1,n2)
    INCLUDING NEW VALUES;
    CREATE MATERIALIZED VIEW LOG ON ali.alitest2 WITH ROWID,PRIMARY KEY ,SEQUENCE
    (n3)
    INCLUDING NEW VALUES;
    CREATE MATERIALIZED VIEW ali.alitest1_mv
    REFRESH WITH PRIMARY KEY FAST
    AS
    select id,n1 from ali.alitest1;
    CREATE MATERIALIZED VIEW LOG ON ali.alitest1_mv WITH ROWID,PRIMARY KEY ,SEQUENCE
    (n1)
    INCLUDING NEW VALUES;
    CREATE MATERIALIZED VIEW ali.alitest2_mv
    REFRESH WITH PRIMARY KEY FAST
    AS
    select t1.id,t1.n1,t2.n3,t1.rowid "t1_rowid",t2.rowid "t2_rowid" from ali.alitest1_mv t1,ali.alitest2 t2 where t1.id=t2.id;
    SQL Error: ORA-12053: this is not a valid nested materialized view
    12053. 00000 - "this is not a valid nested materialized view"
    *Cause:    The list of objects in the FROM clause of the definition of this
    materialized view had some dependencies upon each other.
    *Action:   Refer to the documentation to see which types of nesting are valid.
    do you know what is problem ?
    thanks

    Take look for this link :
    http://rwijk.blogspot.com/2009/08/fast-refreshable-materialized-view.html

  • Query rewrites with Nested materialized views with different aggregations

    Platform used : Oracle 11g.
    Here is a simple fact table (with measures m1,m2) and dimensions (a) Location (b) Calendar and (c) Product. The business problem is that aggregation operator for measure m1,m2 are different along location dimension and Calendar dimension. The intention is to preaggregate the measures for a product along the calendar dimension and Location dimension and store it as materialized views.
    The direct option is to define a materialized view with Inline queries (Because of the different aggrergation operator, it is not possible to write a query without Inline query). http://download-uk.oracle.com/docs/cd/B28359_01/server.111/b28313/qradv.htm#BABEAJBF documents the limitations that it works only for 'Text match' and 'Equivalent queries' and that is too limiting.
    So decided to have nested materialized view, with first view having just joins(my_dim_mvw_joins), the second view having aggregations along Calendar dimension (my_dim_mvw_calendar) and third view having aggregations along the Location dimension(my_dim_mvw_location). Obviously I do not want the query I fire to know about materialized views and I fire it against the fact table. I see that for the fired query (Which needs aggregations along both Calendar and Location), is rewritten with just second materialized view but not the third. (Had set QUERY_REWRITE_INTEGRITY as TRUSTED) .
    Wanted to know whether there are limitations on Query Writes with nested materialized views? Thanks
    (Have given a simple testable example below. Pls ignore the values given in 'CALENDAR_IDs', 'PRODUCT_IDs' etc as they are the same for all the queries)
    -- Calendar hierarchy table
    CREATE TABLE CALENDAR_HIERARCHY_TREE
    (     "CALENDAR_ID" NUMBER(5,0) NOT NULL ENABLE,
    "HIERARCHY1_ID" NUMBER(5,0),
    "HIERARCHY2_ID" NUMBER(5,0),
    "HIERARCHY3_ID" NUMBER(5,0),
    "HIERARCHY4_ID" NUMBER(5,0),
    CONSTRAINT "CALENDAR_HIERARCHY_TREE_PK" PRIMARY KEY ("CALENDAR_ID")
    -- Location hierarchy table
    CREATE TABLE LOCATION_HIERARCHY_TREE
    (     "LOCATION_ID" NUMBER(3,0) NOT NULL ENABLE,
    "HIERARCHY1_ID" NUMBER(3,0),
    "HIERARCHY2_ID" NUMBER(3,0),
    "HIERARCHY3_ID" NUMBER(3,0),
    "HIERARCHY4_ID" NUMBER(3,0),
    CONSTRAINT "LOCATION_HIERARCHY_TREE_PK" PRIMARY KEY ("LOCATION_ID")
    -- Product hierarchy table
    CREATE TABLE PRODUCT_HIERARCHY_TREE
    (     "PRODUCT_ID" NUMBER(3,0) NOT NULL ENABLE,
         "HIERARCHY1_ID" NUMBER(3,0),
         "HIERARCHY2_ID" NUMBER(3,0),
         "HIERARCHY3_ID" NUMBER(3,0),
         "HIERARCHY4_ID" NUMBER(3,0),
         "HIERARCHY5_ID" NUMBER(3,0),
         "HIERARCHY6_ID" NUMBER(3,0),
         CONSTRAINT "PRODUCT_HIERARCHY_TREE_PK" PRIMARY KEY ("PRODUCT_ID")
    -- Fact table
    CREATE TABLE RETAILER_SALES_TBL
    (     "PRODUCT_ID" NUMBER,
    "PRODUCT_KEY" VARCHAR2(50 BYTE),
    "PLAN_ID" NUMBER,
    "PLAN_PERIOD_ID" NUMBER,
    "PERIOD_ID" NUMBER(5,0),
    "M1" NUMBER,
    "M2" NUMBER,
    "M3" NUMBER,
    "M4" NUMBER,
    "M5" NUMBER,
    "M6" NUMBER,
    "M7" NUMBER,
    "M8" NUMBER,
    "LOCATION_ID" NUMBER(3,0),
    "M9" NUMBER,
    CONSTRAINT "RETAILER_SALES_TBL_LOCATI_FK1" FOREIGN KEY ("LOCATION_ID")
    REFERENCES LOCATION_HIERARCHY_TREE ("LOCATION_ID") ENABLE,
    CONSTRAINT "RETAILER_SALES_TBL_PRODUC_FK1" FOREIGN KEY ("PRODUCT_ID")
    REFERENCES PRODUCT_HIERARCHY_TREE ("PRODUCT_ID") ENABLE,
    CONSTRAINT "RETAILER_SALES_TBL_CALEND_FK1" FOREIGN KEY ("PERIOD_ID")
    REFERENCES CALENDAR_HIERARCHY_TREE ("CALENDAR_ID") ENABLE
    -- Location dimension definition to promote query rewrite
    create DIMENSION LOCATION_DIM
    LEVEL CHAIN IS LOCATION_HIERARCHY_TREE.HIERARCHY1_ID
    LEVEL CONSUMER_SEGMENT IS LOCATION_HIERARCHY_TREE.HIERARCHY3_ID
    LEVEL STORE IS LOCATION_HIERARCHY_TREE.LOCATION_ID
    LEVEL TRADING_AREA IS LOCATION_HIERARCHY_TREE.HIERARCHY2_ID
    HIERARCHY PROD_ROLLUP (
    STORE CHILD OF
    CONSUMER_SEGMENT CHILD OF
    TRADING_AREA CHILD OF
    CHAIN
    -- Calendar dimension definition
    create DIMENSION CALENDAR_DIM
    LEVEL MONTH IS CALENDAR_HIERARCHY_TREE.HIERARCHY3_ID
    LEVEL QUARTER IS CALENDAR_HIERARCHY_TREE.HIERARCHY2_ID
    LEVEL WEEK IS CALENDAR_HIERARCHY_TREE.CALENDAR_ID
    LEVEL YEAR IS CALENDAR_HIERARCHY_TREE.HIERARCHY1_ID
    HIERARCHY CALENDAR_ROLLUP (
    WEEK CHILD OF
    MONTH CHILD OF
    QUARTER CHILD OF
    YEAR
    -- Materialized view with just joins needed for other views
    CREATE MATERIALIZED VIEW my_dim_mvw_joins build immediate refresh complete enable query rewrite as
    select product_id, lht.HIERARCHY1_ID, lht.HIERARCHY2_ID, lht.HIERARCHY3_ID, lht.location_id, cht.HIERARCHY1_ID year,
    cht.HIERARCHY2_ID quarter, cht.HIERARCHY3_ID month, cht.calendar_id week, m1, m3, m7, m9
    from retailer_sales_tbl RS, calendar_hierarchy_tree cht, location_hierarchy_tree lht
    WHERE RS.period_id = cht.CALENDAR_ID
    and RS.location_id = lht.location_id
    and cht.CALENDAR_ID in (10,236,237,238,239,608,609,610,611,612,613,614,615,616,617,618,619,1426,1427,1428,1429,1430,1431,1432,1433,1434,1435,1436,1437,1438,1439,1440,1441,1442,1443,1444,1445,1446,1447,1448,1449,1450,1451,1452,1453,1454,1455,1456,1457,1458,1459,1460,1461,1462,1463,1464,1465,1466,1467,1468,1469,1470,1471,1472,1473,1474,1475,1476,1477)
    AND product_id IN (5, 6, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20)
    AND lht.location_id IN (2, 3, 11, 12, 13, 14, 15, 4, 16, 17, 18, 19, 20)
    -- Materialized view which aggregate along calendar dimension
    CREATE MATERIALIZED VIEW my_dim_mvw_calendar build immediate refresh complete enable query rewrite as
    select product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID ,location_id, year, quarter, month, week,
    sum(m1) m1_total, sum(m3) m3_total, sum(m7) m7_total, sum(m9) m9_total,
    GROUPING_ID(product_id, location_id, year, quarter, month, week) dim_mvw_gid
    from my_dim_mvw_joins
    GROUP BY product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID , location_id,
    rollup (year, quarter, month, week);
    -- Materialized view which aggregate along Location dimension
    CREATE MATERIALIZED VIEW my_dim_mvw_location build immediate refresh complete enable query rewrite as
    select product_id, year, quarter, month, week, HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id,
    sum(m1_total) m1_total_1, sum(m3_total) m3_total_1, sum(m7_total) m7_total_1, sum(m9_total) m9_total_1,
    GROUPING_ID(product_id, HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id, year, quarter, month, week) dim_mvw_gid
    from my_dim_mvw_calendar
    GROUP BY product_id, year, quarter, month, week,
    rollup (HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id)
    -- SQL Query Fired (for simplicity have used SUM as aggregation operator for both, but they will be different)
    select product_id, year, HIERARCHY1_ID, HIERARCHY2_ID,
    sum(m1_total) m1_total_1, sum(m3_total) m3_total_1, sum(m7_total) m7_total_1, sum(m9_total) m9_total_1
    from
    select product_id, HIERARCHY1_ID , HIERARCHY2_ID , year,
    sum(m1) m1_total, sum(m3) m3_total, sum(m7) m7_total, sum(m9) m9_total
    from
    select product_id, lht.HIERARCHY1_ID , lht.HIERARCHY2_ID , lht.HIERARCHY3_ID ,lht.location_id, cht.HIERARCHY1_ID year, cht.HIERARCHY2_ID quarter, cht.HIERARCHY3_ID month, cht.calendar_id week,m1,m3,m7,m9
    from
    retailer_sales_tbl RS, calendar_hierarchy_tree cht, location_hierarchy_tree lht
    WHERE RS.period_id = cht.CALENDAR_ID
    and RS.location_id = lht.location_id
    and cht.CALENDAR_ID in (10,236,237,238,239,608,609,610,611,612,613,614,615,616,617,618,619,1426,1427,1428,1429,1430,1431,1432,1433,1434,1435,1436,1437,1438,1439,1440,1441,1442,1443,1444,1445,1446,1447,1448,1449,1450,1451,1452,1453,1454,1455,1456,1457,1458,1459,1460,1461,1462,1463,1464,1465,1466,1467,1468,1469,1470,1471,1472,1473,1474,1475,1476,1477)
    AND product_id IN (5, 6, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20)
    AND lht.location_id IN (2, 3, 11, 12, 13, 14, 15, 4, 16, 17, 18, 19, 20)
    GROUP BY product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID , location_id, year
    ) sales_time
    GROUP BY product_id, year,HIERARCHY1_ID, HIERARCHY2_ID
    This Query rewrites only with my_dim_mvw_calendar. (as saw in Query Plan and EXPLAIN_MVIEW). But we would like it to use my_dim_mvw_location as that has aggregations for both dimensions.

    blackhole001 wrote:
    Hi all,
    I'm trying to make my programmer's life easier by creating a database view for them to query the data, so they don't have to worry about joining tables. This sounds like a pretty horrible idea. I say this because you will eventually end up with programmers that know nothing about your data model and how to properly interact with it.
    Additionally, what you will get is a developer that takes one of your views and see's that of the 20 columns in it, it has 4 that he needs. If all those 4 columns comes from a simple 2 table join, but the view has 8 tables, you're wasting a tonne of resources by using the view (and heaven forbid they have to join that view to another view to get 4 of the 20 columns from that other view as well).
    Ideally you'd write stored routines that satisfy exactly what is required (if you are the database resource and these other programmers are java, .net, etc... based) and the front end developers would call those routines customized for an exact purpose.
    Creating views is not bad, but it's by no means a proper solution to having developers not learn or understand SQL and/or the data model.

  • Problem in fast refreshing nested materialized views

    Hi all,
    While developing an ODS(Operational Data Store) system, i've created base materialized views from production database to ODS database which would use fast refresh. Now, i need to create nested Materialized views on these base MViews which contains joins and aggregations which should refresh on FAST mechanism.
    But while doing so, got several problems though Nested materialized views can be built using Complete Mechanism. The reporting queries is important and we want it should not hit the production database, rather it should hit the ODS db. But we are failing to build the Nested Materialized views which works on FAST.
    I tried google, oracle docs but all in vain. i tried to do a simple testing which also failed. I would be grateful if anyone can help in in this regard. I'm attaching the test case experimented,
    SCOTT >CREATE MATERIALIZED VIEW LOG ON EMP
    2 WITH ROWID, SEQUENCE(EMPNO, ENAME, JOB,
    3 MGR, HIREDATE, SAL,
    4 COMM, DEPTNO)
    5 INCLUDING NEW VALUES;
    Materialized view log created.
    Elapsed: 00:00:00.03
    SCOTT >
    SCOTT >CREATE MATERIALIZED VIEW LOG ON DEPT
    2 WITH ROWID, SEQUENCE(DEPTNO, DNAME, LOC)
    3 INCLUDING NEW VALUES;
    Materialized view log created.
    Elapsed: 00:00:00.06
    SCOTT >
    SCOTT >CREATE MATERIALIZED VIEW MV_EMP
    2 NOCACHE
    3 ENABLE ROW MOVEMENT
    4 NOLOGGING
    5 NOCOMPRESS
    6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
    7 BUILD IMMEDIATE
    8 REFRESH FAST ON DEMAND
    9 WITH ROWID
    10 ENABLE QUERY REWRITE
    11 AS
    12 SELECT * FROM EMP;
    Materialized view created.
    Elapsed: 00:00:00.21
    SCOTT >
    SCOTT >CREATE MATERIALIZED VIEW MV_DEPT
    2 NOCACHE
    3 ENABLE ROW MOVEMENT
    4 NOLOGGING
    5 NOCOMPRESS
    6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
    7 BUILD IMMEDIATE
    8 REFRESH FAST ON DEMAND
    9 WITH ROWID
    10 ENABLE QUERY REWRITE
    11 AS
    12 SELECT * FROM DEPT;
    Materialized view created.
    Elapsed: 00:00:00.14
    SCOTT >CREATE MATERIALIZED VIEW LOG ON MV_EMP
    2 WITH ROWID, SEQUENCE(EMPNO, ENAME, JOB,
    3 MGR, HIREDATE, SAL,
    4 COMM, DEPTNO)
    5 INCLUDING NEW VALUES;
    Materialized view log created.
    Elapsed: 00:00:00.04
    SCOTT >
    SCOTT >CREATE MATERIALIZED VIEW LOG ON MV_DEPT
    2 WITH ROWID, SEQUENCE(DEPTNO, DNAME, LOC)
    3 INCLUDING NEW VALUES;
    Materialized view log created.
    Elapsed: 00:00:00.03
    SCOTT >
    SCOTT >CREATE MATERIALIZED VIEW MV_EMP_DEPT
    2 NOCACHE
    3 ENABLE ROW MOVEMENT
    4 NOLOGGING
    5 NOCOMPRESS
    6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
    7 BUILD IMMEDIATE
    8 REFRESH FAST ON DEMAND
    9 WITH ROWID
    10 ENABLE QUERY REWRITE
    11 AS
    12 SELECT D.ROWID DEPT_ROWID, E.ROWID EMP_ROWID, E.ENAME, D.DNAME, D.LOC, E.JOB, E.SAL
    13 FROM MV_EMP E,
    14 MV_DEPT D
    15 WHERE E.DEPTNO=D.DEPTNO;
    FROM MV_EMP E,
    ERROR at line 13:
    ORA-12053: this is not a valid nested materialized view
    Elapsed: 00:00:00.17
    SCOTT >
    SCOTT >CREATE MATERIALIZED VIEW MV_EMP_DEPT
    2 NOCACHE
    3 ENABLE ROW MOVEMENT
    4 NOLOGGING
    5 NOCOMPRESS
    6 PARALLEL(DEGREE DEFAULT INSTANCES DEFAULT)
    7 BUILD IMMEDIATE
    8 REFRESH FORCE ON DEMAND
    9 WITH ROWID
    10 ENABLE QUERY REWRITE
    11 AS
    12 SELECT D.ROWID DEPT_ROWID, E.ROWID EMP_ROWID, E.ENAME, D.DNAME, D.LOC, E.JOB, E.SAL
    13 FROM MV_EMP E,
    14 MV_DEPT D
    15 WHERE E.DEPTNO=D.DEPTNO;
    Materialized view created.
    Elapsed: 00:00:00.25
    SCOTT >
    SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_EMP','F');
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:00.04
    SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_DEPT','F');
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:00.04
    SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_EMP_DEPT','F');
    BEGIN DBMS_MVIEW.REFRESH('MV_EMP_DEPT','F'); END;
    ERROR at line 1:
    ORA-12004: REFRESH FAST cannot be used for materialized view "SCOTT"."MV_EMP_DEPT"
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2254
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2460
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2429
    ORA-06512: at line 1
    Elapsed: 00:00:00.11
    SCOTT >EXECUTE DBMS_MVIEW.REFRESH('MV_EMP_DEPT','C');
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:00.35
    SCOTT >

    Sorry,
    By mistake this got posted in the CERTIFICATION forum,
    you can view the same question in the following link:
    Problem in fast refreshing nested materialized views

  • How to handle ORA-12053: this is not a valid nested materialized view

    Hi,
    I've been trying to create nested MV's for a while and encountered with this error and not able to find a solution even after spending lot of time on this.
    Here is the problem.
    --> I've 3 base tables Tab1, Tab2, Tab3, which r not having pk's on them (restriction).
    --> Created logs on these tables.
    --> Created 1st level MV's with pk's (from different schema - siebel schema) defined as MV10,MV11,MV12 with required columns from each base table. These mv's r made fast/complete refresh ... doesn't matter much as complete refresh is done fast (tried both .. just in case if thatz the reason for my error msg).
    CREATE MATERIALIZED VIEW mv10
    REFRESH COMPLETE/FAST
    WITH ROWID
    AS
    select
    col1
    ,col2
    FROM siebel.Tab1@dblink _name;
    --> Created MV logs on MV10,MV11,MV12.
    --> Created 2nd level MV (join MV) that is based on MV10,MV11,MV12 having join and filter coniditions ... and this gives the error.
    I think i've followd all the rules for nested MV and Fast Refreshable rules, but for some reason not able to make it work. Plz throw some light on this.
    Thanks
    Srinivas Vemuri

    You will need to use WHEN OTHERS EXCEPTION handler which is not a good idea to do so if you dont handle the same approprialtly then the exception would go un-noticed:
    SQL> ed
    Wrote file afiedt.buf
      1  begin
      2  execute immediate 'drop table my_Test';
      3  exception
      4  when others then
      5  dbms_output.put_line(SQLCODE||SQLERRM);
      6* end;
    SQL> /
    -942ORA-00942: table or view does not exist
    PL/SQL procedure successfully completed.
    SQL>

  • Materialized view log update question

    Hi, I am running into a question regarding mview - not sure if it should behave that way or I didn't use it right.
    I have two base tables, sales and customers (drived from nested materialized view example in oracle doc):
    CREATE TABLE sales
    cust_ID VARCHAR2(32 BYTE) NOT NULL,
    amount_sold NUMBER,
    TEMP VARCHAR2(100 BYTE),
    CONSTRAINT sales_pk PRIMARY KEY (cust_id)
    CREATE TABLE customers
    cust_ID VARCHAR2(32 BYTE) NOT NULL,
    CUST_LAST_NAME VARCHAR2(100 BYTE),
    TEMP VARCHAR2(100 BYTE),
    CONSTRAINT cust_pk PRIMARY KEY (cust_id)
    CREATE MATERIALIZED VIEW LOG ON sales
    WITH ROWID (cust_id, amount_sold);
    CREATE MATERIALIZED VIEW LOG ON customers
    WITH ROWID (cust_id, cust_last_name);
    Then I create a fast refresh materialized view based on them:
    CREATE MATERIALIZED VIEW join_sales_cust
    REFRESH FAST ON DEMAND AS
    SELECT c.cust_id, c.cust_last_name, s.amount_sold, s.rowid srid, c.rowid crid
    FROM sales s, customers c
    WHERE s.cust_id = c.cust_id;
    Since this materialized view only invole cust_id and amount_sold from sales and cust_id and last_name from customers table, I do not want to trigger materialized view log entry if the TEMP column value gets updated. So follow update shouldn't trigger mlog:
    update sales set TEMP='TEMP2' where cust_id=1
    but this update should:
    update sales set amount_sold=3 where cust_id=1
    What I am seeing happenning is any update on the base table will triger mlog entried regardless whether the column is involed in the materialized view or not.
    Can someone please confirm if this is the correct behavior and whether there is a way to accomplish what I wanted to do?
    Thank you!
    Edited by: user3933488 on Jan 8, 2010 12:53 PM

    You created the materialized view logs with some columns, which is not necessary when creating a join MV on top of them. You can happily skip those in your MV log definition. And then it becomes clear that those columns are not involved in the decision whether a MV log needs to be updated or not. Everything that happens to the base table gets recorded. The "WITH ROWID" and "INCLUDING NEW VALUES" and the column list only specify WHAT should be recorded when something changed.
    Regards,
    Rob.

  • Refresh a materialized view in parallel

    Hi,
    To improve the refresh performance for a materialized view, I set up it to be refreshed in parallel. The view can be refreshed successfully, however, I did not see the view is refreshed in parallel from session browser, can someone let me know if I miss any steps?
    1) In DB A (running 8 CPUs), set up the base table to be parallelized, the base table is called table1
    ALTER TABLE A.table1 PARALLEL ( DEGREE Default INSTANCES Default );
    2) In Database A, set up the materialized view log
    CREATE MATERIALIZED VIEW LOG
    ON table1 WITH primary key
    INCLUDING NEW VALUES;
    3) In Database B (in the same server with Database A), there is an existing table called table1, prebuilt with millions of records in the table. Due to the size of table1, I have to use prebuilt option
    Drop MATERIALIZED VIEW table1;
    CREATE MATERIALIZED VIEW table1 ON PREBUILT TABLE
    REFRESH FAST with primary key
    AS
    select /*+ PARALLEL(table1, 8) */ *
    from table1@A;
    4) in Database B, I executed this stored procedure -
    EXECUTE DBMS_MVIEW.REFRESH(LIST=>'table1',PARALLELISM=>8, METHOD=>'F');
    Thanks in advance!
    Liz

    I checked the execution plan when I executed the refresh stored procedure again, Does the plan indicates the parallel execution is working or not?
    SELECT STATEMENT REMOTE ALL_ROWSCost: 32,174 Bytes: 775,392 Cardinality: 1,182                                                   
    13 PX COORDINATOR                                              
    12 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10001 :Q1001                                        
         11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1001                                   
         9 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1001Cost: 32,174 Bytes: 775,392 Cardinality: 1,182                               
              6 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1001                         
                   5 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1001                    
                        4 PX SEND ROUND-ROBIN PARALLEL_FROM_SERIAL SYS.:TQ10000 A               
                             3 VIEW APP_USR. Cost: 12,986 Bytes: 6,070,196 Cardinality: 275,918           
                                  2 HASH UNIQUE Cost: 12,986 Bytes: 9,105,294 Cardinality: 275,918      
                                       1 TABLE ACCESS FULL TABLE A.MLOG$_TABLE1 A Cost: 10,518 Bytes: 9,105,294 Cardinality: 275,918
         8 PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_PARENT :Q1001Cost: 0 Cardinality: 1                          
         7 INDEX RANGE SCAN INDEX (UNIQUE) PARALLEL_COMBINED_WITH_PARENT A.PK_TABLE1 :Q1001Cost: 0 Cardinality: 1                     
    10 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT A.TABLE1 :Q1001Cost: 0 Bytes: 634 Cardinality: 1

  • Need help on tuning materialized view refresh

    Hi All,
    I am working on materialized view refresh tuning.Initially it was complete refresh and used to take more than 90 mins to complete.
    I changed it to fast refresh now it is completing fast. Now i have partitioned the base tables gl_balances and gl_code_combinations of column code_combination_id and created a local index on column code_combination_id then i am trying to partition the materialized on the same column to take advantage of partition change tracking.
    Size of gl_balances base tables is 40Gb and all others tables sizes are small. In where clause there all the 4 tables are mapped. If i will create the partition only on code_combination_id will i the materialized will become the candidate for partition change tracking. As i know it will be applicable for PCT. I need expert advice on this.
    While doing a fast refresh. the refresh takes less time. when there is a change in gl_balances , gl_code_combinations or gl_periods it completes in 20-30 mins. When there is a change in gl_set_of_books tables. It creates a problem here.DEL query takes more than 48 hours to complete.
    CREATE MATERIALIZED VIEW apps.BAL_PART
    REFRESH FAST ON DEMAND
    ENABLE QUERY REWRITE as
    SELECT GL.GL_CODE_COMBINATIONS21.ROWID C1,GL.GL_BALANCES21.ROWID C2, GL.GL_SETS_OF_BOOKS.ROWID C3,
    GL.GL_PERIOD.ROWID C4,
    "GL"."GL_BALANCES21"."ACTUAL_FLAG" ,
    "GL"."GL_BALANCES21"."CURRENCY_CODE" ,
    "GL"."GL_BALANCES21"."PERIOD_NUM" ,
    "GL"."GL_BALANCES21"."PERIOD_YEAR" ,
    "GL"."GL_BALANCES21"."SET_OF_BOOKS_ID" "SOB_ID",
    "GL"."GL_CODE_COMBINATIONS21"."CODE_COMBINATION_ID" "CCID",
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT1" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT10" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT11" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT12" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT13" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT14" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT2" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT3" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT4" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT5" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT6" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT7" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT8" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT9" ,
    "GL"."GL_PERIODS"."PERIOD_NAME" ,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal_Cr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal_Cr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) Open_Bal_Dr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Close_Bal_Dr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) -
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal,
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Period_Cr,
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Period_Dr
    FROM GL.GL_CODE_COMBINATIONS21,
    GL.GL_BALANCES21,
    GL.GL_SETS_OF_BOOKS,
    GL.GL_PERIODS
    WHERE GL.GL_BALANCES21.CODE_COMBINATION_ID =GL.GL_CODE_COMBINATIONS21.CODE_COMBINATION_ID
    AND GL.GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID = GL.GL_BALANCES21.SET_OF_BOOKS_ID
    AND GL.GL_PERIODS.PERIOD_NUM = GL.GL_BALANCES21.PERIOD_NUM
    AND GL.GL_PERIODS.PERIOD_YEAR = GL.GL_BALANCES21.PERIOD_YEAR
    AND GL.GL_PERIODS.PERIOD_TYPE = GL.GL_BALANCES21.PERIOD_TYPE
    AND GL.GL_PERIODS.PERIOD_NAME = GL.GL_BALANCES21.PERIOD_NAME
    AND GL.GL_PERIODS.PERIOD_SET_NAME = GL.GL_SETS_OF_BOOKS.PERIOD_SET_NAME
    and gl.GL_CODE_COMBINATIONS21.summary_flag != 'Y'TRACE 1046 del statement
    DELETE FROM "APPS"."apps.BAL_PART" SNA$
    WHERE "C3" IN (SELECT /*+ NO_MERGE  */ * FROM (SELECT 
      CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM "GL"."MLOG$_GL_SETS_OF_BOOKS"
      "MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1 ) AS OF SNAPSHOT(:B_SCN) MAS$)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1  17759.00  171782.99  159422121    1267371 2564144739           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2  17759.00  171782.99  159422121    1267371 2564144739           0
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 175  (APPS)   (recursive depth: 1)
    Rows     Row Source Operation
          0  DELETE  apps.BAL_PART (cr=0 pr=0 pw=0 time=0 us)
    193128740   NESTED LOOPS  (cr=592437 pr=592422 pw=0 time=945244160 us cost=339302 size=168 card=1)
          3    SORT UNIQUE (cr=7 pr=0 pw=0 time=15832 us cost=2 size=138 card=1)
         24     TABLE ACCESS FULL MLOG$_GL_SETS_OF_BOOKS (cr=7 pr=0 pw=0 time=19 us cost=2 size=138 card=1)
    193128740    INDEX RANGE SCAN C3BOOKS (cr=592430 pr=592422 pw=0 time=789499200 us cost=339299 size=3318314250 card=110610475)(object id 2114736)
    error during execute of EXPLAIN PLAN statement
    ORA-08187: snapshot expression not allowed here
    parse error offset: 314
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                   159520897        2.12     144415.96
      latch: cache buffers chains                   134        0.06          0.68
      latch: undo global data                        33        0.02          0.15
      latch: object queue header operation          521        0.02          0.53
      log file switch (private strand flush incomplete)
                                                    532        0.31         28.26
      resmgr:cpu quantum                            155        1.40         13.49
      resmgr:internal state change                   25        0.11          2.21
      latch free                                     10        0.00          0.00
      latch: cache buffers lru chain                  4        0.00          0.00
      rdbms ipc reply                               489        0.02          0.54
      reliable message                              587        0.00          0.56
      latch: row cache objects                        3        0.00          0.00
    ********************************************************************************GL_SETS_OF_BOOKS has only 6 rows. I know there is complete refresh as a option which will again take more than 90 mins.
    I want to do the fast refresh. Tables rows details below.
    SQL> select count(*) from gl.gl_code_combinations21;
    COUNT(*)
    3075255
    SQL> select count(*) from gl.GL_PERIODS;
    COUNT(*)
    1160
    SQL> select count(*) from gl.gl_balances21;
    COUNT(*)
    477613527
    SQL> select count(*) from gl.gl_sets_of_books;
    COUNT(*)
    6gl_sets_of_books has less rows. Whenever there is a change then it mapped to huge rows hence during materialized view has delete huge number of rows.
    select count(*) from apps.BAL_PART group by C3;
    C3 is the rowid which is present in create materialized statement.
    COUNT(*)
    292927011
    210215
    69330
    184406971
    Is there any way to improve the plan. As i created a partition on code_combination_id and local index on code_combination_id which will not help in set_of_books_id case. I dont PCT will help here or not. Is it possible to use PCT refresh by equipartitioning only one column in where clause.
    Please assist me in improving refresh of materialized view using fast refresh.
    Thanks and Regards,
    Edited by: user646034 on Feb 23, 2013 11:13 PM
    Edited by: user646034 on Feb 23, 2013 11:19 PM
    Edited by: user646034 on Feb 23, 2013 11:46 PM
    Edited by: user646034 on Feb 25, 2013 11:46 AM

    Hi
    The below explain without index and with index.
    /* MV_REFRESH (DEL) */ DELETE FROM "APPS"."BAL_PART                                                                                                                                                                                                                                                                                                                                                                                                                
    " SNA$ WHERE "C3" IN (SELECT /*+ NO_MERGE  */ * FROM (SELECT                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
    CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
    "GL"."MLOG$_GL_SETS_OF_BOOKS" "MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    ) AS OF SNAPSHOT(:B_SCN) MAS$)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         
    Plan hash value: 2704021294                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | Id  | Operation            | Name                          | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   0 | DELETE STATEMENT     |                               |        |       |   339K(100)|          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   1 |  DELETE              | BAL_PART                          |        |       |            |          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   2 |   NESTED LOOPS       |                               |      1 |   168 |   339K  (1)|999:59:59 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   3 |    SORT UNIQUE       |                               |      1 |   138 |     2   (0)| 00:02:31 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   4 |     TABLE ACCESS FULL| MLOG$_GL_SETS_OF_BOOKS        |      1 |   138 |     2   (0)| 00:02:31 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   5 |    INDEX RANGE SCAN  | C3BOOKS                       |    110M|  3164M|   339K  (0)|999:59:59 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    If i will not use the C3 index then the query will use the belolw plan, I guess this will also take same time or more time.
    |   0 | DELETE STATEMENT       |                               |        |       |  9743K(100)|          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
    |   1 |  DELETE                | BAL_PART                          |       |            |          |                                                                                                                                                                                                                                                                                                                                                                                                     

  • Materialized view takes long to refresh

    On Oracle 11g2, I created a materialized view fast refresh on commit 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 one single row into one of the master table
    insert into jcase_x_offense (offense_id,jcase_id) values ('test_row3','test_row3');
    commit; The commit tooks a quite long. I looked into the trace file and the actual insert took 0.01 seconds but one of the internel DML took most of time. I copy the relevant TKPROF output for the internal DML belowINSERT 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)Questions:
    1) what are the objects like JCASE AS OF SNAPSHOT(:B_SCN) ? Can I index them? I tried access it but got error
    select * from JCASE AS OF SNAPSHOT(:B_SCN) ;
    ORA-08187: snapshot expression not allowed here
    08187. 00000 - "snapshot expression not allowed here"
    *Cause:    A snapshot expression using AS OF was specified when not allowed.
    *Action:   Do not use the AS OF clause
    2) In the inline view following the firs FROM, it used ROWID in where clause. I tried create an index on ROWID, and error
    create index idx_jcase_offense_rid on JCASE_X_OFFENSE(rowid)
    ERROR at line 1:
    ORA-00904: : invalid identifier
    Note: I checked that I have indexes all fields in all where clauses in the DML except rowid.
    Thanks for help.

    sybrand_b wrote:
    1 Apparently Oracle is using Flashback technology when no materialized view logs have been set up
    As your MV is a complex MV it is not a candidate for FAST REFRESH ON COMMIT.
    I haven't looked closely at how 11.2 has changed the "fast refresh on commit" - but I would have expected it to raise an Oracle error when the OP tried to create the materialized view with that option if it were not possible.
    I think your first comment is probably the more important one - if the user sets up suitable materialized view logs on all the tables in the outer join then it's possible that the fast refresh could work properly.
    This is pure speculation, of course, based on the absence of an error message.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
    +"Science is more than a body of knowledge; it is a way of thinking"+
    +Carl Sagan+                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

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

  • Regarding Error in Materialized view Fast Refresh

    ORA-12015: cannot create a fast refresh materialized view from a complex query
    CREATE MATERIALIZED VIEW MVCONTENTHISTORY_01
    BUILD IMMEDIATE
    REFRESH FAST
    WITH PRIMARY KEY
    ENABLE QUERY REWRITE
    AS
    SELECT a.DAY, a.contentname,
    SUM
    (CASE
    WHEN (b.subscriptionstartdate) <= (a.DAY)
    AND ((CASE
    WHEN b.subscriptionenddate IS NOT NULL
    THEN (a.DAY)
    ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
    END
    ) <=
    (CASE
    WHEN b.subscriptionenddate IS NOT NULL
    THEN (b.subscriptionenddate)
    ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
    END
    THEN 1
    ELSE 0
    END
    ) COUNT,
    COUNT
    (CASE
    WHEN (b.subscriptionstartdate) <= (a.DAY)
    AND ((CASE
    WHEN b.subscriptionenddate IS NOT NULL
    THEN (a.DAY)
    ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
    END
    ) <=
    (CASE
    WHEN b.subscriptionenddate IS NOT NULL
    THEN (b.subscriptionenddate)
    ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
    END
    THEN 1
    ELSE 0
    END
    ) cnt
    FROM TBLTDATEWISECONTENT a,
    (SELECT TRUNC (a.subscriptionstartdate) subscriptionstartdate,
    TRUNC (a.subscriptionenddate) subscriptionenddate, b.NAME,
    b.contentid
    FROM syntbltcontentsubscrhistory a, syntblmcontent b
    WHERE b.contentid = a.contentid(+)) b
    WHERE a.contentid = b.contentid(+) AND a.DAY = b.subscriptionstartdate(+)
    GROUP BY a.contentname, a.DAY;
    I can't create Materialized view with fast Refresh .
    Kindly provide solution .
    Regards,
    nayana chavda.

    Kindly provide full Oracle version since option vary by release.
    There error message says it is impossible to fast refresh based on a complex query.
    On 10g Oracle provides a package procedure that will tell you why the view cannot be fast refreshed: dbms_mview.explain_mview.
    Otherwise see the Advanced Replication Manual for a list of restrictions.
    10gR2 >>Restrictions for Materialized Views with Subqueries
    The defining query of a materialized view with a subquery is subject to several restrictions to preserve the materialized view's fast refresh capability.
    The following are restrictions for fast refresh materialized views with subqueries:
    Materialized views must be primary key materialized views.
    The master's materialized view log must include certain columns referenced in the subquery. For information about which columns must be included, see "Logging Columns in the Materialized View Log".
    If the subquery is many to many or one to many, join columns that are not part of a primary key must be included in the materialized view log of the master. This restriction does not apply to many to one subqueries.
    The subquery must be a positive subquery. For example, you can use the EXISTS condition, but not the NOT EXISTS condition.
    The subquery must use EXISTS to connect each nested level (IN is not allowed).
    Each table can be in only one EXISTS expression.
    The join expression must use exact match or equality comparisons (that is, equi-joins).
    Each table can be joined only once within the subquery.
    A primary key must exist for each table at each nested level.
    Each nested level can only reference the table in the level above it.
    Subqueries can include AND conditions, but each OR condition can only reference columns contained within one row. Multiple OR conditions within a subquery can be connected with an AND condition.
    All tables referenced in a subquery must reside in the same master site or master materialized view site.
    <<
    HTH -- Mark D Powell --
    Message was edited by: added list of restrictions left off initial post
    mpowel01

  • Create Materialized View with GROUP BY

    I have a table
    treecluster NUMBER(3)
    treenumber NUMBER(3)
    treedate DATE
    nestnumber NUMBER(3)
    eggs NUMBER(3)
    nestlings NUMBER(3)
    fledglings NUMBER(3)
    nestfate VARCHAR2(10)
    nestfailurecode NUMBER(2)
    I want to group the data by treecluster, treenumber, year, and nest number and get a max eggs, nestlings, fledglings. I am doing this with the following:
    SELECT treecluster, treenumber, to_char(nestchecksdate, 'YYYY'), nestnumber,
    max(eggs), max(nestlings), max(fledglings)
    FROM nestchecks
    GROUP BY treecluster, treenumber, to_char(nestchecksdate, 'YYYY'), nestnumber;
    This works fine.
    The last record for a year has a nestfate and nestfailurecode value.
    I need to group all information and then also get the nestfate and nestfailurecode for the year. How do I go about getting this information?
    I am really trying to create a summary materialized view based on a data table so the select I am trying to craft would be a part of a create materialized view as SELECT...
    so I want to be able to group the info and add in the nestfate and failurecode in one step.
    Thanks!

    try this:
    SQL> select * from table_tree;
    TREECLUSTER TREENUMBER NESTCHECK NESTNUMBER       EGGS  NESTLINGS FLEDGLINGS NESTFATE   NESTFAILURECODE
              4        167 17-MAY-00          2          0          0
              4        167 24-MAY-00          2          3          0
              4        167 30-MAY-00          2          3          0
              4        167 12-JUN-00          2          0          1            FAILURE                  2
    select a.treecluster, a.treenumber, to_char(a.nestyear,'YYYY') nestyear,
           a.nestnumber, a.eggs, a.nestlings, a.fledglings, a.nestfate, a.nestfailurecode
    from   (select max(treecluster) treecluster, max(treenumber) treenumber,
                   max(nestchecksdate) nestyear,
                   max(nestnumber) nestnumber, max(eggs) eggs, max(nestlings) nestlings,
                   nvl(max(FLEDGLINGS),0) FLEDGLINGS, max(NESTFATE) NESTFATE,
                   max(nestfailurecode) nestfailurecode
            from table_tree) a
    TREECLUSTER TREENUMBER NEST NESTNUMBER       EGGS  NESTLINGS FLEDGLINGS NESTFATE   NESTFAILURECODE
              4        167 2000          2          3          1          0 FAILURE                  2hope this helps

  • Please help with the query creating Materialized View

    Hi,
    We are using the below query to create a Materialized View but it has been running since 3 hours. It is an Oracle 9i database running in HP-UX.The quey is as follows,
    (SELECT
    /*+ use_nl(A) parallel (A,4)*/
    A.ICD_CODE AS ICD_CODE,
    A.ICD_DESC AS ICD_DESC,
    A.PROC_GROUP as PROC_GROUP,
    B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
    B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
    C.PROC_TYPE AS PROC_TYPE ,
    C.I_O_IND AS I_O_IND,
    C.DISC_MON AS QUARTER ,
    B.PAT_KEY AS PAT_KEY ,
    D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
    C.PROV_ID AS PROV_ID ,
    A.SPECIALTY AS SPECIALTY
    FROM
    EES_ICD_9_CODE A ,
    EES_CLINICAL_COMPL_DATA B,
    EES_CLINICAL_DATA C,
    EES_CLINCL_COMPL_ICD D                                                                            
    WHERE A.ICD_CODE= B.ICD_CODE
                    AND B.ICD_CODE= C.ICD_CODE
                    AND B.COMPL_ICD_CODE=D.ICD_9_CD
                    AND B.PAT_KEY=C.PAT_KEY
                    AND B.COMPL_ICD_CODEB.ICD_CODE
                    AND C.PROC_TYPE  'L'
                    AND B.COMPL_GRP_TXT'Reoperations'
                    AND D.COMPL_TYPE_TXT'Intra-operative Misadventure'
                    AND C.DISC_MON>='2003101'
                    AND A.SPECIALTY='Colo-Rectal')
    union
    (SELECT
    /*+ use_nl(A) parallel (A,4)*/
    A.ICD_CODE AS ICD_CODE,
    A.ICD_DESC AS ICD_DESC,
    A.PROC_GROUP as PROC_GROUP,
    B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
    B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
    C.PROC_TYPE AS PROC_TYPE ,
    C.I_O_IND AS I_O_IND,
    C.DISC_MON AS QUARTER ,
    B.PAT_KEY AS PAT_KEY ,
    D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
    C.PROV_ID AS PROV_ID ,
    A.SPECIALTY AS SPECIALTY
    FROM
    EES_ICD_9_CODE A ,
    EES_CLINICAL_COMPL_DATA B,
    EES_CLINICAL_DATA C,
    EES_CLINCL_COMPL_ICD D                                                                            
    WHERE A.ICD_CODE= B.ICD_CODE
                    AND B.ICD_CODE= C.ICD_CODE
                    AND B.COMPL_ICD_CODE=D.ICD_9_CD
                   AND B.PAT_KEY=C.PAT_KEY
                    AND B.COMPL_ICD_CODEB.ICD_CODE
                    AND C.PROC_TYPE  'L'
                    --AND B.COMPL_GRP_TXT'Reoperations'
                    AND D.COMPL_TYPE_TXT='Intra-operative Misadventure'
                    AND B.PROC_DAY=C.PROC_DAY
                    AND C.DISC_MON>='2003101'
                    AND A.SPECIALTY='Colo-Rectal')
    union
    (SELECT
    /*+ use_nl(A) parallel (A,4)*/
    A.ICD_CODE AS ICD_CODE,
    A.ICD_DESC AS ICD_DESC,
    A.PROC_GROUP as PROC_GROUP,
    B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
    B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
    C.PROC_TYPE AS PROC_TYPE ,
    C.I_O_IND AS I_O_IND,
    C.DISC_MON AS QUARTER ,
    B.PAT_KEY AS PAT_KEY ,
    D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
    C.PROV_ID AS PROV_ID ,
    A.SPECIALTY AS SPECIALTY
    FROM
    EES_ICD_9_CODE A ,
    EES_CLINICAL_COMPL_DATA B,
    EES_CLINICAL_DATA C,
    EES_CLINCL_COMPL_ICD D                                                                            
    WHERE A.ICD_CODE= B.ICD_CODE
                    AND B.ICD_CODE= C.ICD_CODE
                    AND B.COMPL_ICD_CODE=D.ICD_9_CD
                    AND B.PAT_KEY=C.PAT_KEY
                    AND B.COMPL_ICD_CODEB.ICD_CODE
                    AND C.PROC_TYPE  'L'
                    AND B.COMPL_GRP_TXT='Reoperations'
                    --AND D.COMPL_TYPE_TXT='Intra-operative Misadventure'
                    AND B.PROC_DAY>C.PROC_DAY
                    AND C.DISC_MON>='2003101'
                    AND A.SPECIALTY='Colo-Rectal')
    The explain plan is as follows,
    PLAN_TABLE_OUTPUT
    | Id  | Operation                          |  Name                    | Rows  | Bytes |TempSpc| Cost  |  TQ    |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT                   |                          | 46935 |  6716K|       | 10648 |        |      |            |
    |   1 |  SORT UNIQUE                       |                          | 46935 |  6716K|    14M| 10648 | 45,14  | P->S | QC (RAND)  |
    |   2 |   UNION-ALL                        |                          |       |       |       |       | 45,13  | P->P | HASH       |
    |*  3 |    HASH JOIN                       |                          | 42801 |  6102K|       |  4640 | 45,13  | PCWP |            |
    |*  4 |     TABLE ACCESS FULL              | EES_CLINCL_COMPL_ICD     |   875 | 18375 |       |     2 | 45,02
    |*  5 |     HASH JOIN                      |                          | 41552 |  5072K|    14M|  4638 | 45,13  | PCWP |            |
    |*  6 |      TABLE ACCESS FULL             | EES_CLINICAL_DATA        |  1430K|    40M|       |  2855 | 45,03
    |*  7 |      HASH JOIN                     |                          |   628K|    56M|       |   494 | 45,10  | P->P | HASH       |
    |*  8 |       TABLE ACCESS FULL            | EES_ICD_9_CODE           |    37 |  2183 |       |     1 | 45,08 
    |*  9 |       TABLE ACCESS BY INDEX ROWID  | EES_CLINICAL_COMPL_DATA  |  2090K|    71M|       |   49
    |  10 |        BITMAP CONVERSION TO ROWIDS |                          |       |       |       |       |        |    
    |* 11 |         BITMAP INDEX FULL SCAN     | INX_COMPL_GRP            |       |       |       |       |        |
    |* 12 |    TABLE ACCESS BY INDEX ROWID     | EES_CLINICAL_DATA        |     1 |    33 |       |     1
    |  13 |     NESTED LOOPS                   |                          |  1327 |   196K|       |   947 | 45,13  | PCWP |            |
    |* 14 |      HASH JOIN                     |                          | 60205 |  6996K|       |   495 | 45,13  | PCWP |            |
    |  15 |       TABLE ACCESS BY INDEX ROWID  | EES_CLINCL_COMPL_ICD     |    36 |   756 |       |    
    |* 16 |        INDEX RANGE SCAN            | COMPL_TYPE_TXT_3         |     1 |       |       |     1 |     
    |* 17 |       HASH JOIN                    |                          |  1420K|   132M|       |   494 | 45,13  | PCWP |            |
    |* 18 |        TABLE ACCESS FULL           | EES_ICD_9_CODE           |    37 |  2183 |       |     1 | 45,11 
    |* 19 |        TABLE ACCESS BY INDEX ROWID | EES_CLINICAL_COMPL_DATA  |  4722K|   175M|       |   49
    |  20 |         BITMAP CONVERSION TO ROWIDS|                          |       |       |       |       |        |      |           
    |  21 |          BITMAP INDEX FULL SCAN    | INX_COMPL_GRP            |       |       |       |       |        |
    |* 22 |      INDEX RANGE SCAN              | EES_CLINICAL_DATA_IND1   |     1 |       |       |     2 | 45,13
    |* 23 |    HASH JOIN                       |                          |  2807 |   416K|       |  4695 | 45,13  | PCWP |            |
    |  24 |     TABLE ACCESS FULL              | EES_CLINCL_COMPL_ICD     |   911 | 19131 |       |     2 | 45,06
    |* 25 |     HASH JOIN                      |                          |  2617 |   334K|    15M|  4693 | 45,13  | PCWP |            |
    |* 26 |      TABLE ACCESS FULL             | EES_CLINICAL_DATA        |  1430K|    45M|       |  2855 | 45,07
    |* 27 |      HASH JOIN                     |                          |   791K|    74M|       |   305 | 45,12  | P->P | HASH       |
    |* 28 |       TABLE ACCESS FULL            | EES_ICD_9_CODE           |    37 |  2183 |       |     1 | 45,09 
    |* 29 |       TABLE ACCESS BY INDEX ROWID  | EES_CLINICAL_COMPL_DATA  |  2632K|    97M|       |   30
    |  30 |        BITMAP CONVERSION TO ROWIDS |                          |       |       |       |       |        |    
    |* 31 |         BITMAP INDEX SINGLE VALUE  | INX_COMPL_GRP            |       |       |       |       |        |
    Predicate Information (identified by operation id):
       3 - access("B"."COMPL_ICD_CODE"="D"."ICD_9_CD")
       4 - filter("D"."COMPL_TYPE_TXT"'Intra-operative Misadventure')
       5 - access("B"."ICD_CODE"="C"."ICD_CODE" AND "B"."PAT_KEY"="C"."PAT_KEY")
       6 - filter("C"."PROC_TYPE"'L' AND "C"."DISC_MON">=2003101)
       7 - access("A"."ICD_CODE"="B"."ICD_CODE")
       8 - filter("A"."SPECIALTY"='Colo-Rectal')
       9 - filter("B"."COMPL_ICD_CODE""B"."ICD_CODE")
      11 - filter("B"."COMPL_GRP_TXT"'Reoperations')
      12 - filter("B"."ICD_CODE"="C"."ICD_CODE" AND "C"."PROC_TYPE"'L' AND "B"."PROC_DAY"="C"."PROC_DA
      14 - access("B"."COMPL_ICD_CODE"="D"."ICD_9_CD")
      16 - access("D"."COMPL_TYPE_TXT"='Intra-operative Misadventure')
      17 - access("A"."ICD_CODE"="B"."ICD_CODE")
      18 - filter("A"."SPECIALTY"='Colo-Rectal')
      19 - filter("B"."COMPL_ICD_CODE""B"."ICD_CODE")
      22 - access("B"."PAT_KEY"="C"."PAT_KEY")
      23 - access("B"."COMPL_ICD_CODE"="D"."ICD_9_CD")
      25 - access("B"."ICD_CODE"="C"."ICD_CODE" AND "B"."PAT_KEY"="C"."PAT_KEY")
           filter("B"."PROC_DAY">"C"."PROC_DAY")
      26 - filter("C"."PROC_TYPE"'L' AND "C"."DISC_MON">=2003101)
      27 - access("A"."ICD_CODE"="B"."ICD_CODE")
      28 - filter("A"."SPECIALTY"='Colo-Rectal')
      29 - filter("B"."COMPL_ICD_CODE""B"."ICD_CODE")
      31 - access("B"."COMPL_GRP_TXT"='Reoperations')
    Note: cpu costing is offPlease help.

    Try removing the hints.
    Is 47,000 a reasonable estimate of how many rows you expect in the results?
    See these posts for other information that you should supply.
    HOW TO: Post a SQL statement tuning request
    HOW TO: Post a SQL statement tuning request - template posting
    When your query takes too long
    When your query takes too long ...

  • Query performance on materialized view vs master tables

    Hi,
    I am afraid of strange behavior in db, on my master tables UDBMOVEMENT_ORIG(26mil.rows) and UDBIDENTDATA_ORIG(18mil.rows) is created materialized view TMP_MS_UDB_MV (UDBMOVEMENT is synonym to this object) which meets some default conditions and join condition on these master tables. MV got about 12milions rows. I created MV to query not so huge objects, MV got 3GB, master tables toghether 12GB. But I don't understand that even physical reads and consistent gets are less on MV than on master tables, the final execution time is shorter on master tables. See my log below.
    Why?
    Thanks for answers.
    SQL> set echo on
    SQL> @flush
    SQL> alter system flush buffer_cache;
    System altered.
    Elapsed: 00:00:00.20
    SQL> alter system flush shared_pool;
    System altered.
    Elapsed: 00:00:00.65
    SQL> SELECT
    2 UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBIdentData.sCardSubType, UDBIdentData.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBIdentData.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBIdentData.tTarifTimeStart, UDBIdentData.tTarifTimeEnd, UDBIdentData.cLicensePlate, UDBIdentData.lMoneyValue, UDBIdentData.lPointValue, UDBIdentData.lTimeValue, UDBIdentData.tProdTime, UDBIdentData.tExpireDate
    3 FROM UDBMOVEMENT_orig UDBMovement, Udbidentdata_orig UDBIdentData
    4 WHERE
    5 UDBMovement.lGlobalId = UDBIdentData.lGlobalRef(+) AND UDBMovement.sComputer = UDBIdentData.sComputer(+)
    6 AND UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBIdentData.sCardType IN (2) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
    7 AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25 AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
    8 ORDER BY tActionTime, lBlock, lSequenz;
    4947 rows selected.
    Elapsed: 00:00:15.84
    Execution Plan
    Plan hash value: 1768406139
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 7166 | 1238K| | 20670 (1)| 00:04:09 |
    | 1 | SORT ORDER BY | | 7166 | 1238K| 1480K| 20670 (1)| 00:04:09 |
    | 2 | NESTED LOOPS | | | | | | |
    | 3 | NESTED LOOPS | | 7166 | 1238K| | 20388 (1)| 00:04:05 |
    |* 4 | TABLE ACCESS BY INDEX ROWID| UDBMOVEMENT_ORIG | 7142 | 809K| | 7056 (1)| 00:01:25 |
    |* 5 | INDEX RANGE SCAN | IDX_UDBMOVARTICLE | 10709 | | | 61 (0)| 00:00:01 |
    |* 6 | INDEX UNIQUE SCAN | UDBIDENTDATA_PRIM | 1 | | | 1 (0)| 00:00:01 |
    |* 7 | TABLE ACCESS BY INDEX ROWID | UDBIDENTDATA_ORIG | 1 | 61 | | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    4 - filter("UDBMOVEMENT"."STRANSTYPE">0 AND "UDBMOVEMENT"."SDEVICE"<1000 AND
    BITAND("SSALEFLAG",1)=0 AND "UDBMOVEMENT"."SDEVICE">=0 AND BITAND("UDBMOVEMENT"."SSALEFLAG",4)=0)
    5 - access("UDBMOVEMENT"."TACTIONTIME">=TO_DATE(' 2011-05-05 06:00:00', 'syyyy-mm-dd
    hh24:mi:ss') AND "UDBMOVEMENT"."TACTIONTIME"<TO_DATE(' 2011-05-05 12:00:00', 'syyyy-mm-dd
    hh24:mi:ss') AND "UDBMOVEMENT"."SARTCLASSREF"<100)
    filter("UDBMOVEMENT"."SARTCLASSREF"<100)
    6 - access("UDBMOVEMENT"."LGLOBALID"="UDBIDENTDATA"."LGLOBALREF" AND
    "UDBMOVEMENT"."SCOMPUTER"="UDBIDENTDATA"."SCOMPUTER")
    7 - filter("UDBIDENTDATA"."SCARDTYPE"=2)
    Statistics
    543 recursive calls
    0 db block gets
    84383 consistent gets
    4485 physical reads
    0 redo size
    533990 bytes sent via SQL*Net to client
    3953 bytes received via SQL*Net from client
    331 SQL*Net roundtrips to/from client
    86 sorts (memory)
    0 sorts (disk)
    4947 rows processed
    SQL> @flush
    SQL> alter system flush buffer_cache;
    System altered.
    Elapsed: 00:00:00.12
    SQL> alter system flush shared_pool;
    System altered.
    Elapsed: 00:00:00.74
    SQL> SELECT UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBMovement.sCardSubType, UDBMovement.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBMovement.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBMovement.tTarifTimeStart, UDBMovement.tTarifTimeEnd, UDBMovement.cLicensePlate, UDBMovement.lMoneyValue, UDBMovement.lPointValue, UDBMovement.lTimeValue, UDBMovement.tProdTime
    2 FROM UDBMOVEMENT WHERE
    3 UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBMovement.sCardType IN (2) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
    4 AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
    5 AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5 ORDER BY tActionTime, lBlock, lSequenz;
    4947 rows selected.
    Elapsed: 00:00:26.46
    Execution Plan
    Plan hash value: 3648898312
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 2720 | 443K| 2812 (1)| 00:00:34 |
    | 1 | SORT ORDER BY | | 2720 | 443K| 2812 (1)| 00:00:34 |
    |* 2 | MAT_VIEW ACCESS BY INDEX ROWID| TMP_MS_UDB_MV | 2720 | 443K| 2811 (1)| 00:00:34 |
    |* 3 | INDEX RANGE SCAN | EEETMP_MS_ACTTIMEDEVICE | 2732 | | 89 (0)| 00:00:02 |
    Predicate Information (identified by operation id):
    2 - filter("UDBMOVEMENT"."STRANSTYPE">0 AND BITAND("UDBMOVEMENT"."SSALEFLAG",4)=0 AND
    BITAND("SSALEFLAG",1)=0 AND "UDBMOVEMENT"."SARTCLASSREF"<100)
    3 - access("UDBMOVEMENT"."TACTIONTIME">=TO_DATE(' 2011-05-05 06:00:00', 'syyyy-mm-dd
    hh24:mi:ss') AND "UDBMOVEMENT"."SDEVICE">=0 AND "UDBMOVEMENT"."SCARDTYPE"=2 AND
    "UDBMOVEMENT"."TACTIONTIME"<TO_DATE(' 2011-05-05 12:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
    "UDBMOVEMENT"."SDEVICE"<1000)
    filter("UDBMOVEMENT"."SCARDTYPE"=2 AND "UDBMOVEMENT"."SDEVICE"<1000 AND
    "UDBMOVEMENT"."SDEVICE">=0)
    Statistics
    449 recursive calls
    0 db block gets
    6090 consistent gets
    2837 physical reads
    0 redo size
    531987 bytes sent via SQL*Net to client
    3953 bytes received via SQL*Net from client
    331 SQL*Net roundtrips to/from client
    168 sorts (memory)
    0 sorts (disk)
    4947 rows processed
    SQL> spool off
    Edited by: MattSk on Feb 4, 2013 2:20 PM

    I have added some tkprof outputs on MV and master tables:
    SELECT tmp_ms_udb_mv.zIdDevice, tmp_ms_udb_mv.sDevice, tmp_ms_udb_mv.zIdLocal, tmp_ms_udb_mv.sComputer, tmp_ms_udb_mv.tActionTime, tmp_ms_udb_mv.sCardSubType, tmp_ms_udb_mv.sCardType, tmp_ms_udb_mv.cEpan, tmp_ms_udb_mv.cText, tmp_ms_udb_mv.lArtRef, tmp_ms_udb_mv.sArtClassRef, tmp_ms_udb_mv.lSequenz, tmp_ms_udb_mv.sTransMark, tmp_ms_udb_mv.lBlock, tmp_ms_udb_mv.sTransType, tmp_ms_udb_mv.lGlobalID, tmp_ms_udb_mv.sFacility, tmp_ms_udb_mv.sCardClass, tmp_ms_udb_mv.lSingleAmount, tmp_ms_udb_mv.sVAT, tmp_ms_udb_mv.lVATTot, tmp_ms_udb_mv.tTarifTimeStart, tmp_ms_udb_mv.tTarifTimeEnd, tmp_ms_udb_mv.cLicensePlate, tmp_ms_udb_mv.lMoneyValue, tmp_ms_udb_mv.lPointValue, tmp_ms_udb_mv.lTimeValue, tmp_ms_udb_mv.tProdTime
    FROM tmp_ms_udb_mv WHERE
    tmp_ms_udb_mv.sTransType > 0 AND tmp_ms_udb_mv.sDevice < 1000 AND tmp_ms_udb_mv.sDevice>= 0 AND tmp_ms_udb_mv.sCardType IN (1) AND (bitand(tmp_ms_udb_mv.sSaleFlag,1) = 0 AND bitand(tmp_ms_udb_mv.sSaleFlag,4) = 0) AND tmp_ms_udb_mv.sArtClassRef < 100
    AND tmp_ms_udb_mv.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
    AND tmp_ms_udb_mv.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
    ORDER BY tActionTime, lBlock, lSequenz
    call count cpu elapsed disk query current rows
    Parse 1 0.04 0.10 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 596 0.17 27.07 2874 8894 0 8925
    total 598 0.21 27.18 2874 8894 0 8925
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 60
    Rows Row Source Operation
    8925 SORT ORDER BY (cr=8894 pr=2874 pw=0 time=27071773 us)
    8925 MAT_VIEW ACCESS BY INDEX ROWID TMP_MS_UDB_MV (cr=8894 pr=2874 pw=0 time=31458291 us)
    8925 INDEX RANGE SCAN EEETMP_MS_ACTTIMEDEVICE (cr=68 pr=68 pw=0 time=161347 us)(object id 149251)
    SELECT
    UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBIdentData.sCardSubType, UDBIdentData.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBIdentData.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBIdentData.tTarifTimeStart, UDBIdentData.tTarifTimeEnd, UDBIdentData.cLicensePlate, UDBIdentData.lMoneyValue, UDBIdentData.lPointValue, UDBIdentData.lTimeValue, UDBIdentData.tProdTime, UDBIdentData.tExpireDate
    FROM UDBMOVEMENT_orig UDBMovement, Udbidentdata_orig UDBIdentData
    WHERE
    UDBMovement.lGlobalId = UDBIdentData.lGlobalRef(+) AND UDBMovement.sComputer = UDBIdentData.sComputer(+)
    AND UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBIdentData.sCardType IN (1) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
    AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
    AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
    ORDER BY tActionTime, lBlock, lSequenz
    call count cpu elapsed disk query current rows
    Parse 1 0.03 0.06 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 596 0.76 16.94 3278 85529 0 8925
    total 598 0.79 17.01 3278 85529 0 8925
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 60
    Rows Row Source Operation
    8925 SORT ORDER BY (cr=85529 pr=3278 pw=0 time=16942799 us)
    8925 NESTED LOOPS (cr=85529 pr=3278 pw=0 time=15017857 us)
    22567 TABLE ACCESS BY INDEX ROWID UDBMOVEMENT_ORIG (cr=17826 pr=1659 pw=0 time=7273473 us)
    22570 INDEX RANGE SCAN IDX_UDBMOVARTICLE (cr=111 pr=111 pw=0 time=112351 us)(object id 143693)
    8925 TABLE ACCESS BY INDEX ROWID UDBIDENTDATA_ORIG (cr=67703 pr=1619 pw=0 time=8154915 us)
    22567 INDEX UNIQUE SCAN UDBIDENTDATA_PRIM (cr=45136 pr=841 pw=0 time=3731470 us)(object id 108324)

  • Query against materialized view awful after refresh of Mview

    We have a materialized view defined to refresh complete daily at 5am. YOu can run queries against the MV alone or joining it to other tables. Results come back in 2 or 3 seconds. Once the MView refreshes at 5am - those same queries now take 15 minutes or even more sometimes to complete. WHY IS THIS HAPPENING?? Help anyone?

    okay this is better... sorry...
    this is the GOOD EXPLAIN PLAN:
    PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                      
    | Id  | Operation                         |  Name             | Rows  | Bytes | Cost  |                                                                                                                                                                                                
    |   0 | SELECT STATEMENT                  |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
    |   1 |  SORT AGGREGATE                   |                   |     1 |   127 |       |                                                                                                                                                                                                
    |   2 |   NESTED LOOPS                    |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
    |   3 |    NESTED LOOPS                   |                   |     1 |   113 |  1664 |                                                                                                                                                                                                
    |   4 |     NESTED LOOPS                  |                   |     1 |    99 |  1663 |                                                                                                                                                                                                
    |   5 |      NESTED LOOPS                 |                   |     1 |    88 |  1662 |                                                                                                                                                                                                
    |*  6 |       HASH JOIN ANTI              |                   |     1 |    70 |  1661 |                                                                                                                                                                                                
    |*  7 |        TABLE ACCESS BY INDEX ROWID| CONTACT           |  3815 |   201K|  1534 |                                                                                                                                                                                                
    |   8 |         AND-EQUAL                 |                   |       |       |       |                                                                                                                                                                                                
    |*  9 |          INDEX RANGE SCAN         | IDX_CNT__C_STATE  |       |       |       |                                                                                                                                                                                                
    |* 10 |          INDEX RANGE SCAN         | IDX_CNT__STATUS   |       |       |       |                                                                                                                                                                                                
    |  11 |        INDEX FAST FULL SCAN       | PK_RPP            | 69277 |  1082K|   120 |                                                                                                                                                                                                
    |* 12 |       TABLE ACCESS BY INDEX ROWID | REP_PROFILE       |     1 |    18 |     1 |                                                                                                                                                                                                
    |* 13 |        INDEX UNIQUE SCAN          | PK_C19            |     1 |       |       |                                                                                                                                                                                                
    |* 14 |      INDEX UNIQUE SCAN            | PK_B01            |     1 |    11 |       |                                                                                                                                                                                                
    |* 15 |     INDEX UNIQUE SCAN             | PK_B02            |     1 |    14 |       |                                                                                                                                                                                                
    |* 16 |    INDEX UNIQUE SCAN              | PK_RCN            |     1 |    14 |       |                                                                                                                                                                                                
    Predicate Information (identified by operation id):                                                                                                                                                                                                                                    
       6 - access("B"."CONTACT_ID"="RPP"."PARTNERSHIP_ID")                                                                                                                                                                                                                                 
       7 - filter("B"."C_STATE"='GA' AND "B"."C_LAST"<>'Name Unknown' AND                                                                                                                                                                                                                  
                  "B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
       9 - access("B"."C_STATE"='GA')                                                                                                                                                                                                                                                      
      10 - access("B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
      12 - filter("C19"."TERR1"='46')                                                                                                                                                                                                                                                      
      13 - access("B"."CONTACT_ID"="C19"."CONTACT_ID")                                                                                                                                                                                                                                     
      14 - access("B"."FIRM_ID"="B01"."FIRM_ID")                                                                                                                                                                                                                                           
      15 - access("B"."OFFICE_ID"="B02"."OFFICE_ID")                                                                                                                                                                                                                                       
      16 - access("B"."CONTACT_ID"="RCN"."CONTACT_ID")                                                                                                                                                                                                                                     
    Note: cpu costing is off                                                                                                                                                                                                                                                               
    38 rows selected.

Maybe you are looking for

  • Installation Problem Personal Oracle 8.0.4 on Windows 2000

    When trying to install Personal Oracle 8.0.4 on a Windows 2000 machine, i get an Error: "Unable to delete the NT Service for the SQL *Net V2 Listener". No previous installation of Personal Oracle is present on this machine as it's a newly installed O

  • Windows 8.1 won't boot after VS 2013 express for windows (metro) installation

    I have purchased HP Pavilion e115sm  with AMD A-10 processor and 12GB of RAM notebook, installed windows 8.1 on it, i updated windows with "windows update" and installed all drivers needed. After that, i have tried to install VS 2013 express for wind

  • Capturing line items in the routine-mail order sending problem

    Hi I am sending Sales Order Output to the Email. I have configured the output type Using Option 'External Send' Option. But the Problem is Whenever there are blocks for Sales Order Email Should not be send. 1.    When there is a block in Sales Order

  • Dropdown inside Table - Anyone please?

    Hi Gurus,               This is my first post. Im getting started with Adobe Interactive Forms and Im stucked with something. I need to put a dropdown inside a table cell, I am able to do it but I dont know how to do the binding. When I use a simple

  • Should I get E6?

    Should I get E6? Heard a lot of problems. Especially the notification light. Can someone tell me if the new batch of phones have this bug fixed? Also is the phone laggy sometimes?