Query rewrite error QSM-01219

Hi,
When having a query run with the REWRITE_OR_ERROR hint the query fails with:
QSM-01151: query was rewritten
QSM-01209: query rewritten with materialized view, CM_FT_FX1_MV, using text match algorithm
QSM-01219: no suitable materialized view found to rewrite this query
What do these error then mean? Does this mean that the MV wasn't found or that the MV had issues? This worked before and the only change was that we upgraded the database from version 10.2.0.1 to 10.2.0.3.
If the MV name is specified in the hint REWRITE_OR_ERROR(CM_FT_FX1_MV) then the query works fine. Is something like this supported in Oracle: REWRITE_OR_ERROR(MV1,MV2,......) ?
Did anyone encounter similar issue?
Thanks,
Zrinka

Since you have not posted more details, see if your case is similar to bug 7201596 on metalink.

Similar Messages

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.

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.

Query rewrite clause getting error

Hi all;
I did not complete Query rewrite clause (M.view) , when trying to enable i am getting error
and i have asked this question " https://forums.oracle.com/forums/thread.jspa?threadID=2543789 "
Question wrongly posted under data communication model. - So this is not a duplicate thread.
please reply me what was missing here ?
SQL> alter system set query_rewrite_enabled='TRUE' scope=SPFILE;
SQL> grant query rewrite to ****;
Grant succeeded.
conn xxx/xxxx@xxxxxx
1. SQL> ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS/
Session altered.
2. SQL> alter session set query_rewrite_enabled=true;
Session altered.
3. SQL> execute dbms_stats.gather_table_stats('rose', 'mv1');
PL/SQL procedure successfully completed.
4. SQL> exec dbms_mview.explain_rewrite('select * from sales','MV1');
BEGIN dbms_mview.explain_rewrite('select from sales','MV1'); END;*
*ERROR at line 1:
ORA-30380: REWRITE_TABLE does not exist
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3085
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3206
ORA-06512: at line 1Thanks in advance ..

Expain plan before utlxrw.sql execution SQL> select count(*), sum(quan_sold), sum(amt_sold) from sales;
COUNT(*) SUM(QUAN_SOLD) SUM(AMT_SOLD)
6000000 12000000 720480000
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 2958490228 | Id | Operation | Name | Rows | Bytes | Cost (CPU)| Time
0 | SELECT STATEMENT | | 1 | *40* | 3 (0) | 00:00 :01
1 | MAT_VIEW REWRITE ACCESS FULL | MV1 | 1 | *40* | 3 (0) | 00:00 :01
SQL> @$ORACLE_HOME/rdbms/admin/utlxrw.sql;
Table created.
SQL> exec dbms_mview.explain_rewrite('select * from sales','MV1');
PL/SQL procedure successfully completed.
SQL> select count(*), sum(quan_sold), sum(amt_sold) from sales;COUNT(*) SUM(QUAN_SOLD) SUM(AMT_SOLD)
6000000 12000000 720480000
Execution Plan
Plan hash value: 2958490228
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | *11* | 3 (0) | 00:00:01 |
| 1 | MAT_VIEW REWRITE ACCESS FULL | MV1 | 1 | *11* | 3 (0) | 00:00:01 |
but i do NOT find any difference after enabling Query rewrite clause .. please clarify this ..
bytes only changed.

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.

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 does not happen

Hello all,
let me start by wishing you all the best for the forthcoming year !
And now, the problem
I am trying to create a materialized view so that a few slow reports that run on OBIEE (10g) make use of query rewrite functionality. Unfortunately any attempt that had made was unsuccessful. I though of posting the query that is created by OBIEE and the different materialized views that i have created, so that anyone that had a similar problem before might help me through it. So here it goes ( there is a separate discussion for the other query here ) :
First comes the query that was created by OBIEE when no materialized view existed.
SELECT DISTINCT D1.c5 AS c1,                  D1.c10 AS c2,                       D1.c9 AS c3,                  D1.c6 AS c4,                  D1.c8 AS c5,                  D1.c8 / NULLIF (D1.c6, 0) AS c6,
                  D1.c7 AS c7,                  D1.c7 / NULLIF (D1.c6, 0) AS c8,        D1.c4 AS c9,                  D1.c3 / NULLIF (D1.c1, 0) AS c10,                     D1.c2 / NULLIF (D1.c1, 0) AS c11
    FROM (SELECT SUM (D1.c6) OVER (PARTITION BY D1.c5) AS c1,
                 SUM (D1.c7) OVER (PARTITION BY D1.c5) AS c2,
                 SUM (D1.c8) OVER (PARTITION BY D1.c5) AS c3,
                 SUM (D1.c4) OVER (PARTITION BY D1.c5) AS c4,
                 D1.c5 AS c5,                 D1.c6 AS c6,                 D1.c7 AS c7,                 D1.c8 AS c8,                 D1.c9 AS c9,                 D1.c10 AS c10
            FROM ( SELECT COUNT (CASE D1.c12 WHEN 1 THEN D1.c11 ELSE NULL END)    AS c4,                    D1.c5 AS c5,                           SUM (D1.c13) AS c6,
                         SUM (D1.c14) AS c7,                           SUM (D1.c15) AS c8,               COUNT (DISTINCT D1.c11) AS c9,                           D1.c10 AS c10
                      FROM (SELECT                   /*+ PARALLEL(T16913,8) */
                                  T19403.YEAR_MONTH   AS c5,
                                   T7252.PERCENTAGE AS c10,
                                   T366.BARCODE AS c11,
                                   ROW_NUMBER ()   OVER ( PARTITION BY T19403.YEAR_MONTH,   T366.BARCODE ORDER BY T19403.YEAR_MONTH DESC,   T366.BARCODE DESC) AS c12,
                                   T16913.PHA_QUANTITY AS c13,
                                   T16913.EXEC_COST AS c14,
                                   T16913.EXEC_VALUE AS c15
                              FROM EXECALENDAR_DIM T19403,
                                       DRUG_DIM T366,
                                       PERCENTAGE_DIM T7252,
                                       PRESCDRUG_FACT T16913
                             WHERE (T366.DWHKEY = T16913.DRU_DWHKEY
                                    AND T7252.DWHKEY = T16913.PER_DWHKEY
                                    AND T16913.EXECUTION_DATE =
                                           T19403.CALENDAR_DATE
                                    AND T19403.YEAR_MONTH = '201212')) D1
                  GROUP BY D1.c5, D1.c10) D1) D1
ORDER BY c1, c2
so my first try was that
CREATE MATERIALIZED VIEW PRESCDRUG_FACT_MV BUILD IMMEDIATE REFRESH ON DEMAND ENABLE QUERY REWRITE AS
SELECT /*+ PARALLEL(PRESCDRUG_FACT,8) */
                 EXECALENDAR_DIM.YEAR_MONTH       as YEAR_MONTH
                ,PRESCDRUG_FACT.PER_DWHKEY
                 ,count(*)                            as COUNT_ALL
                 ,COUNT (EXECALENDAR_DIM.YEAR_MONTH) AS c_YEAR_MONTH
                 ,COUNT (DISTINCT PRESCDRUG_FACT.DRUG_CD) DRUG_CODE
                 ,COUNT (DISTINCT PRESCDRUG_FACT.DRUG_BARCODE) BARCODE
                  -- quantities
                 ,SUM (PRESCDRUG_FACT.PHA_QUANTITY) AS PHA_QUANTITY
                 ,SUM (PRESCDRUG_FACT.DOC_QUANTITY) AS DOC_QUANTITY
                 ,SUM (PRESCDRUG_FACT.APR_QUANTITY) AS APR_QUANTITY
                 -- values
                 ,SUM (PRESCDRUG_FACT.EXEC_VALUE)       AS EXEC_VALUE
                 ,SUM (PRESCDRUG_FACT.PUB_VALUE)        AS PUB_VALUE
                 ,SUM (PRESCDRUG_FACT.APR_VALUE) AS APR_VALUE
                 -- costs
                 ,SUM (PRESCDRUG_FACT.EXEC_COST) AS EXEC_COST
                 ,SUM (PRESCDRUG_FACT.PUB_COST) AS PUB_COST
                 ,SUM (PRESCDRUG_FACT.APR_COST) AS APR_COST
   FROM EXECALENDAR_DIM,    PRESCDRUG_FACT
WHERE EXECALENDAR_DIM.CALENDAR_DATE   = PRESCDRUG_FACT.EXECUTION_DATE
       AND EXECALENDAR_DIM.YEAR_MONTH in ( '201212')
   GROUP BY   EXECALENDAR_DIM.YEAR_MONTH ,PRESCDRUG_FACT.PER_DWHKEY
and i got the following messages from DBMS_MVIEW.EXPLAIN_REWRITE
QSM-01150: query did not rewrite
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, EXECALENDAR_DIM, on column, CALENDAR_DATE
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, EXECUTION_DATE
QSM-01082: Joining materialized view, PRESCDRUG_FACT_MV, with table, PRESCDRUG_FACT, not possible
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, DRU_DWHKEY
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, EXEC_VALUE
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, EXEC_COST
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, PHA_QUANTITY
QSM-01155: multi-mv query rewrite not possible when there is a Window Function
QSM-01219: no suitable materialized view found to rewrite this query
My second attempt is the following ( in comparison to the first i have added the DRUG_BARCODE column in the grouping clause
CREATE MATERIALIZED VIEW PRESCDRUG_FACT_MV BUILD IMMEDIATE REFRESH ON DEMAND ENABLE QUERY REWRITE AS
SELECT /*+ PARALLEL(PRESCDRUG_FACT,8) */
                 EXECALENDAR_DIM.YEAR_MONTH       as YEAR_MONTH
                 ,PRESCDRUG_FACT.PER_DWHKEY
              ,PRESCDRUG_FACT.DRUG_BARCODE
                 ,count(*)                                            as COUNT_ALL
                 ,COUNT (EXECALENDAR_DIM.YEAR_MONTH) AS c_YEAR_MONTH
                 ,COUNT (DISTINCT PRESCDRUG_FACT.DRUG_CD) DRUG_CODE
                 ,COUNT (DISTINCT PRESCDRUG_FACT.DRUG_BARCODE) BARCODE
                 ,COUNT (DISTINCT PRESCDRUG_FACT.PRESC_NUMBER) PRESC_NUMBER
                 ,COUNT (DISTINCT PRESCDRUG_FACT.PRESC_ID) PRESC_ID
                  -- quantities
                 ,SUM (PRESCDRUG_FACT.PHA_QUANTITY) AS PHA_QUANTITY
                 ,SUM (PRESCDRUG_FACT.DOC_QUANTITY)        AS DOC_QUANTITY
                 ,SUM (PRESCDRUG_FACT.APR_QUANTITY) AS APR_QUANTITY
                 -- values
                 ,SUM (PRESCDRUG_FACT.EXEC_VALUE)       AS EXEC_VALUE
                 ,SUM (PRESCDRUG_FACT.PUB_VALUE)        AS PUB_VALUE
                 ,SUM (PRESCDRUG_FACT.APR_VALUE) AS APR_VALUE
                 -- costs
                 ,SUM (PRESCDRUG_FACT.EXEC_COST) AS EXEC_COST
                 ,SUM (PRESCDRUG_FACT.PUB_COST) AS PUB_COST
                 ,SUM (PRESCDRUG_FACT.APR_COST) AS APR_COST
    FROM EXECALENDAR_DIM,    PRESCDRUG_FACT
WHERE EXECALENDAR_DIM.CALENDAR_DATE   = PRESCDRUG_FACT.EXECUTION_DATE
       AND EXECALENDAR_DIM.YEAR_MONTH in ( '201212')
   GROUP BY   EXECALENDAR_DIM.YEAR_MONTH ,PRESCDRUG_FACT.PER_DWHKEY,DRUG_BARCODE
and the results of DBMS_MVIEW.EXPLAIN_REWRITE
QSM-01150: query did not rewrite
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, EXECALENDAR_DIM, on column, CALENDAR_DATE
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, EXECUTION_DATE
QSM-01082: Joining materialized view, PRESCDRUG_FACT_MV, with table, PRESCDRUG_FACT, not possible
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, DRU_DWHKEY
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, EXEC_VALUE
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, EXEC_COST
QSM-01102: materialized view, PRESCDRUG_FACT_MV, requires join back to table, PRESCDRUG_FACT, on column, PHA_QUANTITY
QSM-01155: multi-mv query rewrite not possible when there is a Window Function
QSM-01219: no suitable materialized view found to rewrite this query
third try (rolling up the group results)
CREATE MATERIALIZED VIEW PRESCDRUG_FACT_MV BUILD IMMEDIATE REFRESH ON DEMAND ENABLE QUERY REWRITE AS
SELECT /*+ PARALLEL(PRESCDRUG_FACT,8) */
                 EXECALENDAR_DIM.YEAR_MONTH       as YEAR_MONTH
                 ,PRESCDRUG_FACT.PER_DWHKEY
              ,PRESCDRUG_FACT.DRUG_BARCODE
                 ,count(*)                                            as COUNT_ALL
                 ,COUNT (EXECALENDAR_DIM.YEAR_MONTH) AS c_YEAR_MONTH
                 ,COUNT (DISTINCT PRESCDRUG_FACT.DRUG_CD) DRUG_CODE
                 ,COUNT (DISTINCT PRESCDRUG_FACT.DRUG_BARCODE) BARCODE
                 ,COUNT (DISTINCT PRESCDRUG_FACT.PRESC_NUMBER) PRESC_NUMBER
                 ,COUNT (DISTINCT PRESCDRUG_FACT.PRESC_ID) PRESC_ID
                  -- quantities
                 ,SUM (PRESCDRUG_FACT.PHA_QUANTITY) AS PHA_QUANTITY
                 ,SUM (PRESCDRUG_FACT.DOC_QUANTITY)        AS DOC_QUANTITY
                 ,SUM (PRESCDRUG_FACT.APR_QUANTITY) AS APR_QUANTITY
                 -- values
                 ,SUM (PRESCDRUG_FACT.EXEC_VALUE)       AS EXEC_VALUE
                 ,SUM (PRESCDRUG_FACT.PUB_VALUE)        AS PUB_VALUE
                 ,SUM (PRESCDRUG_FACT.APR_VALUE) AS APR_VALUE
                 -- costs
                 ,SUM (PRESCDRUG_FACT.EXEC_COST) AS EXEC_COST
                 ,SUM (PRESCDRUG_FACT.PUB_COST) AS PUB_COST
                 ,SUM (PRESCDRUG_FACT.APR_COST) AS APR_COST
    FROM EXECALENDAR_DIM,    PRESCDRUG_FACT
WHERE EXECALENDAR_DIM.CALENDAR_DATE   = PRESCDRUG_FACT.EXECUTION_DATE
       AND EXECALENDAR_DIM.YEAR_MONTH in ( '201212')
   GROUP BY   EXECALENDAR_DIM.YEAR_MONTH     , rollup (PRESCDRUG_FACT.PER_DWHKEY,    DRUG_BARCODE)
results from DBMS_MVIEW.EXPLAIN_REWRITE
QSM-01150: query did not rewrite
QSM-01295: no suitable grouping_id found in materialized view with grouping sets
QSM-01155: multi-mv query rewrite not possible when there is a Window Function
QSM-01219: no suitable materialized view found to rewrite this query
So, no luck so far. My guess is that it has to do something with the partition clause that appears in the original query.
anyway, if anything cross your minds..
thanks in advance
Theodore

Hello again,
It appeared that, the problem is present only when I try the query in pl/sql developer.
For some reason, even though I set QUERY_REWRITE_INTEGRITY to STALE_TOLERATED, it behaved as this parameter was set to ENFORCED.
So the case was that:
for session - STALE_TOLERATED
for system - ENFORCED
In v$parameter2 against "QUERY_REWRITE_INTEGRITY" was shown "stale_tolerated", but the query was not rewritten.
When I do the same (altering the session and perform the select query) in SQLPlus, everything works as expected - the query is rewritten.
And I conclude the problem is in PL/SQL Developer (my version is 8.0.1.1498) or something related to this.
Edited by: Verdi on 2010-2-12 14:00

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

Materialized views on prebuilt tables - query rewrite

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

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

Oracle Query Rewrite Alias Problem

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

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

No query rewrite

i have a problem with query rewrite in 10gR1.
create table time_hierarchy (
day date primary key,
mmyyyy char(6) not null,
qyyyy char(5) not null,
yyyy char(4) not null
) organization index;
create table tx (
shopid number not null,
txdate date references time_hierarchy initially deferred
not null,
amount number not null
create dimension tx_dimension
level day is time_hierarchy.day
level mmyyyy is time_hierarchy.mmyyyy
level qyyyy is time_hierarchy.qyyyy
level yyyy is time_hierarchy.yyyy
hierarchy time_rollup (
day child of
mmyyyy child of
qyyyy child of
yyyy
create materialized view tx_mv
build immediate
refresh on demand
enable query rewrite
as
select a.shopid shopid,
count(*) txnum,
sum(a.amount) amountsum,
b.mmyyyy mmyyyy
from tx a join time_hierarchy b on a.txdate = b.day
group by a.shopid, b.mmyyyy;
i populated the tables and did a complete analyze.
this query was rewritten:
select /*+ REWRITE */ a.shopid shopid,
b.mmyyyy mmyyyy,
count(*) txnum,
sum(a.amount) amountsum
from tx a join time_hierarchy b on a.txdate = b.day
group by a.shopid, b.mmyyyy
order by a.shopid, b.mmyyyy;
but this not:
select /*+ REWRITE */ a.shopid shopid,
b.qyyyy qyyyy,
count(*) txnum,
sum(a.amount) amountsum
from tx a join time_hierarchy b on a.txdate = b.day
group by a.shopid, b.qyyyy
order by a.shopid, b.qyyyy;
an explain_mview gave me this;
MESSAGE
QSM-01082: Joining materialized view, TX_MV, with table, TIME_HIERARCHY, not pos
sible
QSM-01102: materialized view, TX_MV, requires join back to table, TX, on column,
AMOUNT
QSM-01102: materialized view, TX_MV, requires join back to table, TX, on column,
TXDATE
QSM-01102: materialized view, TX_MV, requires join back to table, TIME_HIERARCHY
, on column, YYYY
MESSAGE
QSM-01102: materialized view, TX_MV, requires join back to table, TIME_HIERARCHY
, on column, QYYYY
QSM-01102: materialized view, TX_MV, requires join back to table, TIME_HIERARCHY
, on column, DAY
QSM-01086: dimension(s) not present or not used in ENFORCED integrity mode
QSM-01063: query has a dictionary table or view
if i set integrity to trusted, the latter query will be rewritten too.
can anyone explain me why? i'm clueless.
Best,
-ap

yes, see definition of tx, relation tx.txdate->time_hierarchy.day
what puzzles me is the fact, that mmyyyy works but not qyyyy.
both are levels of day.
-j

About query rewriting

Hi,
I just started using materialized view and found in trouble.
In my case the query rewriting works only if the tables joined in the query are exactly the same
of those joined in the MV.
Is this normal?
Using EXPLAIN_MVIEW I found that when rewriting doesn't happen I got:
QSM-01284: materialized view <string> has an anchor table <string> not found in query
IE:
MV is select <some fields> from t1, t2, t3 where t1.id = t2.fk and t1.id = t3.fk group by <some fields>
query1 is select <few fields> from t1, t2, t3 where t1.id = t2.fk and t1.id = t3.fk group by <few fields>
query2 is select <few fields> from t1, t2 where t1.id = t2.fk group by <few fields>
The rewrite works query1 but not for query2.
Could you explain me why?
Thanks

The first condition to use any query rewrite is to be sure that MV contains data that can be (at least partially) used for your query X you'd like to rewrite. For your 2nd query MV doesn't contain any usable data because joining another table generally further restricts result set and one cannot use these data to get result from less joined result set. It is simply not possible. Of course group by clause goves another complication in your scenario, but the first condition anyway remains.
Gints Plivna
http://www.gplivna.eu

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.

Query rewrite complains about ragged hierarchy when it does not exist

Hi -
I have a customer dimension with only one level. The lowest level of detai.
When I enable the query rewrite I get an error (see below) about ragged or skipped level hierarchy in my customer dimension. I am trying to figure out what the issue is so I created a one level customer hierarchy (lowest level) and I still get the error.
I do not understand how I can have a skipped/ragged hierarchy when my dimension is at the lowest level.
I am using the lastest versions of AWM and 11G.
Thanks in advance for any help you can provide,
Frank
Invalid Metadata Objects:
Invalid Object "MYTEST.CUST_SALES": "XOQ-01957: The cube has REWRITE MVs and also contains either a ragged or skip-level hierarchy. The hierarchy is "MYTEST.CUST_DIM.STANDARD"."
Edited by: bmwrider on Oct 16, 2009 9:01 AM

Hi there,
See this:- Error when trying to enable cube MV 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

Query rewrite error QSM-01219

Similar Messages

Maybe you are looking for