Risky enable star transformations and trusted Query Rewrites?

Hi,
I need some advice/opinions from someone experienced with large scale
data warehousing.
I'm working on a fairly large data warehouse (around 3 TB), and we're
using Oracle 10.1.0.2.0.
So, I found out about MV's and Star Transformations, and that we're not
using them.
Naturally I decided to try them out in our test environment and I was
more than pleased (actually, I nearly wet my pants) with the potential
performance boost we could get for some of our more critical solutions.
However, I also noticed that the production environment has the
following settings:
star_transformation_enabled = false
query_rewrite_integrity = enforced
...which basically disables all the cool stuff. In the testing
environment I used the following:
star_transformation_enabled = true
query_rewrite_integrity = trusted (to make use of func. dep in
dimensions)
I would like to stand on somewhat solid grounds and increase my
understanding before aproaching our DBA's with the suggestion to change
system global settings :)
Basically, my question(s) are:
1. What are the impact of enabling Star Transformations on a system?
Is there any at all, if no previous solution has been built in a way
to
make use of star transformations?
Or could this change result in fine-tuned queries performing badly
since they
suddenly make use of star transformations?
2. Is "query_rewrite_integrity" used by Oracle for other things besides
Materialized Views?
I'm thinking, if the only thing it's used for is to resolve query
rewrites for MV's, then it's safe to change it, because there are no
such MV's.
Note that I'd like to set it to TRUSTED, in order to make real use
of the dependencies declared with CREATE DIMENSION...
I would be happy to know what you think about this.
Any thoughts, opinions are welcome since this is new grounds for me.
Best Regards
R.

Following parameters are deprecated in release 10.2.
LOGMNR_MAX_PERSISTENT_SESSIONS
MAX_COMMIT_PROPAGATION_DELAY
REMOTE_ARCHIVE_ENABLE
SERIAL_REUSE
SQL_TRACE
Check this in your parameter file.
As per Oracle Errors Documents.
Error : ORA-32004
Cause:     One or more obsolete and/or parameters were specified in the
     SPFILE or the PFILE on the server side.
Action:     See alert log for a list of parameters that are obsolete. or
     deprecated. Remove them from the SPFILE or the server side PFILE
Regards,
Sabdar Syed.

Similar Messages

Star transformation and Partition pruning

All experts,
I need advice on my situation -
I have data warehouse running on oracle 11.2.0.1
We are using star trnasformation. The fact table is partitioned.
However, with the star query (fact joined to dimensions with keys and filters only on dimensions), partition pruning is not happening.
I read some documents online and it seems that partition pruning is not going to happen unless I directly filter fact (which is against the best paractices of star query).
Please advice

SELECT
PTL_EDW.D_TIME.CAL_YYYYMM,
(( ( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.LABOR_COST) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.OUTSIDE_COST) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.PARTS_COST) ) )-( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_LABOR_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_OUTSIDE_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_PARTS_AMOUNT) ) )+( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_LABOR_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_OUTSIDE_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_PARTS_AMOUNT) ) ) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.OIL_COST) ))
FROM
PTL_EDWPERF.F_JOB_OIL_COST,
PTL_EDW.D_LOCATION_MASTER D_LOCATION_DOMICILE,
PTL_EDW.D_VEHICLE_CAP_STATUS,
PTL_EDW.D_UNIT_MASTER,
PTL_EDW.D_ACCOUNT_CODE,
PTL_EDW.D_TIME
WHERE
( PTL_EDWPERF.F_JOB_OIL_COST.ACCOUNT_CODE_KEY = PTL_EDW.D_ACCOUNT_CODE.ACCOUNT_CODE_KEY)
AND ( PTL_EDWPERF.F_JOB_OIL_COST.VEHICLE_CAP_STATUS_KEY=PTL_EDW.D_VEHICLE_CAP_STATUS.VEHICLE_CAP_STATUS_KEY )
AND ( PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY=D_LOCATION_DOMICILE.LOCATION_MASTER_KEY )
AND (PTL_EDWPERF.F_JOB_OIL_COST.UNIT_MASTER_KEY = PTL_EDW.D_UNIT_MASTER.UNIT_MASTER_KEY)
AND (PTL_EDWPERF.F_JOB_OIL_COST.RO_ACCOUNTING_MONTH_KEY = PTL_EDW.D_TIME.TIME_KEY)
AND ( exists (select 1 from ptl_edw.s_location where s_location.ssoid = '600028988' and PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY = decode(s_location.location_master_key, -99999, PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY, s_location.location_master_key)) )
AND
--PTL_EDWPERF.F_JOB_OIL_COST.PARTITION_KEY BETWEEN 201011 AND 201104
PTL_EDW.D_TIME.CAL_YYYYMM BETWEEN 200601 AND 201104
AND
D_LOCATION_DOMICILE.CORP_CD IN ( '2000','HPTL' )
AND
( ( PTL_EDW.D_VEHICLE_CAP_STATUS.VEHICLE_CAP_STATUS ) IN ( 'ACCRUED','ACTIVE' ) )
AND
( PTL_EDW.D_UNIT_MASTER.CONTRACT_GROUP = 'P' )
AND
PTL_EDW.D_UNIT_MASTER.UNIT_CATEGORY IN ( 'TRACTOR','TRAILER','TRUCK' )
AND
PTL_EDW.D_ACCOUNT_CODE.ACCOUNT_CODE_GROUP1 IN ( 'COMMERCIAL RENTAL','CONTRACT MAINTENANCE - GUAR','CONTRACT MAINTENANCE - OTHER','CONTRACT MAINTENANCE - PEG','LEASE','TRAILER PLUS' )
GROUP BY
PTL_EDW.D_TIME.CAL_YYYYMM
-- bg4643wj2d3xn
=====================================
Elapsed: 00:39:35.08
Execution Plan
Plan hash value: 2317670688
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 9 | 666 | | 186K (1)| 00:43:36 | | |
| 1 | HASH GROUP BY | | 9 | 666 | | 186K (1)| 00:43:36 | | |
|* 2 | FILTER | | | | | | | | |
|* 3 | HASH JOIN | | 557K| 39M| | 186K (1)| 00:43:35 | | |
|* 4 | VIEW | index$_join$_006 | 1925 | 19250 | | 16 (7)| 00:00:01 | | |
|* 5 | HASH JOIN | | | | | | | | |
|* 6 | INDEX RANGE SCAN | D_TIME_CALYYYYMM_IDX2 | 1925 | 19250 | | 5 (20)| 00:00:01 | | |
| 7 | INDEX FAST FULL SCAN | D_TIME_TIME_KEY_PK | 1925 | 19250 | | 14 (0)| 00:00:01 | | |
|* 8 | HASH JOIN | | 557K| 34M| 32M| 186K (1)| 00:43:34 | | |
| 9 | PARTITION RANGE ALL | | 557K| 26M| | 131K (1)| 00:30:46 | 1 | 133 |
| 10 | TABLE ACCESS BY LOCAL INDEX ROWID| F_JOB_OIL_COST | 557K| 26M| | 131K (1)| 00:30:46 | 1 | 133 |
| 11 | BITMAP CONVERSION TO ROWIDS | | | | | | | | |
| 12 | BITMAP AND | | | | | | | | |
| 13 | BITMAP MERGE | | | | | | | | |
| 14 | BITMAP KEY ITERATION | | | | | | | | |
| 15 | BUFFER SORT | | | | | | | | |
|* 16 | VIEW | index$_join$_179 | 2 | 20 | | 2 (50)| 00:00:01 | | |
|* 17 | HASH JOIN | | | | | | | | |
| 18 | INLIST ITERATOR | | | | | | | | |
|* 19 | INDEX UNIQUE SCAN | D_CAPSTS_ETL_IDX | 2 | 20 | | 0 (0)| 00:00:01 | | |
| 20 | INDEX FAST FULL SCAN | D_VEHICLE_CAP_STATUS_PK | 2 | 20 | | 1 (0)| 00:00:01 | | |
|* 21 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_VEH_CAP_KY | | | | | | 1 | 133 |
| 22 | BITMAP MERGE | | | | | | | | |
| 23 | BITMAP KEY ITERATION | | | | | | | | |
| 24 | BUFFER SORT | | | | | | | | |
|* 25 | TABLE ACCESS FULL | D_TIME | 1925 | 51975 | | 19 (6)| 00:00:01 | | |
|* 26 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_CST_RO_ACC_MTH_KY | | | | | | 1 | 133 |
| 27 | BITMAP MERGE | | | | | | | | |
| 28 | BITMAP KEY ITERATION | | | | | | | | |
| 29 | BUFFER SORT | | | | | | | | |
|* 30 | TABLE ACCESS FULL | D_ACCOUNT_CODE | 11 | 165 | | 4 (0)| 00:00:01 | | |
|* 31 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_ACCT_CODE_KY | | | | | | 1 | 133 |
| 32 | BITMAP MERGE | | | | | | | | |
| 33 | BITMAP KEY ITERATION | | | | | | | | |
| 34 | BUFFER SORT | | | | | | | | |
|* 35 | VIEW | index$_join$_172 | 3136 | 28224 | | 19 (6)| 00:00:01 | | |
|* 36 | HASH JOIN | | | | | | | | |
| 37 | INLIST ITERATOR | | | | | | | | |
|* 38 | INDEX RANGE SCAN | D_LOCNMST_ETL_IDX | 3136 | 28224 | | 12 (17)| 00:00:01 | | |
| 39 | INDEX FAST FULL SCAN | LOCATION_MASTER_KEY_PK | 3136 | 28224 | | 10 (0)| 00:00:01 | | |
|* 40 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_CHRG_LOCN_KY | | | | | | 1 | 133 |
|* 41 | TABLE ACCESS FULL | D_UNIT_MASTER | 1790K| 23M| | 51484 (2)| 00:12:01 | | |
|* 42 | TABLE ACCESS BY INDEX ROWID | S_LOCATION | 1 | 23 | | 12 (0)| 00:00:01 | | |
|* 43 | INDEX RANGE SCAN | S_LOCN_SSOID_IDX | 14 | | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "PTL_EDW"."S_LOCATION" "S_LOCATION" WHERE "S_LOCATION"."SSOID"='600028988' AND
DECODE("S_LOCATION"."LOCATION_MASTER_KEY",(-99999),:B1,"S_LOCATION"."LOCATION_MASTER_KEY")=:B2))
3 - access("F_JOB_OIL_COST"."RO_ACCOUNTING_MONTH_KEY"="D_TIME"."TIME_KEY")
4 - filter("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
5 - access(ROWID=ROWID)
6 - access("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
8 - access("F_JOB_OIL_COST"."UNIT_MASTER_KEY"="D_UNIT_MASTER"."UNIT_MASTER_KEY")
16 - filter("D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACCRUED' OR "D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACTIVE')
17 - access(ROWID=ROWID)
19 - access("D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACCRUED' OR "D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACTIVE')
21 - access("F_JOB_OIL_COST"."VEHICLE_CAP_STATUS_KEY"="D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS_KEY")
25 - filter("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
26 - access("F_JOB_OIL_COST"."RO_ACCOUNTING_MONTH_KEY"="D_TIME"."TIME_KEY")
30 - filter("D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='COMMERCIAL RENTAL' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT MAINTENANCE
- GUAR' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT MAINTENANCE - OTHER' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT
MAINTENANCE - PEG' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='LEASE' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='TRAILER PLUS')
31 - access("F_JOB_OIL_COST"."ACCOUNT_CODE_KEY"="D_ACCOUNT_CODE"."ACCOUNT_CODE_KEY")
35 - filter("D_LOCATION_DOMICILE"."CORP_CD"='2000' OR "D_LOCATION_DOMICILE"."CORP_CD"='HPTL')
36 - access(ROWID=ROWID)
38 - access("D_LOCATION_DOMICILE"."CORP_CD"='2000' OR "D_LOCATION_DOMICILE"."CORP_CD"='HPTL')
40 - access("F_JOB_OIL_COST"."CHARGING_LOCATION_KEY"="D_LOCATION_DOMICILE"."LOCATION_MASTER_KEY")
41 - filter("D_UNIT_MASTER"."CONTRACT_GROUP"='P' AND ("D_UNIT_MASTER"."UNIT_CATEGORY"='TRACTOR' OR
"D_UNIT_MASTER"."UNIT_CATEGORY"='TRAILER' OR "D_UNIT_MASTER"."UNIT_CATEGORY"='TRUCK'))
42 - filter(DECODE("S_LOCATION"."LOCATION_MASTER_KEY",(-99999),:B1,"S_LOCATION"."LOCATION_MASTER_KEY")=:B2)
43 - access("S_LOCATION"."SSOID"='600028988')
Note
- star transformation used for this statement
Statistics
3034 recursive calls
0 db block gets
28519518 consistent gets
1075291 physical reads
0 redo size
2519 bytes sent via SQL*Net to client
567 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
64 rows processed
Partition is range on YYYYMM(numeric format)

11g OLAP cube MV's with Query Rewrite option

Hi All,
I am trying to test the 11g OLAP cube MV's with the Query Rewrite option.
I had created a cube on the schema OLAPTRAIN problem by oracle. I an selected necessary options in 'Materialized Views' tab of the Cube definition in AWM. here is the screenshot
!http://i40.tinypic.com/9jzpte.png!
and then I try to run the SQL query
select SUM(S.QUANTITY) AS QUAN,
SUM(S.SALES) AS SALES,
T.CALENDAR_YEAR_NAME,
P.DEPARTMENT_NAME,
C.COUNTRY_NAME
FROM
TIMES T,CUSTOMERS C,PRODUCTS P, SALES_FACT S
WHERE
C.CUSTOMER_KEY = S.CUSTOMER AND
T.DAY_KEY = S.DAY_KEY AND
P.ITEM_KEY = S.PRODUCT
group by T.CALENDAR_YEAR_NAME, P.DEPARTMENT_NAME, C.COUNTRY_NAME;
and observed the Explain plan, it is not using OLAP cube built, instead it is using the relational tables given in the above sql query.
Also, i have observed that , though enabling or disabling of the Query Rewrite option doesn't make any change in the Explain query for the above query.
alter materialized view olaptrain.cb$sales_cube enable query rewrite;
alter materialized view OLAPTRAIN.cb$sales_cube disable query rewrite;
No idea why is this Query Rewrite feature is not working on my Database instance of 11g R2 . Do am I missing any steps that has be taken care of , to make this working. Any inputs would be appreciated.
Thanks
S

Hi there,
You should check out Note 577293.1 on Metalink - 'Oracle OLAP 11g: How to ensure use of Cube Materialized Views/Query Rewrite'
Thanks,
Stuart Bunby
OLAP Blog: http://oracleOLAP.blogspot.com
OLAP Wiki: http://wiki.oracle.com/page/Oracle+OLAP+Option
OLAP on OTN: http://www.oracle.com/technology/products/bi/olap/index.html
DW on OTN : http://www.oracle.com/technology/products/bi/db/11g/index.html

No query rewriting in a star schema

Gentlemen,
I am facing a problem with query rewriting in a simple data warehouse star schema. I want to take advantage of the built-in roll up along dimensions of a star schema. Therefore, I created several DIMENSIONs and made sure that all foreign key/primary key relationships between fact and dimension tables are set up correctly. In addition, as many table attributes as possible are assigned the NOT NULL constraint, especially the ones that are used by the CHILD Of and ATTRIBUTE relationships.
I defined materialized views on the fact table and a couple of dimension tables to report on aggregated data. All the MVIEWs are enabled for query rewriting and I have the initialization parameter set correctly (QUERY_REWRITE_INTEGRITY is set to TRUSTED).
From my tests I learned that a query is rewritten correctly only of the corresponding MVIEW contains the fact table and one dimension table. This is true for every dimension I created. However, as soon as the MVIEW joins more than one dimension table to the fact table the rewriting mechanism fails. It appears that the roll-up (aggregation along the hierarchy) is only possible for one of the dimensions. If the original query suggests rolling-up more than one dimension (e.g., "summarize the key figures by year and product category" but the underlying dimension is based on month and product), the MVIEW is no longer rewritten at all.
Do you know this effect from your work experience? Is this a bug or have I made a mistake or forgotten to switch on a special feature?
Here are some technical data of our data warehouse: we are running an Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 on a Windows Server 2003, the size of the database is about 10 GB (excluding indexes), the star schema contains ten dimension tables each one with a simple or parallel hierarchies (e.g. a product dimension). The fact table and the MVIEWS are partitioned by month.
Any help is very welcome.
Regards,
John

Hi,
you may ask with DBMS_MVIEW why your query does not get rewritten:
Maybe you have to create a util table first with
SQL> @?/rdbms/admin/utlxrw.sql
Then you ask:
SQL> begin
DBMS_MVIEW.EXPLAIN_REWRITE('<your query without ; at the end>');
end;
The reason why it is not rewritten:
SQL> select message from rewrite_table order by sequence;
Kind regards
Uwe

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!

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.

Error when trying to enable cube MV query rewrite

Hi
I'm facing a problem when trying enable query rewrite on the cube materilized view, see below
Invalid Metadata Objects:
Invalid Object "ACCOUNTING.APP_CUBE": "XOQ-01957: The cube has REWRITE MVs and also contains either a ragged or skip-level hierarchy. The hierarchy is "ACCOUNTING.MACHINE.MACHINES"."
As far as I can tell the dimension should not have ragged or skip-level hierarchy as I understand it (having just read up on them now). The dimension only has two levels ALL_MACHINES and MACHINE. The mapping points to a table that has just 1 column the machine_key which has 8 just rows. This joins with a fact table that has just these 8 distinct values in it (and no NULLS).
Am I missing something obvious?
Thanks
Simon

Each 11g hierarchy has two properties that can be seen in the XML template for the dimension.
IsSkipLevel
IsRagged
For example
<LevelHierarchy
Name = "MACHINES"
IsSkipLevel = "True"
IsRagged = "True">
If you do not see them, then the default is False.
You should think of these properties as 'constraints' in the RDBMS sense. For example, if you say
IsSkipLevel = "False"
then the system will interpret this as a constraint that says that the hierarchy is not skip level -- i.e. all parents are always exactly one level above their children. This constraint is validated during dimension load (or, more precisely, dimension COMPILE). If you say it is not skip level and the server finds that it is skip level, then you will get an XOQ-01713 error during the load. If, on the other hand, you say
IsSkipLevel = "True"
then the system will interpret this as no constraint, so it will not check during load. Note that this does not say that there are skip levels in the hierarchy, it just says that the server will not check for skip levels. It is similar to an IS NOT NULL constraint on a column -- If the constraint is there then you can be sure that there are no NULLs; if it is not there, then there may or may not be NULLs.
The double negative implied in the XML property name is unfortunate -- a better name would have been something like "EnableNoSkipLevelConstraint = True", but the choice was made and backwards compatibility requirements makes it hard to change now.
Your specific error, XOQ-01957, is saying that the MACHINE hierarchy of the MACHINES dimension is marked as IsSkipLevel = "True" or IsRagged = "True". (It is probably both.) In other words the skip level and ragged constraints are not enabled on the hierarchy. To fix this you should flip the two properties to False in the XML and recreate the dimensions. Unfortunately you cannot change the properties directly in AWM 11.1 since AWM tries to manage the properties automatically for you. But there are times, like, this, when things go wrong.

XPath query rewrite and insertChildXML (10g2): Help?

Hi all,
I have a registered schema for a <log> document. The schema defines an element /log/logData and under that there, /log/logData/data having maxOccurs="unbounded". So the form of documents is
<log>
<logData>
<data>a</data>
<data>b</data>
<data>c</data>
</logData>
</log>
In the schema definition I have enabled "storeArrayAsVArray='true'". The <data> elements are stored in a nested table. Every type is stored object-relationally.
To an instance documen, I add <data> elements so:
UPDATE log SET object_value = insertChildXML(object_value, 'log/logData', 'data', '<data>foo</data>') WHERE existsNode ('/log[@uid="foo"]')
The call succeeds but the problem is that I need to make this call thousands of times. Initiallly the call might take 100 ms, but after a few hundred inserts inserting a single element takes over a second, and the time keeps increasing.
I believe at least part of the problem is that XPath query rewrites are not working for this call.
Following Chapter 6 of Oracle XML DB Developer's Guide, to debug the problem I have switched on
ALTER SESSION SET EVENTS '19021 trace name context forever, level 1';
and then every invocation causes:
ORA-19022: XML XPath functions are disabled
indicating that Oracle could not rewrite the query. Then I set
ALTER SESSION SET EVENTS '19027 TRACE NAME CONTEXT FOREVER, LEVEL 8192'
to obtain a trace file. Here is a portion of that trace:
*** 2005-10-30 16:54:44.984
*** ACTION NAME:() 2005-10-30 16:54:44.968
*** MODULE NAME:(SQL*Plus) 2005-10-30 16:54:44.968
*** SERVICE NAME:(SYS$USERS) 2005-10-30 16:54:44.968
*** SESSION ID:(137.38364) 2005-10-30 16:54:44.968
NO REWRITE
     Reason ==> xseq:not optuop
NO REWRITE
     Reason ==> xseq:not optuop
NO REWRITE
     Reason ==> not SQLX operand
NO REWRITE
     Reason ==> non sqlx expression input
NO REWRITE
     Reason ==> non rewritable sqlx input
NO REWRITE
(the rest of the file repeats these lines)
I have no idea how to interpet that! Can anyone out there offer some insight/assistance?
Thanks if you can,
Hugh

Below is a complete example script. Cannot seem to get rewrite for even this simple case. By that I mean, executing both of the SELECT statements near the end yield the ORA-19022, and that executing the insertChildXML takes progressively longer to execute the more child elements there are.
Any pointers appreciated!
Hugh
set echo on
ALTER SESSION SET EVENTS '19021 trace name context forever, level 1';
ALTER SESSION SET EVENTS '19027 TRACE NAME CONTEXT FOREVER, LEVEL 8192';
exec dbms_xmlschema.deleteSchema('http://hughw.net/foo', dbms_xmlschema.DELETE_CASCADE_FORCE);
begin
dbms_xmlschema.registerSchema('http://hughw.net/foo', XMLType('<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://hughw.net/foo" xmlns="http://hughw.net/foo" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns:xdb="http://xmlns.oracle.com/xdb" xdb:storeVarrayAsTable="true">
<xs:element name="root" xdb:defaultTable="ROOT" >
<xs:complexType xdb:SQLType="ROOT_T">
<xs:sequence>



<xs:element name="child" type="childType" minOccurs="0" maxOccurs="unbounded"
xdb:SQLName="CHILDREN"
xdb:SQLCollType="CHILD_V"
/>
</xs:sequence>
<xs:attribute name="uid" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:complexType name="childType" xdb:SQLType="CHILD_T">
<xs:simpleContent>
<xs:extension base="xs:string"/>
</xs:simpleContent>
</xs:complexType>
</xs:schema>'));
end;
insert into root values( XMLType('<?xml version="1.0" encoding="UTF-8"?>
<root uid="1" xmlns="http://hughw.net/foo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://hughw.net/foo http://hughw.net/foo">
<child>a</child>
<child>b</child>
<child>c</child>
</root>'));
CREATE INDEX ROOT_INDEX ON ROOT (extractValue(object_value,'/root/@uid'));
select insertChildXML(object_value, '/root', 'child', '<child>x</child>>') FROM root;
explain plan for select insertChildXML(object_value, '/root', 'child', '<child>x</child>>') FROM root;
SELECT PLAN_TABLE_OUTPUT FROM table(DBMS_XPLAN.display('plan_table', NULL, 'serial'));
select insertChildXML(object_value, '/root', 'child', '<child>x</child>>') FROM root
WHERE existsNode(object_value, '/root[@uid="1"]') = 1;
explain plan for select insertChildXML(object_value, '/root', 'child', '<child>x</child>>') FROM root
WHERE existsNode(object_value, '/root[@uid="1"]') = 1;
SELECT PLAN_TABLE_OUTPUT FROM table(DBMS_XPLAN.display('plan_table', NULL, 'serial'));

Error while enabling query rewrite on cube

Hi
Trying to enable query rewrite option for OLAP cube throws below error message :
Your metadata changes have been saved, with the following errors
Invalid Metadata Objects:
Invalid Object "FUSION.FLINE_STATUS_CUBE2": "CREATE MATERIALIZED VIEW "FUSION"."CB$FLINE_STATUS_CUBE2"
ORGANIZATION CUBE ON FUSION.DOO_STATUS (
FACT "FLINE_STATUS_CUBE2_STORED"("FLINE_STATUS_CUBE2_MEASURE_DIM" 'SYS_COUNT') IS "SYS_COUNT",
FACT "FLINE_STATUS_CUBE2_STORED"("FLINE_STATUS_CUBE2_MEASURE_DIM" 'TOTAL_QUANTITY') IS "TOTAL_QUANTITY",
FACT "FLINE_STATUS_CUBE2_STORED"("FLINE_STATUS_CUBE2_MEASURE_DIM" 'TOTAL_PRICE') IS "TOTAL_PRICE",
DIMENSION "WAREHOUSE1" IS "WAREHOUSE1" .............................................
ORA-30353: expression not supported for query rewrite
There are no issues with loading/viewing data from cube.
Any pointers on what could be going wrong herel.
Thanks
RaviKishore

In the context of an OLAP cube the offending expression will be part of the cube's mapping. As already pointed out, there are a number of functions that aren't compatible. Here is the oracle documentation for the error.
ORA-30353 expression not supported for query rewrite
Cause: The SELECT clause referenced UID, USER, ROWNUM, SYSDATE, CURRENT_TIMESTAMP, MAXVALUE, a sequence number, a bind variable, correlation variable, a set result, a trigger return variable, a parallel table queue column, collection iterator, a non-deterministic date format token RR, etc.
Action: Remove the offending expression or disable the REWRITE option on the materialized view.
The most common cause in my experience is handling dates with either TO_DATE or TO_CHAR functions. If these functions do not have an explicit date format, then you will hit this error.

Why do we need query rewrite enabled for a function-based index?

Oracle 9i
========
I have searched a few sites but could not find any content on it. The question is why do we need to implement query rewrite enabled when we are trying out a function-based index?
Thanks in advance.

You don't, that's a legacy requirement from the early days of function based indexes in Oracle 8i. Here's a quick example running under 9.2.0.6
drop table t1;
create table t1 as
select
from
     all_objects
where
     rownum <= 30000
create or replace function pl_func(i_vc     varchar2)
return varchar2
deterministic
as
begin
     return soundex(i_vc);
end;
-- set the worst case scenario
alter session set query_rewrite_enabled = false;
alter session set query_rewrite_integrity = enforced;
create index t1_i1 on t1(pl_func(object_name));
execute dbms_stats.gather_table_stats(user, 't1')
set autotrace traceonly explain
select
     object_name
from t1
where pl_func(object_name) = 'T513'
set autotrace offResults (after set feedback off)
SQL> @temp
Execution Plan
Plan hash value: 1429545322
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |    27 |   675 |    10   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| T1    |    27 |   675 |    10   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | T1_I1 |    27 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("TEST_USER"."PL_FUNC"("OBJECT_NAME")='T513')
SQL> spool offRegards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Map Viewer Query Rewriting for Dynamic themes and Materialized Views.

Hi,
I am usng a WMS request to render FOI points in my map.
Internally query rewrite is happening in Mapviewer for this dynamic theme and my data points query is getting converted as
select FROM
( select status, shape from MatView.MyTab where id = '3' )
WHERE MDSYS.SDO_FILTER(shape, MDSYS.SDO_GEOMETRY(2003, 4283, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY(144.948120117188,-37.8162934802451,144.950866699219,-37.8141237016045)), 'querytype=WINDOW') = 'TRUE'
here the rewritten query is not correct and is throwing exceptions in mapviewer log
How can I make this query to be written correctly.
(My orginal query before rewrite is: select status,shape from MatView.MyTab where id='3' )
I am using a materialised view : MatView is a materialized view.
When I used normal tables, the query is re written correctly.But for this materialized view this is happening.
How can I correct the error?
Is this has something to do with some Spatial Indexing in Materialised view or Query Rewriting for materialized view?
Edited by: 841309 on Mar 10, 2011 11:04 PM

Oops!
The Materialized view was not accessible from the schema I tried :)
And so when I gave permissions,it formed the correct query.
So if permission is not there,map viewer will rewrite the query in a wrong way! New information.

Spatial vs. materialized views/query rewrite

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

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

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 ISSUE (ANSI JOINS do not work, traditional join works ) 11gR2

For some types of queries constructed with ANSI JOINS, materialized views are not being used.
This is currently increasing time on various reports since we cannot control the way the queries are generated(Tableau Application generates and runs queries against the STAR Schema).
Have tried to debug this behavior using DBMS_MVIEW.EXPLAIN_REWRITE and mv_capabilities function without any success.
The database is configured for query rewrite: REWRITE INTEGRITY, QUERY REWRITE ENABLED and other settings are in place.
Have successfully reproduced the issue using SH Sample schema:
Q1 and Q2 are logically identical the only difference between them being the type of join used:
Q1: ANSI JOIN
Q2: Traditional join
Below is an example that can be validated on SH sample schema.
Any help on this will be highly appreciated.
-- Q1: the query is generated by an app and needs to be rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
-- Q2: the query with traditional join is rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Tested both queries with the following materialized views:
CREATE MATERIALIZED VIEW MVIEW_TEST_1
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
CREATE MATERIALIZED VIEW MVIEW_TEST_2
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Explain Plans showing that Q1 does not use materialized view and Q2 uses materialized view
SET AUTOTRACE TRACEONLY
--Q1 does not use MVIEW_TEST_1
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4    5
511 rows selected.
Execution Plan
Plan hash value: 1218164197
| Id | Operation           | Name       | Rows | Bytes |TempSpc| Cost (%CPU)| Time       |
|   0 | SELECT STATEMENT      |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   1 | HASH GROUP BY           |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   2 |   VIEW                | VM_NWVW_1 | 55500 | 1571K|       |   916   (1)| 00:00:11 |
|   3 |    HASH GROUP BY      |        | 55500 | 1842K| 2408K|   916   (1)| 00:00:11 |
|* 4 |     HASH JOIN           |        | 55500 | 1842K|       |   409   (1)| 00:00:05 |
|   5 |      TABLE ACCESS FULL| COUNTRIES |    23 |   414 |       |     3   (0)| 00:00:01 |
|   6 |      TABLE ACCESS FULL| CUSTOMERS | 55500 |   867K|       |   405   (1)| 00:00:05 |
--Q2 uses MVIEW_TEST_2
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4
511 rows selected.
Execution Plan
Plan hash value: 2126022771
| Id | Operation               | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT          |              |     511 | 21973 |       3   (0)| 00:00:01 |
|   1 | MAT_VIEW REWRITE ACCESS FULL| MVIEW_TEST_2 |     511 | 21973 |       3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------Database version 11gR1 (Tested also on 11gR2)
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit 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

Thanks for the formatting tips.
Just found an Oracle Bug which explains the above behavior.
Unfortunately the bug will be fixed only in 12.1 Release so as a workaround will try to use traditional joins.
For those who have metalink access see [Bug 10145667 : ERRORS TRYING TO REWRITE QUERY WITH EXACT TEXT MATCH TO MVIEW]

Usage of Query Rewrite in Materialized Views

Hi,
I have a star schema with fact table and and dimensions tables.
One of the dimension tables is time_dimension and I have created
a materialized view(time_sales_mv) on it and the fact table. I
have also created a dimension(time_dim) on the
table 'time_dimension' with hierarchies and attributes.
Following are the syntaxes -
--Dimension table
CREATE TABLE TIME_DIMENSION (
TIME_KEY NUMBER(9) NOT NULL,
DAY_OF_MONTH NUMBER(9),
WEEKDAY NUMBER(9),
WEEKEND NUMBER(9),
JULIAN_DAY NUMBER(9),
JULIAN_WEEK NUMBER(9),
JULIAN_YEAR NUMBER(9),
MONTH_NUMBER NUMBER(9),
MONTH_NAME VARCHAR2(15),
WEEK_OF_THE_YEAR NUMBER(9),
WEEKDAY_NAME VARCHAR2(10),
WEEK_DAY_NUMBER NUMBER(9),
THE_YEAR NUMBER(9),
DAY_OF_THE_YEAR NUMBER(9),
THE_DATE DATE,
THE_QUARTER NUMBER(9),
PRIMARY KEY ( TIME_KEY )) ;
--Fact table
CREATE TABLE SALES_FACT (
TIME_KEY NUMBER(9) NOT NULL,
PRODUCT_KEY NUMBER(9) NOT NULL,
PROMOTION_KEY NUMBER(9) NOT NULL,
CUSTOMER_KEY NUMBER(9) NOT NULL,
DOLLAR_SALES FLOAT,
UNIT_SALES NUMBER(9),
DOLLAR_COST FLOAT)
-- Dimension created
CREATE DIMENSION Time_dim
LEVEL THE_DATE IS TIME_DIMENSION.THE_DATE
LEVEL WEEK_OF_THE_YEAR IS time_dimension.WEEK_OF_THE_YEAR
LEVEL MONTH_NUMBER IS time_dimension.MONTH_NUMBER
LEVEL THE_QUARTER IS time_dimension.THE_QUARTER
LEVEL THE_YEAR IS time_dimension.THE_YEAR
HIERARCHY calendar_rollup (
     THE_DATE CHILD OF
     MONTH_NUMBER CHILD OF
     THE_QUARTER CHILD OF
     THE_YEAR )
HIERARCHY weekly_rollup (
     THE_DATE CHILD OF
WEEK_OF_THE_YEAR )
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_MONTH
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.WEEKDAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.JULIAN_DAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_THE_YEAR
ATTRIBUTE MONTH_NUMBER DETERMINES
time_dimension_sagar.month_name
ATTRIBUTE THE_YEAR DETERMINES
time_dimension_sagar.JULIAN_YEAR;
-- Materialized View
CREATE MATERIALIZED VIEW time_sales_mv
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT t.month_number, SUM
(dollar_sales) AS sum_dollar_sales
FROM sales_fact s,time_dimension t
WHERE t.time_key =
s.time_key GROUP BY
t.month_number
Now if I use the same query as in the MV and see the explain
plan it shows the MV is being used instead of the underlying
tables which is as expected. But if I change 'month_number'
to 'month_name' in the above query, the explain plan does not
use the MV which is not as expected. Since 'month_name' is an
attribute of 'month_number'(defined in the dimension
definition), we can use it and query rewrite feature will join
the MV to the time_dimension table. But in the actual plan, it
uses the fact table 'sales_fact' instead of the MV. Even when I
use the rewrite hint on the query it does not use the MV. I want
know why this is happening??
Query-
SELECT t.month_number, SUM(dollar_sales) AS
sum_dollar_sales FROM
sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_number
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=82 Bytes=2132)
TABLE ACCESS (FULL) OF TIME_SALES_MV (Cost=1 Card=82
Bytes=2132)
Query(using month_name instead of month_number)-
SELECT t.month_name, SUM(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)
Query (using rewrite hint in the above query) -
SELECT /*+ rewrite(time_sales_mv)*/
t.month_name, SUM
(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)

Hi,
I have a star schema with fact table and and dimensions tables.
One of the dimension tables is time_dimension and I have created
a materialized view(time_sales_mv) on it and the fact table. I
have also created a dimension(time_dim) on the
table 'time_dimension' with hierarchies and attributes.
Following are the syntaxes -
--Dimension table
CREATE TABLE TIME_DIMENSION (
TIME_KEY NUMBER(9) NOT NULL,
DAY_OF_MONTH NUMBER(9),
WEEKDAY NUMBER(9),
WEEKEND NUMBER(9),
JULIAN_DAY NUMBER(9),
JULIAN_WEEK NUMBER(9),
JULIAN_YEAR NUMBER(9),
MONTH_NUMBER NUMBER(9),
MONTH_NAME VARCHAR2(15),
WEEK_OF_THE_YEAR NUMBER(9),
WEEKDAY_NAME VARCHAR2(10),
WEEK_DAY_NUMBER NUMBER(9),
THE_YEAR NUMBER(9),
DAY_OF_THE_YEAR NUMBER(9),
THE_DATE DATE,
THE_QUARTER NUMBER(9),
PRIMARY KEY ( TIME_KEY )) ;
--Fact table
CREATE TABLE SALES_FACT (
TIME_KEY NUMBER(9) NOT NULL,
PRODUCT_KEY NUMBER(9) NOT NULL,
PROMOTION_KEY NUMBER(9) NOT NULL,
CUSTOMER_KEY NUMBER(9) NOT NULL,
DOLLAR_SALES FLOAT,
UNIT_SALES NUMBER(9),
DOLLAR_COST FLOAT)
-- Dimension created
CREATE DIMENSION Time_dim
LEVEL THE_DATE IS TIME_DIMENSION.THE_DATE
LEVEL WEEK_OF_THE_YEAR IS time_dimension.WEEK_OF_THE_YEAR
LEVEL MONTH_NUMBER IS time_dimension.MONTH_NUMBER
LEVEL THE_QUARTER IS time_dimension.THE_QUARTER
LEVEL THE_YEAR IS time_dimension.THE_YEAR
HIERARCHY calendar_rollup (
     THE_DATE CHILD OF
     MONTH_NUMBER CHILD OF
     THE_QUARTER CHILD OF
     THE_YEAR )
HIERARCHY weekly_rollup (
     THE_DATE CHILD OF
WEEK_OF_THE_YEAR )
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_MONTH
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.WEEKDAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.JULIAN_DAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_THE_YEAR
ATTRIBUTE MONTH_NUMBER DETERMINES
time_dimension_sagar.month_name
ATTRIBUTE THE_YEAR DETERMINES
time_dimension_sagar.JULIAN_YEAR;
-- Materialized View
CREATE MATERIALIZED VIEW time_sales_mv
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT t.month_number, SUM
(dollar_sales) AS sum_dollar_sales
FROM sales_fact s,time_dimension t
WHERE t.time_key =
s.time_key GROUP BY
t.month_number
Now if I use the same query as in the MV and see the explain
plan it shows the MV is being used instead of the underlying
tables which is as expected. But if I change 'month_number'
to 'month_name' in the above query, the explain plan does not
use the MV which is not as expected. Since 'month_name' is an
attribute of 'month_number'(defined in the dimension
definition), we can use it and query rewrite feature will join
the MV to the time_dimension table. But in the actual plan, it
uses the fact table 'sales_fact' instead of the MV. Even when I
use the rewrite hint on the query it does not use the MV. I want
know why this is happening??
Query-
SELECT t.month_number, SUM(dollar_sales) AS
sum_dollar_sales FROM
sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_number
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=82 Bytes=2132)
TABLE ACCESS (FULL) OF TIME_SALES_MV (Cost=1 Card=82
Bytes=2132)
Query(using month_name instead of month_number)-
SELECT t.month_name, SUM(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)
Query (using rewrite hint in the above query) -
SELECT /*+ rewrite(time_sales_mv)*/
t.month_name, SUM
(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)

Risky enable star transformations and trusted Query Rewrites?

Similar Messages

Maybe you are looking for