Materialized views queries

Hi ,
if i am correct , Materialized Views will create a table of exactly the same name as per the MV.
Will the so called "Table" be indexed ? and if not can i put indexes on it ?
and will there be performance issue if i were to specify indexes on MV ?
kindly advise
tks & rdgs

Yes - a materialised view can be indexed. Yes, it should be indexed if that will improve performance.

Similar Messages

Materialized View with Joins

Dear Dev/DBAs,
I have the following scenario:
SQL> CREATE TABLE T1 (ID NUMBER(3),NAME VARCHAR2(10));
SQL> CREATE TABLE T2 (ID NUMBER(3),NAME VARCHAR2(10));
The T1 contains records having the ID num from 10 to 80 and the T2 having the ID from 90 to 170
SQL> SELECT * FROM T1 JOIN ALL SELECT * FROM T2
It give all records in the 2 tables.
I'm planning to create a materialized view (like CREATE MATERIALIZED VIEW V_TAB REFRESH ON COMMIT AS SELECT * FROM T1 JOIN ALL SELECT * FROM T2) and it seems i can't do with the error ORA-12054, further the oracle documentation says that materialized view can only be used with a simple join.
Do you have another solution??
Note that the materialized views can be used to improve queries.
Thank you in advance

Straight from the link I posted:
*Restrictions on Fast Refresh on Materialized Views with UNION ALL*Materialized views with the UNION ALL set operator support the REFRESH FAST option if the following conditions are satisfied:
* The defining query must have the UNION ALL operator at the top level.
The UNION ALL operator cannot be embedded inside a subquery, with one exception: The UNION ALL can be in a subquery in the FROM clause provided the defining query is of the form SELECT * FROM (view or subquery with UNION ALL) as in the following example:
CREATE VIEW view_with_unionall AS
(SELECT c.rowid crid, c.cust_id, 2 umarker
FROM customers c WHERE c.cust_last_name = 'Smith'
UNION ALL
SELECT c.rowid crid, c.cust_id, 3 umarker
FROM customers c WHERE c.cust_last_name = 'Jones');
CREATE MATERIALIZED VIEW unionall_inside_view_mv
REFRESH FAST ON DEMAND AS
SELECT * FROM view_with_unionall;
Note that the view view_with_unionall satisfies the requirements for fast refresh.
* Each query block in the UNION ALL query must satisfy the requirements of a fast refreshable materialized view with aggregates or a fast refreshable materialized view with joins.
The appropriate materialized view logs must be created on the tables as required for the corresponding type of fast refreshable materialized view.
Note that the Oracle Database also allows the special case of a single table materialized view with joins only provided the ROWID column has been included in the SELECT list and in the materialized view log. This is shown in the defining query of the view view_with_unionall.
* The SELECT list of each query must include a maintenance column, called a UNION ALL marker. The UNION ALL column must have a distinct constant numeric or string value in each UNION ALL branch. Further, the marker column must appear in the same ordinal position in the SELECT list of each query block.
* Some features such as outer joins, insert-only aggregate materialized view queries and remote tables are not supported for materialized views with UNION ALL.
* Partiton Change Tracking (PCT)-based refresh is not supported for UNION ALL materialized views.
* The compatibility initialization parameter must be set to 9.2.0 or higher to create a fast refreshable materialized view with UNION ALL.

Explain Plan for Materialized Views in 10g

I am verifying explain plan for few queries on 10g as compared to 9i I was wondering in Materialized Views queries MAT_VIEW ACCESS instead of TABLE ACCESS is it expected behaviour or am missing something?
Couldn't find information in 10g documentation
thanks in advance

I've put together a query for the v$sql_plan in 9iR2.
Depending on what you use, you can probably drop some columns (eg OTHER and partition columns) and you could drive it from the v$session by getting the hash_value from there for the sid you are interested in :
(select * from v$sql_plan where hash_value =
(select sql_hash_value from v$session where sid=:sid))
select level, optimizer, lpad('_',1*(level-1),'_')||operation operation,
options, object_owner||'.'||object_name obj_name, search_columns,
ltrim(to_char(cardinality,'999,999,999')) no_rows,
ltrim(to_char(bytes/1024,'999,999')) kbytes, cost tot_cost,
object_node link, id, parent_id, other_tag||':'||other other,
partition_start, partition_stop, cpu_cost, io_cost,
access_predicates, filter_predicates,
round(temp_space/(1024*1024),2) temp_space_mb
from (select * from v$sql_plan where hash_value = :hash_val)
start with id=0
connect by prior id = parent_id and prior child_number = child_number
order by child_number, id, position;

Creating a Materialized View from different agregate queries

I want to create a materialized view. The problem is that doing so can get sticky. The view should have one row, with each column representing the return of an aggregate function on the base table. Here is a query that returns this kind of result:
select
     (select count(rowid) from pasta) "PASTA_ROWS",
     (select count(salt) from pasta where salt='F') "SALT_IS_FEMALE_ROWS"
from dual;
You can see that by selecting the subqueries from dual, I get the return to be in seperate columns. The problem is that when I try creating a Materialized view, I get an error.
ERROR at line 8:
ORA-22818: subquery expressions not allowed here
So, is there a simple SQL query that will return the values I am asking for, in seperate columns, but will not make the materialized view produce an error?
Thanks,
Edward
For your reference, here is a describe of the pasta table:
SQL> desc pasta
Name Null? Type
CHEESE NUMBER(4)
TOMATO VARCHAR2(20)
SALT VARCHAR2(1)
OREGANO VARCHAR2(20)
OLIVE_OIL VARCHAR2(40)

Edward:
Something like this should work:
SELECT COUNT(*) PASTA_ROWS,
       SUM(DECODE(salt,'F',1,0)) SALT_IS_FEMALE_ROWS
FROM pastaTTFN
John

Problem with queries while refreshing materialized views

We are in oracle 8.1.7. We have some materialized views that are refreshed with DMBS_REFRESH.REFRESH in a Job. The problem is that when the refresh occurs while a query is executing we get a "Invalid Rowid" or "0RA-08103 Object not longer exists" in the session executing the query.
We already have reproduced the problem. Is this a bug ? Any idea?
Thanks.

Check if the objects referred in the MV defination has undergone any reorg recently.

Plan query for hierarhial queries inlude materialized views?

I have this problem;
I have a tree with more levels . In nodes of this tree I have a I have a measure . For leafs I have MV . What's happend with non-leaf nodes? Querying this measure for non-leafs nodes use MV from leafs?
Thanks in advance,
Aurel

Hello Daniel,
Even this problem seems a olap one , I think is choosing an execution plan one. Please have patience :)
I have a 10.2.0.3 Oracle Database and I want to build an OLAP (ROLAP more exactly) application for one client of the firm I work for.
I have 2 dimensions , time_dim and products_dim and a cube(sales) with these two dimensions and a fact table .
Aggregation on products dimension is a little dificult.
I have three tables : products,hierarchy and productsXhierarchy
Hierarchy has a hierarchy
create table Hierarchy(
     id number,
     name varchar2(30),
     idOfParent number,
     path varchar2(30))
obviously path column is redundat but this structure is legacy.
Data look like bellow
217158 name1
234154 name2 217158 name1
345671 name3 234154 name1 -> name2
134567 name4 345671 name1 -> name2 -> name3
134568 name5 345671 name1 -> name2 -> name3
134569 name6 345671 name1 -> name2 -> name3
Products table is
create table Products(
     idProduct number,
     nameOfProduct varchar2(30),
Data look like
10001 nameofproduct
The last table is an intersection table of the first two tables
create table productsXhierarchy{
     id number,
     idhierarchy number,
     idProduct number)
data looks like
1345 134567 10001
1346 134567 10002
1347 134568 10002
1348 134568 10002
1349 134569 10002
Unfortunatelly hierarchy table is a large table , about 8000 records .
There is applicable a solution with materialized view in this case? I though to build MVs only for products ie rows in Products table
My question is : for an intermediate node in hierarchy ie rows in Hierarchy table , lets say name3 row , for calculating sum of sales for this category optimizer will choose to use MVs for products in this category (ie products in m4,m5,m6 categories - 1345,1346,1347,1348,1349)?
Thanks for your patience for reading this,
Aurel

How can I create a materialized view based on hierarchical cube query?

Hi,
database version 10gR2.
When i try to create MV for sql below, i got error .
I tried creating MV log in several ways, but still, keep getting the same error.
SQL Error: ORA-12015: cannot create a fast refresh materialized view from a complex query
12015. 00000 - "cannot create a fast refresh materialized view from a complex query"
*Cause:    Neither ROWIDs and nor primary key constraints are supported for
           complex queries.
*Action:   Reissue the command with the REFRESH FORCE or REFRESH COMPLETE
           option or create a simple materialized view.So, I wonder if it is possible to create MV based on sql below?
if yes, how should I do it?
if no, what is the alternative?
select
      coalesce(UP_ORG_ID_6, UP_ORG_ID_5, UP_ORG_ID_4, UP_ORG_ID_3, UP_ORG_ID_2, UP_ORG_ID_1) as ORG_ID,
      a.day_id as day_id,
      a.TRADE_TYPE_ID as TRADE_TYPE_ID,
      a.CUST_ID,
      coalesce(UP_CODE_6, UP_CODE_5, UP_CODE_4, UP_CODE_3, UP_CODE_2, UP_CODE_1) as product_id,
      QUANTITY_UNIT,
      COST_UNIT,
      A.SOURCE_ID as SOURCE_ID,
      SUM(CONTRACT_AMOUNT) as CONTRACT_AMOUNT,
      SUM(CONTRACT_COST) as CONTRACT_COST,
      SUM(SALE_AMOUNT) as SALE_AMOUNT,
      SUM(SALE_COST) as SALE_COST,
      SUM(ACTUAL_AMOUNT) as ACTUAL_AMOUNT,
      SUM(ACTUAL_COST) as ACTUAL_COST,
      SUM(TRADE_COUNT) as TRADE_COUNT
from DM_F_LO_SALE_DAY a, DM_D_ALL_ORG_FLAT B, DM_D_ALL_PROD_FLAT D
where a.ORG_ID=B.ORG_ID
      and a.PRODUCT_ID=D.CODE
      and a.day_id=20110201
group by rollup(UP_ORG_ID_1, UP_ORG_ID_2, UP_ORG_ID_3, UP_ORG_ID_4, UP_ORG_ID_5, UP_ORG_ID_6),
      a.TRADE_TYPE_ID,
         a.day_id,
      A.CUST_ID,
      rollup(UP_CODE_1, UP_CODE_2, UP_CODE_3, UP_CODE_4, UP_CODE_5, UP_CODE_6),
      a.QUANTITY_UNIT,
      a.COST_UNIT,
      a.SOURCE_ID;Thanks in advance.

Rob vanWjik has an excellent series of fast refresh materialized views starting here:
http://rwijk.blogspot.com/2009/05/fast-refreshable-materialized-view.html
Part three specifically on aggregate MVs is here:
http://rwijk.blogspot.com/2009/06/fast-refreshable-materialized-view.html

Error on creation of Materialized view

Hi all, how are u? :-D
Well, I´m trying to use MATERIALIZED VIEW with refresh fast,
when first I grant permissions on the table action to an user,
after I create the MATERIALIZED VIEW LOG on the master and, finally,
I create the MATERIALIZED VIEW on the target.
-- using other_user:
GRANT SELECT, INSERT, UPDATE, DELETE ON action TO an_user;
CREATE MATERIALIZED VIEW LOG ON action
WITH PRIMARY KEY;
-- using an_user:
CREATE MATERIALIZED VIEW vw_action
REFRESH FAST
START WITH sysdate
NEXT TRUNC(sysdate) + 1/24
AS SELECT * FROM other_user.action;But, when I perform the CREATE MATERIALIZED VIEW the following error occurs:
ERROR at line 5:
ORA-12018: following error encountered during code generation for "AN_USER"."VW_ACTION"
ORA-00942: table or view does not exist
When I execute the query SELECT * FROM other_user.action, the data are returned.
What can it to be?
What´s the problem in this case?
Thank you very much!
[]´s

Hi Nicolas,
Well, I´m using Oracle 9.2.0.1 with Linux Red Hat.
I tryid without synonym and with synonym too, but...
I´m gonna to search for a solution.
And I´m gonna to try use the action recommended by oracle:
ORA-12015 cannot create a fast refresh materialized view from a complex query
Cause: Neither ROWIDs nor primary key constraints are supported for complex queries.
Action: Reissue the command with the REFRESH FORCE or REFRESH COMPLETE option or create a simple materialized view.thank you very much!
[]´s

How to use materialized view in stored procedure

in my stored procedure I use couple of queries (see the script below). I want to create materialized views to replace these queries. Is it possible to achieve and how to achieve it in my case? thanks in advance
set serveroutput on
DECLARE
v_cur_tid NUMBER(5):=0;
v_cur_cs_attendance NUMBER(5):=0;
v_cur_c_tot_enrolments NUMBER(5):=0;
v_most_enrolments NUMBER(5):=0;
v_least_enrolments NUMBER(5):=0;
v_most_pop_cid NUMBER(5):=0;
v_least_pop_cid NUMBER(5):=0;
CURSOR class_cursor IS
select
id,
name,
max_attendees
from
class
where
id in (select distinct(event_id) from trainer_schedule where event_type='c' and is_active='y')
order by id;
BEGIN
DBMS_OUTPUT.PUT_LINE('==================================================================================================================================');
--print the report header
DBMS_OUTPUT.PUT_LINE('Summary Report No.3: Training Class Active Schedules Summary Report');
FOR r_class IN class_cursor LOOP
--print the header or subsection
select sum(enrolments) into v_cur_c_tot_enrolments from class_schedule where class_id = r_class.id;
IF v_most_enrolments < v_cur_c_tot_enrolments OR v_most_enrolments = 0
THEN v_most_enrolments := v_cur_c_tot_enrolments; v_most_pop_cid := r_class.id;
END IF;
IF v_least_enrolments > v_cur_c_tot_enrolments OR v_least_enrolments = 0
THEN v_least_enrolments := v_cur_c_tot_enrolments; v_least_pop_cid := r_class.id;
END IF;
DBMS_OUTPUT.PUT_LINE('******************************************************************************************');
DBMS_OUTPUT.PUT_LINE('CLASS_ID: ' || r_class.id ||'     '|| 'CLASS_NAME: ' || r_class.name ||'     '||'CAPACITY: ' || r_class.max_attendees ||'     '||'TOTAL_ENROLMENTS: ' || v_cur_c_tot_enrolments);
DBMS_OUTPUT.PUT_LINE(rpad('____________', 12) || lpad('____________', 12) || lpad('____________________', 20) || lpad('____________________', 20) || lpad('____________',12) || lpad('____________',12));
DBMS_OUTPUT.PUT_LINE(rpad('SCHEDULE_ID', 12) || lpad('TRAINER_ID',12) || lpad('START_TIME', 20) || lpad('END_TIME',20) || lpad('ENROLMENTS',12) || lpad('ATTENDANCE',12));
DBMS_OUTPUT.PUT_LINE(rpad('____________', 12) || lpad('____________',12) || lpad('____________________', 20) || lpad('____________________', 20) || lpad('____________',12) || lpad('____________',12));
FOR r_cs IN (select id,to_char(start_time,'DD-MM-YYYY HH24:Mi') as start_time, to_char(end_time,'DD-MM-YYYY HH24:Mi') as end_time, enrolments from class_schedule where class_id = r_class.id order by id)
LOOP
select trainer_id into v_cur_tid from trainer_schedule where event_type='c' and event_id = r_cs.id;
select count(training_session.id) into v_cur_cs_attendance
from training_session, class_schedule
where training_session.attended = 'y' and
training_session.type='c'and
to_char(training_session.start_time,'DD-MM-YYYY HH24:Mi') = to_char(class_schedule.start_time,'DD-MM-YYYY HH24:Mi') and
class_schedule.id = r_cs.id;
DBMS_OUTPUT.PUT_LINE(rpad(r_cs.id, 12) || lpad(v_cur_tid,12) || lpad(r_cs.start_time, 20) || lpad(r_cs.end_time,20) || lpad(r_cs.enrolments,12) || lpad(v_cur_cs_attendance,12));
END LOOP;
END LOOP;
DBMS_OUTPUT.PUT_LINE('******************************************************************************************');
DBMS_OUTPUT.PUT_LINE('******************************************************************************************');
DBMS_OUTPUT.PUT_LINE('MOST_POPULAR_CLASS: '||v_most_pop_cid||'      TOTAL_ENROLMENTS_TO_DATE: '||v_most_enrolments);
DBMS_OUTPUT.PUT_LINE('LEAST_POPULAR_CLASS: '||v_least_pop_cid||'      TOTAL_ENROLMENTS_TO_DATE: '||v_least_enrolments);
DBMS_OUTPUT.PUT_LINE('==================================================================================================================================');
END;
/

Hi,
you could use Dynamic SQL /Execute immediate to run DDL from a stored procedure.
http://download-uk.oracle.com/docs/cd/B10501_01/appdev.920/a96624/11_dynam.htm
Could you please tell why do you want to create a materialized view in stored procedure ?
How frequently you will runt this procedure . It would is better to create a MV once and use it.
thanks

Do I need to tune the base query of my materialized view ?

Hi gurus,
We implement materialized view (FAST REFRESH ON COMMIT) on base table used in OLTP system. In fact the MV itself is also queried by the OLTP system itself, interactively.
Currently user complain that after they input transaction, they see that the MV is not refresh as soon as they commit the transaction.
(it takes 5 to 10 minutes before they see the update on the MV)
The query of the MV is attached below, it consists of union all of two queries but actually the real query has 13 queries on a UNION ALL.
The question is :
Do I need to tune the query that forms the MV ?
Does it impact the refresh time of the MV ?
Thank you for your help,
xtanto
SELECT GRNH.DOC_CODE ||' '|| GRNH.GRN_NO, GRNH.GRN_DATE, GRNH.REGS_CODE,
F_Convert_Qty_K(GRND.PRODUCT, GRND.QTY, GRND.UOM) QTY_IN, 0 QTY_OUT, 0 QTY_ADJ, 'N/A'.....
FROM GRN_LOCAL_D GRND
          JOIN GRN_LOCAL_H GRNH ON GRNH.GRNH_ID = GRND.GRNH_ID
          WHERE GRND.PRODUCT IS NOT NULL AND GRNH.WH_CODE IS NOT NULL
UNION ALL
SELECT GRNH.DOC_CODE ||' '|| GRNH.GRN_NO, GRNH.GRN_DATE, GRNH.REGS_CODE,
F_Convert_Qty_K(GRND.PRODUCT_B, GRND.QTY_B, GRND.UOM_B) QTY_IN, 0 QTY_OUT, 0 QTY_ADJ, 'N/A'...
FROM GRN_LOCAL_D GRND
JOIN GRN_LOCAL_H GRNH ON GRNH.GRNH_ID = GRND.GRNH_ID
WHERE GRND.PRODUCT_B IS NOT NULL AND GRNH.WH_CODE IS NOT NULL
UNION ALL
     ......

Hi Justin & APC,
Are they seeing a 5-10 minute delay in being able to commit their transaction?NO, the commit itself is completed normally, but after that when they go to the page (this is webbased app) that display data from the MV, the newly committed transactionis not there yet. Only after 5-10 minutes we can see the new data.
What does the F_Convert_Qty_K() function do?It is a function that convert the quantity from whatever Unit Of Measurement (UOM) into the smallest UOM. Below is the code.
So the question remains:
why intermittently theere is delay before the new data visible in the MV ?
Thanks you,
xtanto
CREATE OR REPLACE FUNCTION F_Convert_Qty (pProduct VARCHAR2, pQty NUMBER, pUOM VARCHAR2)
RETURN NUMBER
IS
vQtyBase NUMBER(13,5);
BEGIN
SELECT CASE WHEN pUOM = ( SELECT UOM_BASE FROM PRODUCTS WHERE PRODUCT = pProduct)
          THEN pQty
     ELSE
               SELECT ROUND(pQty * Coefficient / Divisor, 5)
               FROM (
                         SELECT Coefficient, Divisor FROM CONVERT_UOM
                         WHERE PRODUCT = pProduct AND UOM_CONVERT = pUOM
                         ) tmp
          END INTO vQtyBase FROM DUAL;
--RETURN (vQtyBase) ;
RETURN ( NVL(vQtyBase,0) ) ;
END F_Convert_Qty;
/

Hi experts pls help me with this materialized view refresh time!!!

Hi Expeerts ,
Please clarify my doubt about this materialized view code
[\n]
CREATE MATERIALIZED VIEW SCHEMANAME.products_mv
REFRESH WITH ROWID
AS SELECT * from VIEW_TABLE@DATAOPPB;
[n]
Here i am creating a materialized view named products_mv of the view_table present in the remote server.Can anyone tell me when will my table product_mv will get refreshed if i follow this code.As what i read from the books is that the refresh period is implicit and is carried out by the database implicitly.so can u tell me suppose i insert 2 new records into my view_table when will this record get updated into my product_mv table.
I cant use primary key approach so this is the approach i am following .Kindly help me in understanding when will refresh of records occur in the materialized view product_mv...Pls help
regards
debashis

Hi Justin ,
Yes, my database can reasonably schedule other jobs too .Its not an issue.
Actually what i meant "fine in all aspects" is that will the matrerialized view will get refreshed w.r.t the documetum_v table present in my remote server.This is all i need to refresh my materialized view .
I queries the DBA_JOBS table .I could see the following result i have pasted below:-
[\n]
NLS_ENV
MISC_ENV INSTANCE
dbms_refresh.refresh('"WORKFLOW"."PRODUCTS_MV2"');
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
[n]
here WORKFLOW"."PRODUCTS_MV2 is the materialized view i have created.So can u tell me that whether we can predict our refresh part is functioning fine from this data.If so how?
Actually i am asking u in details as i dont have much exposure to materialized view .I am using it for the very first time.
Regds
debashis

Issue in Materialized view

Hi,
Am facing the below issue while creating MV,
create materialized view log on a;
cretae materialized view log ob b;
create materialized view
refresh fast on commit
as
select a.x,a.y,b.z
from a,b
where
a.i=b.i and
a.bill_dt > trunc(add_months(sysdate,-12),'month');
And am getting ORA-12054 Kindly suggest me how can achive this?
Thanks,
Siva

I don't really have a good idea, sorry.
If an MV can be partitioned, then maybe monthly partitioning on the MV could be an option. But I guess (I do not know for certain) that an MV would not support dropping old partions.
An alternative solution (but it is somewhat a kludge) would be an MV that refreshes complete every night (no refresh fast on commit, no MV logs.) Then you create a view that selects from the MV all data before today and uses union all to a select that queries the base tables for todays data. It will not be as fast to query as an MV refresh on commit, but it might be fast enough?
I do not see another way - but maybe some other forum user has a good idea? ;-)

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

Materialized views - query rewrite -- optional joins & dimensions

Hi,
I've implemented a number of materialized views that are accessible via query rewrite.
Most of these views make use of duplicate tables (DD_TIME table is joined via purchase, load, process, ... date columns)
I've also created a dimension to make Oracle aware of the time relation (month is child of year...)
The issue:
--> If I create the mat. view with inner joins, query rewrite works with the dimensions, but I need to provide ALL joined tables in the query
--> If I create the mat. view with outer joins, query rewrite works even with 1 joined table, but the dimension seems to be ignored
How can I create 'optional' joins in the Mat. View while making use of dimensions for rollup?
(the limitations on materialized view delta joins mentioned on [oracle docs|http://docs.oracle.com/cd/B28359_01/server.111/b28313/qradv.htm#autoId16] kinda has me worried)
Example Mat. View:
CREATE MATERIALIZED VIEW DA_REPOSITORY_MERCHANT_MM
... ENABLE QUERY REWRITE
AS SELECT
DDFPC.YEAR_NO,
DDFPC.YEAR_MONTH,
DDPUR.YEAR_NO,
DDPUR.YEAR_MONTH,
SUM( DF.TRANSACTION_AMOUNT )
FROM DF_REP DF,
DD_TIME DDFPC,
DD_TIME DDPUR
WHERE DF.FPC_DTE = DDFPC.DAY_DATE(+)
AND DF.PUR_DTE = DDPUR.DAY_DATE(+)
GROUP BY
DDFPC.YEAR_NO,
DDFPC.YEAR_MONTH,
DDPUR.YEAR_NO,
DDPUR.YEAR_MONTH
Example query launched:
SELECT
DDFPC.YEAR_NO,
SUM( DF.TRANSACTION_AMOUNT )
FROM DF_REP DF,
DD_TIME DDFPC
WHERE DF.FPC_DTE = DDFPC.DAY_DATE
GROUP BY
DDFPC.YEAR_NO

The problem was resolved by setting foreign keys in the fact table and making them not nullable + using inner joins.
--> this informs oracle there can be no difference between a query without the dimensions and a query with the dimensions.
As a result, the materialized view can contain 1 fact linked to 2 dimension tables, but the query rewrite will work for queries on the 1 fact joined with only 1 dimension

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.

Materialized views queries

Similar Messages

Maybe you are looking for