Query rewrite with replication Mat. Views

Hi,
Is it possible to have query rewrite using MV's
built from remote tables ?
Thanks for your help
11.20.2

Hi,
Yes , it is possible
GRANT GLOBAL QUERY REWRITE system privilege
use explain _rewrite to verify if rewrite works for MV/sql text
DBMS_MVIEW.EXPLAIN_REWRITE (
query VARCHAR2,
mv VARCHAR2(30),
statement_id VARCHAR2(30));
Thanks,
Ajay More

Similar Messages

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

  • Query Rewrite with regular database Views

    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. However, query rewrite doesn't work no matter how I define the MV and View. Here's an example:
    I've Sales tables with columns: PDate, CustCode, Amount
    and Customer table with columns: CustCode, CustDesc
    I create a view SALES_V with columns: PDate, CustCode, CustDesc, Amount by joining Sales table with Customer table as follows:
    create or replace view SALES_V as
    select PDate, c.CustCode, c.CustDesc, Amount
    from Sales s
    join Customer c on (s.CustCode=c.CustCode);
    For the sake of speed, I create a materialized view SALES_TOT_MV with columns: PDate, Amount with the following SQL:
    create materialized view SALES_TOT_MV
    enable query rewrite
    as select PDate, sum(Amount) Amount from Sales
    group by PDate;
    When I run the following query, I expect it to be rewritten to make use of SALES_TOT_MV:
    select PDate, sum(Amount) from SALES_V
    group by PDate;
    However, explain plan always tell me it's using SALES table, not the SALES_TOT_MV.
    Can somebody tell me it's a limitation of Oracle optimizer or I'm just missing something for this?
    Thanks in advance!!
    - Andrew
    Edited by: blackhole001 on Jan 28, 2010 12:34 PM

    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.

  • Query Rewrite (QSM-01263) and Views in Execution Plan

    Hello!
    I created a query rewrite enabled materialized view from a query, which contains only tables (no views). Query rewrite didn't work, so i checked the query with dbms_mview.explan_rewrite, which told my that my query contains references to views or dictionary tables. I checked my query again, but there are only tables, no views, no dictionary tables.
    When I look in the execution plan of my query I see that the query optimizer generates views, I guess from my subquery (?). "A view definition was processed, either from a stored view...or as defined by steps...".
    I suppose that's the reason why my query rewrite doesn't work. All my other mat views are working fine, so the usual parameters (query_rewrite_enabled, integrity, etc.) are set correctly.
    Do you have any ideas how to get my query rewrite enabled work?
    Thanks!

    Modifying the query (potentially with hints) so that Oracle doesn't do the view transformation would be one option.

  • Very high parse times for query rewrite using cube materialized views

    We recently upgraded to version 11.2.0.2 (both AWM and Oracle database server). We are using cube materialized views with query rewrite enabled. Some observations of changes that took place when we rebuilt all the dimensions and cubes in this version:
    1. Queries against the base tables take about 35 seconds to parse. Then they execute in a tenth of a second. Even simple queries that just get a sum of the amount from the fact table (which is joined to all the dimensions) takes that long to parse. Once parsed, the queries fly.
    2. I noticed that the materialized views used to use grouping sets in the group by clause in version 11.2.0.1, but now they use group by rollup, rollup, rollup...
    If we disable query rewrite on the MV or for my session, parse times drop to less than a second. Ideas?

    There does appear to be a slow down in parse times between 11.1.0.7 and 11.2. We are still investigating this, but in the meantime here is a way to force the code in 11.2 to generate a GROUPING SETS clause instead of the new ROLLUP syntax.
    The trick is to create a dummy hierarchy containing only the leaf level. This is necessary for all dimensions that currently have a single hierarchy. As a simple example I created a dimension, PROD, with three levels, A, B, and C, in a single hierarchy. I then created a one dimensional cube, PC. Here is the SELECT statement for the MV in 11.2. Note the ROLLUP clause in the GROUP BY.
    SELECT
      GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")  SYS_GID,
      (CASE GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")
       WHEN 3
       THEN TO_CHAR(('A_' || T3."CLASS_ID") )
       WHEN 1
       THEN TO_CHAR(('B_' || T3."FAMILY_ID") )
       ELSE TO_CHAR(('C_' || T3."ITEM_ID") )  END)     "PROD",
      T3."CLASS_ID" "D1_PROD_A_ID",
      T3."FAMILY_ID" "D1_PROD_B_ID",
      T3."ITEM_ID" "D1_PROD_C_ID",
      SUM(T2."UNIT_PRICE")     "PRICE",
      COUNT(T2."UNIT_PRICE")  "COUNT_PRICE",
      COUNT(*)  "SYS_COUNT"
    FROM
      GLOBAL."PRICE_AND_COST_FACT" T2,
      GLOBAL."PRODUCT_DIM" T3
    WHERE
      (T3."ITEM_ID" = T2."ITEM_ID")
    GROUP BY
      (T3."CLASS_ID") ,
      ROLLUP ((T3."FAMILY_ID") , (T3."ITEM_ID") )Next I modified the dimension to add a new hierarchy, DUMMY, containing just the leaf level, C. Once I have mapped the new level and re-enabled MVs, I get the following formulation.
    SELECT
      GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")  SYS_GID,
      (CASE GROUPING_ID(T3."CLASS_ID", T3."FAMILY_ID", T3."ITEM_ID")
       WHEN 3
       THEN ('A_' || T3."CLASS_ID")
       WHEN 1
       THEN ('B_' || T3."FAMILY_ID")
       WHEN 0
       THEN ('C_' || T3."ITEM_ID")
       ELSE NULL END)  "PROD",
      T3."CLASS_ID" "D1_PROD_A_ID",
      T3."FAMILY_ID" "D1_PROD_B_ID",
      T3."ITEM_ID" "D1_PROD_C_ID",
      SUM(T2."UNIT_PRICE")     "PRICE",
      COUNT(T2."UNIT_PRICE")  "COUNT_PRICE",
      COUNT(*)  "SYS_COUNT"
    FROM
      GLOBAL."PRICE_AND_COST_FACT" T2,
      GLOBAL."PRODUCT_DIM" T3
    WHERE
      (T3."ITEM_ID" = T2."ITEM_ID")
    GROUP BY
      GROUPING SETS ((T3."CLASS_ID") , (T3."FAMILY_ID", T3."CLASS_ID") , (T3."ITEM_ID", T3."FAMILY_ID", T3."CLASS_ID") )This puts things back the way they were in 11.1.0.7 when the GROUPING SETS clause was used in all cases. Note that the two queries are logically equivalent.

  • Query Rewrite to Utilize Materialized Views on a Remote Database

    We have our materilized views stored at a remote database. Is there a way to utilize query rewrite to rewrite the queries issued on the local database such that queries will refer the materialized views at a remote db?
    From the documentation, I already know that the base tables for MVs and MVs should eside in the same instance or the query should be submitted on the instance where MVs reside if base tables are residing in a different remote DB to benefit from query rewrite.
    My aim is to utilize query rewrite to reduce the workload on a primary database by passing queries that can be rewritten to use MVs on a remote DB.
    Thanks for the guidance,

    My aim is to utilize query rewrite to reduce the workload on a primary database by passing queries that can be rewritten to use MVs on a remote DB. If you know that MVs are not stale or acceptable of staled data and don't see network bandwidth problems (small set of result), You would try accessing MV tables directly on remote db using dblinks.

  • UpdateXML query rewrite with unstructured data?

    Hi,
    I'm currently loading unstructured, non-schema based XML and am trying to address some performance issues when I merge changes to a document.
    I currently read the document from the table, merge the changes using XQuery and save the document back - however, I'm aware that this can be excessive when a minor number of changes are involved (I'm also seeing some contention on the path table when a number of parallel threads are involved).
    I know that using "updateXML" and "insertChildXML" can be more efficient due to the XPath rewrite - however, I'm not sure if this is applicable when the XML is unstructured and non-schema based.
    Any advice on this would be greatly appreciated.
    Regards
    Larry

    Hi Larry,
    I know that using "updateXML" and "insertChildXML" can be more efficient due to the XPath rewrite - however, I'm not sure if this is applicable when the XML is unstructured and non-schema based.XPath rewrite applies to structured (Object-Relational) storage, but to Binary XML and/or XMLIndex as well.
    Besides, with Binary XML and a SECUREFILE LOB storage, a "sliding update" is used when the data is written back to disk (only the modified portion of the LOB is affected) thus reducing the overhead of writing whole documents over and over again even for small changes.
    For example (OOX_SML_WORKBOOK is a binary XMLType table here) :
    -- unstructured XMLIndex with path-subsetting :
    CREATE INDEX oox_sml_workbook_uxi1 ON oox_sml_workbook (object_value) INDEXTYPE IS XDB.XMLIndex
      PARAMETERS ('PATH TABLE oox_sml_workbook_ptb
      PATHS (INCLUDE (/workbook/sheets/sheet)
                         NAMESPACE MAPPING (xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"))');
    -- update of an attribute using updateXML function :
    update oox_sml_workbook
    set object_value = updateXML( object_value
                                , '/workbook/sheets/sheet[@sheetId="3"]/@name'
                                , 'NewName'
                                , 'xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"' )
    where xmlexists('declare default element namespace "http://schemas.openxmlformats.org/spreadsheetml/2006/main"; (::)
                     /workbook/sheets/sheet[@sheetId="3"]'
                    passing object_value)
    ;If you're lucky and currently working with the latest patchset (11.2.0.3), you can also use XQuery Update Facility, a small extension to the XQuery standard that allows various kinds of operations on nodes : inserting (after/before), updating, renaming and deleting.
    This extension supersedes the old proprietary functions updateXML, insertXML etc.
    And it can be optimized via XPath/XQuery rewrite too :
    update oox_sml_workbook
    set object_value =
        xmlquery('declare default element namespace "http://schemas.openxmlformats.org/spreadsheetml/2006/main"; (::)
                  copy $d := .
                  modify (
                    for $i in $d/workbook/sheets/sheet
                    return replace value of node $i/@name with concat("MySheet",$i/@sheetId)
                  return $d'
                  passing object_value
                  returning content)
    ;

  • Query works with indexs but view does not

    Hi,
    I am using the following query:
    SQL> select t.xml_msg_text
    2 from xml_tbl t
    3 where xmlexists (
    4 'declare namespace ns1 = "Abc:SET"; fn:collection("oradb:/DEV/TABLE1")/ROW[ID1=$d/main/ns1:id]'
    5 passing t.xml_msg_text as "d"
    6 );
    It gets executed very fast as it uses the underlying XMLType indexes.
    But if I create a view usign this query. And then Select * from View_Name. It does not use the indexes and takes forever to execute.
    Any suggestions please.
    Thanks..

    Actually I can't create the Explain Plan for this in SqlPlus:
    In the following query:
    select t.xml_msg_text
    from xml_tbl t
    where xmlexists (
    'declare namespace ns1 = "Abc:SET"; fn:collection("oradb:/DEV/TABLE1")/ROW[ID1=$d/main/ns1:id]'
    passing t.xml_msg_text as "d"
    WHEREAS
    I can create the Explain Plan for
    select t.xml_msg_text
    from xml_tbl t
    - There is XQuery Code
    - And TABLE1 is in another schema but I have created the synonym and given the proper rights. That's why I can execute the query but can't see the plan in SQL Plus.
    Please suggest.
    Thanks..

  • Materialized views on prebuilt tables - query rewrite

    Hi Everyone,
    I am currently counting on implementing the query rewrite functionality via materialized views to leverage existing aggregated tables.
    Goal*: to use aggregate-awareness for our queries
    How*: by creating views on existing aggregates loaded via ETL (+CREATE MATERIALIZED VIEW xxx on ON PREBUILT TABLE ENABLE QUERY REWRITE+)
    Advantage*: leverage oracle functionalities + render logical model simpler (no aggregates)
    Disadvantage*: existing ETL's need to be written as SQL in view creation statement --> aggregation rule exists twice (once on db, once in ETL)
    Issue*: Certain ETL's are quite complex via lookups, functions, ... --> might create overy complex SQLs in view creation statements
    My question: is there a way around the issue described? (I'm assuming the SQL in the view creation is necessary for oracle to know when an aggregate can be used)
    Best practices & shared experiences are welcome as well of course
    Kind regards,
    Peter

    streefpo wrote:
    I'm still in the process of testing, but the drops should not be necessary.
    Remember: The materialized view is nothing but a definition - the table itself continues to exist as before.
    So as long as the definition doesn't change (added column, changed calculation, ...), the materialized view doesn't need to be re-created. (as the data is not maintained by Oracle)Thanks for reminding me but if you find a documented approach I will be waiting because this was the basis of my argument from the beginning.
    SQL> select * from v$version ;
    BANNER                                                                                                                                                                    
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production                                                                                                    
    PL/SQL Release 11.2.0.1.0 - Production                                                                                                                                    
    CORE     11.2.0.1.0     Production                                                                                                                                                
    TNS for Linux: Version 11.2.0.1.0 - Production                                                                                                                            
    NLSRTL Version 11.2.0.1.0 - Production                                                                                                                                    
    SQL> desc employees
    Name                                                                                            Null?    Type
    EMPLOYEE_ID                                                                                     NOT NULL NUMBER(6)
    FIRST_NAME                                                                                               VARCHAR2(20)
    LAST_NAME                                                                                       NOT NULL VARCHAR2(25)
    EMAIL                                                                                           NOT NULL VARCHAR2(25)
    PHONE_NUMBER                                                                                             VARCHAR2(20)
    HIRE_DATE                                                                                       NOT NULL DATE
    JOB_ID                                                                                          NOT NULL VARCHAR2(10)
    SALARY                                                                                                   NUMBER(8,2)
    COMMISSION_PCT                                                                                           NUMBER(2,2)
    MANAGER_ID                                                                                               NUMBER(6)
    DEPARTMENT_ID                                                                                            NUMBER(4)
    SQL> select count(*) from employees ;
      COUNT(*)                                                                                                                                                                
           107                                                                                                                                                                
    SQL> create table mv_table nologging as select department_id, sum(salary) as totalsal from employees group by department_id ;
    Table created.
    SQL> desc mv_table
    Name                                                                                            Null?    Type
    DEPARTMENT_ID                                                                                            NUMBER(4)
    TOTALSAL                                                                                                 NUMBER
    SQL> select count(*) from mv_table ;
      COUNT(*)                                                                                                                                                                
            12                                                                                                                                                                
    SQL> create materialized view mv_table on prebuilt table with reduced precision enable query rewrite as select department_id, sum(salary) as totalsal from employees group by department_id ;
    Materialized view created.
    SQL> select count(*) from mv_table ;
      COUNT(*)                                                                                                                                                                
            12                                                                                                                                                                
    SQL> select object_name, object_type from user_objects where object_name = 'MV_TABLE' ;
    OBJECT_NAME                                                                                                                      OBJECT_TYPE                              
    MV_TABLE                                                                                                                         TABLE                                    
    MV_TABLE                                                                                                                         MATERIALIZED VIEW                        
    SQL> insert into mv_table values (999, 100) ;
    insert into mv_table values (999, 100)
    ERROR at line 1:
    ORA-01732: data manipulation operation not legal on this view
    SQL> update mv_table set totalsal = totalsal * 1.1 where department_id = 10 ;
    update mv_table set totalsal = totalsal * 1.1 where department_id = 10
    ERROR at line 1:
    ORA-01732: data manipulation operation not legal on this view
    SQL> delete from mv_table where totalsal <= 10000 ;
    delete from mv_table where totalsal <= 10000
    ERROR at line 1:
    ORA-01732: data manipulation operation not legal on this view While investigating for this thread I actually made my own question redundant as the answer became gradually clear:
    When using complex ETL's, I just need to make sure the complexity is located in the ETL loading the detailed table, not the aggregate
    I'll try to clarify through an example:
    - A detailed Table DET_SALES exists with Sales per Day, Store & Product
    - An aggregated table AGG_SALES_MM exists with Sales, SalesStore per Month, Store & Product
    - An ETL exists to load AGG_SALES_MM where Sales = SUM(Sales) & SalesStore = (SUM(Sales) Across Store)
    --> i.e. the SalesStore measure will be derived out of a lookup
    - A (Prebuilt) Materialized View will exist with the same column definitions as the ETL
    --> to allow query-rewrite to know when to access the table
    My concern was how to include the SalesStore in the materialized view definition (--> complex SQL!)
    --> I should actually include SalesStore in the DET_SALES table, thus:
    - including the 'Across Store' function in the detailed ETL
    - rendering my Aggregation ETL into a simple GROUP BY
    - rendering my materialized view definition into a simple GROUP BY as wellNot sure how close your example is to your actual problem. Also don't know if you are doing an incremental/complete data load and the data volume.
    But the "SalesStore = (SUM(Sales) Across Store)" can be derived from the aggregated MV using analytical function. One can just create a normal view on top of MV for querying. It is hard to believe that aggregating in detail table during ETL load is the best approach but what do I know?

  • Oracle Query Rewrite Alias Problem

    Hi,
    The problem desribed below is regarding the use of oracle aggregate awareness through the use of query rewrite.
    2 materialized views exist (one agg per day, one agg per month) and 1 dimension exists for time (date - month - quarter - year)
    Query rewrite seems to be working fine for a query as such (alias sql = alias mv):
    select DDFPC.MONTH_NO
    from BIDATA_MAIN.DF_REPOSITORY_SUBSET DF2, BIDATA_MAIN.DD_TIME DDFPC
    where DF2.FINANCIAL_PROCCESSING_DATE_ID = DDFPC.DATE_ID and DF2.ROUTING_CODE_ISS IN ('FPC','NCC')
    group by DDFPC.MONTH_NO
    However, considering our reporting tool generates aliases on the fly, we could get the following query (alias sql <> alias mv):
    select T2.MONTH_NO
    from BIDATA_MAIN.DF_REPOSITORY_SUBSET DF2, BIDATA_MAIN.DD_TIME T2
    where DF2.FINANCIAL_PROCCESSING_DATE_ID = T2.DATE_ID and DF2.ROUTING_CODE_ISS IN ('FPC','NCC')
    group by T2.MONTH_NO
    --> for the second query, query rewrite refuses to correctly use the dimension – it’ll rewrite to the DD (daily) aggregate, but not to the MM (monthly) aggregate
    Investigation gives: QSM-01072: materialized view, DA_REPOSITORY_MERCHANT_MM, and query have different joins between tables, DF_REPOSITORY_SUBSET and DD_TIME
    So*: How can query rewrite be forced to take place with different aliases between query & materialized view – taken into account a dimension is used for aggregation-awareness?
    This seems to indicate it should work...

    You are missing a join on the file_id column
    i.e.
    select sum(f.BLOCKS), sum(d.BLOCKS) from dba_free_space f ,dba_data_files d where f.TABLESPACE_NAME=d.TABLESPACE_NAME and f.TABLESPACE_NAME like SUBSTR('KU_TSD_1',0,10)
    and f.file_id = d.file_id
    This might have been easier to detect if you had removed the sum aggregation and looked at the data coming back from the raw query.

  • Need Help in Mat View Creation

    I have the following query to create a mat view
    CREATE MATERIALIZED VIEW IB_CONT1
    REFRESH FAST ON DEMAND WITH ROWID
    AS
      SELECT
            CUST,
            CONSEQ,
            STD,
            ENDD,
            ADD     
    FROM
         ADMIN.CONTACT@IB_DBLINK;But it displays an error as
            ADMIN.CONTACT@IB_DBLINK
    ERROR at line 11:
    ORA-12018: following error encountered during code generation for
    "OWNER"."IB_CONT1"
    ORA-00942: table or view does not existBut when i query the table i displays data.
    SQL> select count(*) from admin.contact@ib_dblink;
      COUNT(*)
          100what could be the reason?
    Any help will be highly appreciated.
    Thanks in advance.

    Try without ROWID option.
    Regards
    RK

  • Query rewrite for COUNT(DISTINCT)

    Hi,
    I am having fact table with different dimension keys.
    CREATE TABLE FACT
    TIME_SKEY NUMBER
    REGION_SKEY NUMBER,
    AC_SKEY NUMBER
    I need to take COUNT(DISTINCT(AC_SKEY) for TIME_SKEY and REGION_SKEY. There are oracle dimension defined for time and region which are using TIME_SKEY and REGION_SKEY. I have created MV with query rewrite with COUNT(DISTINCT) but it is not using dimension if I am using any other level and MV can't be fast refreshed as it was build using COUNT(DISTINCT).
    CREATE MATERIALIZED VIEW AC_MV
    NOCACHE
    NOLOGGING
    NOCOMPRESS
    NOPARALLEL
    BUILD IMMEDIATE
    REFRESH COMPLETE ON DEMAND
    WITH PRIMARY KEY
    ENABLE QUERY REWRITE
    AS
    SELECT
    TIME_SKEY ,
    REGION_SKEY,
    COUNT (DISTINCTAC_SKEY)
    FROM FACT
    GROUP BY TIME_SKEY, REGION_SKEY;
    Query used to retrieve data is as below
    SELECT TIME_SKEY, COUNT(DISTINCT AC_SKEY) OVER (PARTITION BY TIME_SKEY) UNIQ_AC, COUNT(DISTINCT AC_SKEY) OVER () UNIQ_AC1
    FROM FACT;
    There can be other queries based on time / region dimension.
    Can you please provide help in solving above issue?
    Thanks,
    Pritesh

    What version of the Oracle database?

  • Are Cube organized materialized view with Year to Date calculated measure eligible for Query Rewrite

    Hi,
    Will appreciate if someone can help me with a question regarding Cube organized MV (OLAP).
    Does cube organized materialized view with calculated measures based on time series  Year to date, inception to date  eg.
    SUM(FCT_POSITION.BASE_REALIZED_PNL) OVER (HIERARCHY DIM_CALENDAR.CALENDAR BETWEEN UNBOUNDED PRECEDING AND CURRENT MEMBER WITHIN ANCESTOR AT DIMENSION LEVEL DIM_CALENDAR."YEAR")
    are eligible for query rewrites or these are considered advanced for query rewrite purposes.
    I was hoping to find an example with YTD window function on physical fact dim tables  with optimizer rewriting it to Cube Org. MV but not much success.
    Thanks in advance

    I dont think this is possible.
    (My own reasoning)
    Part of the reason query rewrite works for base measures only (not calc measures in olap like ytd would be) is due to the fact that the data is staged in olap but its lineage is understandable via the olap cube mappings. That dependency/source identification is lost when we build calculated measures in olap and i think its almost impossible for optimizer to understand the finer points relating to an olap calculation defined via olap calculation (olap dml or olap expression) and also match it with the equivalent calculation using relational sql expression. The difficulty may be because both the olap ytd as well as relational ytd defined via sum() over (partition by ... order by ...) have many non-standard variations of the same calculation/definition. E.g: You can choose to use or choose not to use the option relating to IGNORE NULLs within the sql analytic function. OLAP defn may use NASKIP or NASKIP2.
    I tried to search for query rewrite solutions for Inventory stock based calculations (aggregation along time=last value along time) and see if olap cube with cube aggregation option set to "Last non-na hierarchical value" works as an alternative to relational calculation. My experience has been that its not possible. You can do it relationally or you can do it via olap but your application needs to be aware of each and make the appropriate backend sql/call. In such cases, you cannot make olap (aw/cubes/dimensions) appear magically behind the scenes to fulfill the query execution while appearing to work relationally.
    HTH
    Shankar

  • Materialized Views with Query Rewrite is not getting re-written

    I have tried everything that has been mentioned in all the forums here and on metalink to fix this issue, has any smart APEX user found a solution?
    The issue is the MV with Query rewrite capability is not being re-written.
    Things I have tried
    1) give all Query Rewrite privileges to all 3 APEx schemas and parsing schema;
    2) check trace files with tkprof;
    3) dynamically printed explain plan from v$_SQL on the page while executing the query;
    4) to test in a different environment i created an another DAD using the pl/sql webtool kit and tried the same thing and rewrite works like a charm...
    whats the issue here...why are apex schemas not re-writing the queries????
    appreciate any help...thanks

    Jes, per your request
    --create materialized view
    CREATE MATERIALIZED VIEW "RPLANSWEB"."MV_FCG_ALL_SUMMARY_TAB"
    ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
    STORAGE(INITIAL 81920 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "RPLANSWEB"
    BUILD IMMEDIATE
    USING INDEX
    REFRESH FORCE ON DEMAND
    USING DEFAULT LOCAL ROLLBACK SEGMENT
    ENABLE QUERY REWRITE
    AS SELECT fcg, year, fcg_desc,
    fac, efr, fac_desc, efr_desc,
    ums_round, fcg_allow_drillable allow_drillable,
    MAX(category_code_um1) category_code_um1,
    SUM(perm_asset) perm_asset,
    SUM(temp_asset) temp_asset,
    SUM(semi_asset) semi_asset,
    SUM(lease_asset) lease_asset,
    SUM(planned_constr) planned_constr,
    SUM(all_perm_asset) all_perm_asset,
    SUM(total_asset) total_asset,
    SUM(allow) allow, SUM(rqmt) rqmt,
    SUM(perm_planned_constr) perm_planned_constr,
    SUM(perm_planned_constr_rqmt_delta) perm_planned_constr_rqmt_delta,
    ROUND(DECODE(SUM(rqmt), 0, 0, SUM(all_perm_asset)/SUM(rqmt)*100)) perm_rqmt_pctsat,
    ROUND(DECODE(SUM(allow), 0, 0, SUM(all_perm_asset)/SUM(allow)*100)) perm_allw_pctsat,
    ROUND(DECODE(SUM(rqmt), 0, 0, SUM(total_asset)/SUM(rqmt)*100)) total_rqmt_pctsat,
    ROUND(DECODE(SUM(allow), 0, 0, SUM(total_asset)/SUM(allow)*100)) total_allw_pctsat,
    ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(rqmt)/SUM(all_perm_asset)*100)) perm_rqmt_pctutl,
    ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(allow)/SUM(all_perm_asset)*100)) perm_allw_pctutl,
    ROUND(DECODE(SUM(total_asset), 0, 0, SUM(rqmt)/SUM(total_asset)*100)) total_rqmt_pctutl,
    ROUND(DECODE(SUM(total_asset), 0, 0, SUM(allow)/SUM(total_asset)*100)) total_allw_pctutl,
    SUM(coarse_screen_asset) coarse_screen_asset,
    SUM(total_excess) total_excess,
    SUM(total_deficit) total_deficit,
    SUM(perm_excess) perm_excess,
    SUM(perm_deficit) perm_deficit,
    SUM(all_perm_excess) all_perm_excess,
    SUM(all_perm_deficit) all_perm_deficit,
    SUM(temp_excess) temp_excess,
    SUM(satisfy_rqmt) satisfy_rqmt
    FROM summary_tab_dd
    GROUP BY fcg, year, fcg_desc,
    fac, efr, fac_desc, efr_desc,
    ums_round, fcg_allow_drillable;
    sql plus> log in as parsing schema user (not APEX_PUBLIC_USER)
    sql plus> SELECT fcg, year, fcg_desc,
    SUM(perm_asset) perm_asset,
    SUM(perm_excess) perm_excess,
    SUM(perm_deficit) perm_deficit,
    SUM(all_perm_excess) all_perm_excess,
    SUM(all_perm_deficit) all_perm_deficit,
    SUM(temp_excess) temp_excess,
    SUM(satisfy_rqmt) satisfy_rqmt
    FROM summary_tab_dd
    where year=2007
    GROUP BY fcg, year, fcg_desc;
    --execution plan
    SELECT STATEMENT     ALL_ROWS     12     291     17460                         
    HASH(GROUP BY)          12     291     17460                         
    MAT_VIEW REWRITE ACCESS(FULL) RPLANSWEB.MV_FCG_ALL_SUMMARY_TAB     ANALYZED     11     291     17460                         "MV_FCG_ALL_SUMMARY_TAB"."YEAR"=2007
    --execution plan from sql workshop (application express)
    SELECT STATEMENT 42,341 55 3,882 1,990,027
    HASH GROUP BY 42,341 55 3,882 1,990,027
    TABLE ACCESS FULL SUMMARY_TAB_DD 109,158 47 3,329 5,130,426 "YEAR" = 2007
    --execution plan from an APEX page (displayed from v$sql and V$SQL_PLAN)
    OPERATION: SELECT STATEMENT OPTIONS: OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: ALL_ROWS SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: BYTES: CPU_COST: IO_COST: ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION:
    OPERATION: HASH OPTIONS: GROUP BY OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: 109158 BYTES: 8732640 CPU_COST: 549150132 IO_COST: 4569 ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION: "FCG"[VARCHAR2,6], "FCG_DESC"[VARCHAR2,15], SUM("PERM_DEFICIT")[22], SUM("PERM_EXCESS")[22], SUM("SATISFY_RQMT")[22], SUM("TEMP_EXCESS")[22], SUM("ALL_PERM_EXCESS")[22], SUM("ALL_PERM_DEFICIT")[22], SUM("PERM_ASSET")[22]
    OPERATION: TABLE ACCESS OPTIONS: FULL OBJECT_NAME: SUMMARY_TAB_DD OBJECT_ALIAS: SUMMARY_TAB_DD@SEL$1 OBJECT_TYPE: TABLE OPTIMIZER: SEARCH_COLUMNS: 0 COST: 3329
    as you can see while executing the script in sql developer the optimizer is finding the relevant materialized view, not in the case of APEX's SQL Workshop or Page.
    appreciate your time

  • Help with query rewrite and materialized views

    Hello everybody,
    I'm currently learning how to use Oracle (10G Enterprise) and in particular, Materialized Views.
    I seem to have a problem making the optimizer use a materialized view. I have already set the OPTIMIZER_MODE, QUERY_REWRITE_ENABLED and QUERY_REWRITE_INTEGRITY as needed.
    I need to create a materialized view for the following query:
    Q1:
    SELECT PS_SUPPKEY, PS_PARTKEY, PS_SUPPCOST
    FROM PARTSUPPLIER E, PART WHERE PS_PARTKEY=P_PARTKEY and (lower(P_COMMENT) LIKE ''_o_a\%'' or lower(P_COMMENT) LIKE ''_o_u\%'')
    and PS_SUPPCOST =
    (SELECT min( PS_SUPPCOST)
    FROM PARTSUPPLIER I
    WHERE E.PS_PARTKEY=I.PS_PARTKEY)'
    I created it using the following code:
    CREATE MATERIALIZED VIEW mv_q1
    ENABLE QUERY REWRITE
    AS SELECT PS_SUPPKEY, PS_PARTKEY, PS_SUPPCOST
    FROM PARTSUPPLIER E JOIN PART ON (PS_PARTKEY=P_PARTKEY)
    WHERE lower(P_COMMENT) LIKE '_o_a%' or lower(P_COMMENT) LIKE '_o_u%'
    and PS_SUPPCOST=
    (SELECT min( PS_SUPPCOST)
    FROM PARTSUPPLIER I
    WHERE E.PS_PARTKEY=I.PS_PARTKEY);
    I have created the statistics using:
    execute dbms_stats.gather_table_stats('frandres',' mv_q1');
    execute dbms_stats.gather_table_stats('frandres','PARTSUPPLIER');
    execute dbms_stats.gather_table_stats('frandres','PART');
    Both partsupplier and part are tables and not views.
    When executing Q1, the plan does not use the materialized view. Furthermore, when using explain rewrite:
    DECLARE
    qrytxt VARCHAR2(3000) := 'SELECT PS_SUPPKEY, PS_PARTKEY, PS_SUPPCOST
    FROM PARTSUPPLIER E, PART WHERE PS_PARTKEY=P_PARTKEY and (lower(P_COMMENT) LIKE ''_o_a\%'' or lower(P_COMMENT) LIKE ''_o_u\%'')
    and PS_SUPPCOST =
    (SELECT min( PS_SUPPCOST)
    FROM PARTSUPPLIER I
    WHERE E.PS_PARTKEY=I.PS_PARTKEY)';
    BEGIN
    dbms_mview.EXPLAIN_REWRITE
    (qrytxt,'MV_Q1','MV_Q1');
    END;
    I get the following message:
    MESSAGE
    QSM-01150: query did not rewrite
    QSM-01263: query rewrite not possible when query references a dictionary table o
    r view
    QSM-01219: no suitable materialized view found to rewrite this query
    What I can't understand is why it says I am referencing the dictionary or a view?
    If I remove the (lower(P_COMMENT) LIKE ''_o_a\%'' or lower(P_COMMENT) LIKE ''_o_u\%'') condition to the query (using the same materialized view), I get the following message from EXPLAIN_REWRITE:
    MESSAGE
    QSM-01150: query did not rewrite
    QSM-01219: no suitable materialized view found to rewrite this query
    Which is reasonable.
    I don't know if the like condition is messing up my materialized view. Can anyone please help?
    Thanks a lot in advance.
    Edited by: user12072111 on Oct 29, 2009 9:43 PM

    Bingo!
    The 10.2.0.3 patch set is supposed to fix this ( [List of bugs fixed (MVs)|http://www.dbatools.net/doc/bug10203.html#MVIEW] )
    In particular:
    5052568      Query rewrite does not work for SQL with LIKE clause.
    Thank you very much for your message!
    The downside is that I'm only using Oracle for educational purposes and consequently have no Metalink id, so I can't install the patch. Thanks a lot though!

Maybe you are looking for