Query rewrite by CBO
Hello,
Some days back, I came across a blog entry in which author concluded that when a = b and b = c, oracle does not conclude as a = c. He also provided a test case to prove his point. The URL is [http://sandeepredkar.blogspot.com/2009/09/query-performance-join-conditions.html]
Now, I thought that that can not be true. So I executed his test case (on 10.2.04) and the outcome indeed proved his point. Initially, I thought it might be due to absense of PK-FK relationship. But even after adding the PK-FK relationship, there was no change in the outcome. Although, when I modified the subquery with list of values, both the queries performed equally. I tried asking the author on his blog but it seems he has not yet seen my comment.
I am pasting his test case below. Can somebody please help me understand why CBO does not/can not use optimal plan here?
SQL> create table cu_all (custid number, addr varchar2(200), ph number, cano number, acctype varchar2(10));
Table created.
SQL> create table ca_receipt (custid number, caamt number, cadt date, totbal number);
Table created.
SQL>
SQL> insert into cu_all
2 select lvl,
3 dbms_random.string('A',30),
4 round(dbms_random.value(1,100000)),
5 round(dbms_random.value(1,10000)),
6 dbms_random.string('A',10)
7 from (select level "LVL" from dual connect by level <=200000);
200000 rows created.
SQL> insert into ca_receipt
2 select round(dbms_random.value(1,10000)),
3 round(dbms_random.value(1,100000)),
4 sysdate - round(dbms_random.value(1,100000)),
5 round(dbms_random.value(1,100000))
6 from (select level "LVL" from dual connect by level <=500000);
500000 rows created.
SQL> create unique index pk_cu_all_ind on cu_all(custid);
Index created.
SQL> create index ind2_cu_all on cu_all(CANO);
Index created.
SQL> create index ind_ca_receipt_custid on ca_receipt(custid);
Index created.
SQL> exec dbms_stats.gather_table_stats(user,'CU_ALL', cascade=>true);
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_table_stats(user,'CA_RECEIPT', cascade=>true);
PL/SQL procedure successfully completed.
Now let us execute the query with trace on. This is the similar query which was provided to me.
SQL> set autot trace
SQL> SELECT ca.*, cu.*
2 FROM ca_receipt CA,
3 cu_all CU
4 WHERE CA.CUSTID = CU.CUSTID
5 AND CA.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
6 CONNECT BY PRIOR CUSTID = CANO)
7 ORDER BY ACCTYPE DESC;
289 rows selected.
Execution Plan
Plan hash value: 3186098611
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1000 | 81000 | 504 (2)| 00:00:07 |
| 1 | SORT ORDER BY | | 1000 | 81000 | 504 (2)| 00:00:07 |
|* 2 | HASH JOIN | | 1000 | 81000 | 503 (2)| 00:00:07 |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1000 | 26000 | 112 (1)| 00:00:02 |
| 5 | VIEW | VW_NSO_1 | 20 | 100 | 21 (0)| 00:00:01 |
| 6 | HASH UNIQUE | | 20 | 180 | | |
|* 7 | CONNECT BY WITH FILTERING | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 9 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | | | | |
| 11 | CONNECT BY PUMP | | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 21 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
| 16 | TABLE ACCESS FULL | CU_ALL | 200K| 10M| 389 (1)| 00:00:05 |
Predicate Information (identified by operation id):
2 - access("CA"."CUSTID"="CU"."CUSTID")
7 - access("CANO"=PRIOR "CUSTID")
9 - access("CUSTID"=2353)
13 - access("CANO"=PRIOR "CUSTID")
14 - access("CA"."CUSTID"="CUSTID")
Statistics
1 recursive calls
0 db block gets
2249 consistent gets
25 physical reads
0 redo size
11748 bytes sent via SQL*Net to client
729 bytes received via SQL*Net from client
21 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
289 rows processed
If you look at the query, it seems to be normal one.
But the problem is here-
Query is having two tables CA and CU. From the inner CU table query, it fetches records and joins with CA table an CA table Joins with CU table using the same column.
Here the inner query joins with CA table and cardinality of the query gets changed. So it is opting FTS when joining to CU table again.
This is causing the performance bottleneck. So to resolve the issue, I have change the joining condition.
Now if we check, following is the proper execution plan. Also the consistents gets have been reduced to 797 against 2249 in original query.
SQL> SELECT ca.*, cu.*
2 FROM ca_receipt CA,
3 cu_all CU
4 WHERE CA.CUSTID = CU.CUSTID
5 AND CU.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
6 CONNECT BY PRIOR CUSTID = CANO)
7 ORDER BY ACCTYPE DESC;
289 rows selected.
Execution Plan
Plan hash value: 3713271440
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1000 | 81000 | 133 (2)| 00:00:02 |
| 1 | SORT ORDER BY | | 1000 | 81000 | 133 (2)| 00:00:02 |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1000 | 81000 | 132 (1)| 00:00:02 |
| 4 | NESTED LOOPS | | 20 | 1200 | 42 (3)| 00:00:01 |
| 5 | VIEW | VW_NSO_1 | 20 | 100 | 21 (0)| 00:00:01 |
| 6 | HASH UNIQUE | | 20 | 180 | | |
|* 7 | CONNECT BY WITH FILTERING | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 9 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | | | | |
| 11 | CONNECT BY PUMP | | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 21 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 55 | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 0 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
Predicate Information (identified by operation id):
7 - access("CANO"=PRIOR "CUSTID")
9 - access("CUSTID"=2353)
13 - access("CANO"=PRIOR "CUSTID")
15 - access("CU"."CUSTID"="CUSTID")
16 - access("CA"."CUSTID"="CU"."CUSTID")
Statistics
1 recursive calls
0 db block gets
797 consistent gets
1 physical reads
0 redo size
11748 bytes sent via SQL*Net to client
729 bytes received via SQL*Net from client
21 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
289 rows processed
user503699 wrote:
Hello,
Some days back, I came across a blog entry in which author concluded that when a = b and b = c, oracle does not conclude as a = c. He also provided a test case to prove his point. The URL is [http://sandeepredkar.blogspot.com/2009/09/query-performance-join-conditions.html]
Now, I thought that that can not be true. So I executed his test case (on 10.2.04) and the outcome indeed proved his point. Initially, I thought it might be due to absense of PK-FK relationship. But even after adding the PK-FK relationship, there was no change in the outcome. Although, when I modified the subquery with list of values, both the queries performed equally. I tried asking the author on his blog but it seems he has not yet seen my comment.I see that Jonathan provided a helpful reply to you while I was in the process of setting up a test case.
Is it possible that the optimizer is correct? What if... the optimizer transformed the SQL statement? What if... the original SQL statement actually executes faster than the modified SQL statement? What if... the autotrace plans do not match the plans shown on that web page?
The first execution with the original SQL statement:
ALTER SESSION SET EVENTS '10053 trace name context forever, level 1';
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_case';
SET AUTOTRACE TRACE
SELECT ca.*, cu.*
FROM ca_receipt CA,
cu_all CU
WHERE CA.CUSTID = CU.CUSTID
AND CA.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
CONNECT BY PRIOR CUSTID = CANO)
ORDER BY ACCTYPE DESC;
Execution Plan
Plan hash value: 2794552689
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 81081 | 1125 (2)| 00:00:01 |
| 1 | SORT ORDER BY | | 1001 | 81081 | 1125 (2)| 00:00:01 |
| 2 | NESTED LOOPS | | 1001 | 81081 | 1123 (1)| 00:00:01 |
| 3 | NESTED LOOPS | | 1001 | 26026 | 114 (2)| 00:00:01 |
| 4 | VIEW | VW_NSO_1 | 20 | 100 | 22 (0)| 00:00:01 |
| 5 | HASH UNIQUE | | 20 | 180 | | |
|* 6 | CONNECT BY WITH FILTERING | | | | | |
| 7 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 19 | 2 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | | | | |
| 10 | CONNECT BY PUMP | | | | | |
| 11 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 22 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 55 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
6 - access("CANO"=PRIOR "CUSTID")
8 - access("CUSTID"=2353)
12 - access("CANO"=PRIOR "CUSTID")
14 - access("CA"."CUSTID"="$nso_col_1")
16 - access("CA"."CUSTID"="CU"."CUSTID")
Statistics
1 recursive calls
0 db block gets
232 consistent gets
7 physical reads
0 redo size
2302 bytes sent via SQL*Net to client
379 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processedThe second SQL statement which was modified:
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_case2';
SELECT ca.*, cu.*
FROM ca_receipt CA,
cu_all CU
WHERE CA.CUSTID = CU.CUSTID
AND CU.CUSTID IN (SELECT CUSTID FROM cu_all START WITH custid = 2353
CONNECT BY PRIOR CUSTID = CANO)
ORDER BY ACCTYPE DESC;
Execution Plan
Plan hash value: 497148844
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 81081 | 136 (3)| 00:00:01 |
| 1 | SORT ORDER BY | | 1001 | 81081 | 136 (3)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID | CA_RECEIPT | 50 | 1050 | 52 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 1001 | 81081 | 134 (2)| 00:00:01 |
| 4 | NESTED LOOPS | | 20 | 1200 | 43 (3)| 00:00:01 |
| 5 | VIEW | VW_NSO_1 | 20 | 100 | 22 (0)| 00:00:01 |
| 6 | HASH UNIQUE | | 20 | 180 | | |
|* 7 | CONNECT BY WITH FILTERING | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 19 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | | | | |
| 11 | CONNECT BY PUMP | | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID| CU_ALL | 20 | 180 | 22 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | IND2_CU_ALL | 20 | | 1 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | CU_ALL | 1 | 55 | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | PK_CU_ALL_IND | 1 | | 0 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IND_CA_RECEIPT_CUSTID | 50 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
7 - access("CANO"=PRIOR "CUSTID")
9 - access("CUSTID"=2353)
13 - access("CANO"=PRIOR "CUSTID")
15 - access("CU"."CUSTID"="$nso_col_1")
16 - access("CA"."CUSTID"="CU"."CUSTID")
Statistics
1 recursive calls
0 db block gets
162 consistent gets
0 physical reads
0 redo size
2302 bytes sent via SQL*Net to client
379 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processed
ALTER SESSION SET EVENTS '10053 trace name context off';The question might be asked, does the final SQL statement actually executed look the same as the original? Slightly reformatted:
The first SQL statement:
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CA.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;
Final Transformation:
SELECT
"CA"."CUSTID" "CUSTID",
"CA"."CAAMT" "CAAMT",
"CA"."CADT" "CADT",
"CA"."TOTBAL" "TOTBAL",
"CU"."CUSTID" "CUSTID",
"CU"."ADDR" "ADDR",
"CU"."PH" "PH",
"CU"."CANO" "CANO",
"CU"."ACCTYPE" "ACCTYPE"
FROM
(SELECT DISTINCT
"CU_ALL"."CUSTID" "$nso_col_1"
FROM
"TESTUSER"."CU_ALL" "CU_ALL"
WHERE
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID"
CONNECT BY
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID") "VW_NSO_1",
"TESTUSER"."CA_RECEIPT" "CA",
"TESTUSER"."CU_ALL" "CU"
WHERE
"CA"."CUSTID"="VW_NSO_1"."$nso_col_1"
AND "CA"."CUSTID"="CU"."CUSTID"
ORDER BY
"CU"."ACCTYPE" DESC;The second SQL statement:
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CU.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;
Final Transformation:
SELECT
"CA"."CUSTID" "CUSTID",
"CA"."CAAMT" "CAAMT",
"CA"."CADT" "CADT",
"CA"."TOTBAL" "TOTBAL",
"CU"."CUSTID" "CUSTID",
"CU"."ADDR" "ADDR",
"CU"."PH" "PH",
"CU"."CANO" "CANO",
"CU"."ACCTYPE" "ACCTYPE"
FROM
(SELECT DISTINCT
"CU_ALL"."CUSTID" "$nso_col_1"
FROM
"TESTUSER"."CU_ALL" "CU_ALL"
WHERE
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID"
CONNECT BY
"CU_ALL"."CANO"=PRIOR "CU_ALL"."CUSTID") "VW_NSO_1",
"TESTUSER"."CA_RECEIPT" "CA",
"TESTUSER"."CU_ALL" "CU"
WHERE
"CA"."CUSTID"="CU"."CUSTID"
AND "CU"."CUSTID"="VW_NSO_1"."$nso_col_1"
ORDER BY
"CU"."ACCTYPE" DESC;Now, let's take a look at performance, flushing the buffer cache to force physical reads:
SET AUTOTRACE OFF
SET TIMING ON
SET AUTOTRACE TRACEONLY STATISTICS
SET ARRAYSIZE 100
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CA.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
SELECT
CA.*,
CU.*
FROM
CA_RECEIPT CA,
CU_ALL CU
WHERE
CA.CUSTID = CU.CUSTID
AND CU.CUSTID IN (
SELECT
CUSTID
FROM
CU_ALL
START WITH
CUSTID = 2353
CONNECT BY PRIOR
CUSTID = CANO)
ORDER BY
ACCTYPE DESC;The output:
/* (with AND CA.CUSTID IN...) */
52 rows selected.
Elapsed: 00:00:00.64
Statistics
0 recursive calls
0 db block gets
232 consistent gets
592 physical reads
0 redo size
2044 bytes sent via SQL*Net to client
346 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processed
/* (with AND CU.CUSTID IN...) */
52 rows selected.
Elapsed: 00:00:00.70
Statistics
0 recursive calls
0 db block gets
162 consistent gets
712 physical reads
0 redo size
2044 bytes sent via SQL*Net to client
346 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
52 rows processedThe original SQL statement completed in 0.64 seconds, and the second completed in 0.70 seconds.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Similar Messages
-
How to handle a phrase like a single word in a query rewrite template?
Hi there,
i would like to handle a case like this:
"hewlett packard" printer
I have a custom thesaurus where {hewlett packard} is a synonym of {hp}, and viceversa of course.
Now, i can successfully find records like "hp printer" or "printer model hp 2575 "by issuing the following query:
select * from sale_items
where contains(item_name,
'SYN(hewlett packard,cust_thes) AND printer')>0
or its equivalent form containing curly braces:
select * from sale_items
where contains(item_name,
'SYN({hewlett packard},cust_thes) AND printer')>0
My problem is that i can't find a way of successfully passing the phrase "hewlett packard" as a single word in a query rewrite template like this one:
select * from sale_items
where contains(item_name,
'<query>
<textquery grammar="CONTEXT">{hewlett packard} printer
<progression>
<seq><rewrite>transform((TOKENS, "SYN(", ",cust_thes)", " AND "))</rewrite></seq>
</progression>
</textquery>
<score datatype="INTEGER" algorithm="COUNT"/>
</query>')>0
When i run this query i get no rows.
The same happens if i substitute curly braces with double quotes.
So, how to get phrases to be recognized in the query rewrite template?
Bye,
FlavioI am unable to find out a way to search on the particular phrase like I have a document containing the text
“Oracle Text is a good searching tool.” Now if searches for the phrase “searching tool”, it doesn’t return any rows but if I search for “searching” and “tool” in 2 separate queries, it gives the document.
If any one has done it before, please tell me the solution.
I have used the following queries to create index on BLOB column:-
CREATE INDEX doc_ indx ON doctest(document)
INDEXTYPE IS ctxsys.CONTEXT PARAMETERS('lexer doc_lexer sync (on commit) ');
select * from doc_test where contains(document, 'searching tool') > 0;
select * from doc_test where contains(document,'searching') > 0;
select * from doc_test where contains(document,'tool') > 0;
Should I specify something while creating the indexes ?
Regards
Inderjeet -
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 LukacsHi 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 -
Are Cube organized materialized view with Year to Date calculated measure eligible for Query Rewrite
Hi,
Will appreciate if someone can help me with a question regarding Cube organized MV (OLAP).
Does cube organized materialized view with calculated measures based on time series Year to date, inception to date eg.
SUM(FCT_POSITION.BASE_REALIZED_PNL) OVER (HIERARCHY DIM_CALENDAR.CALENDAR BETWEEN UNBOUNDED PRECEDING AND CURRENT MEMBER WITHIN ANCESTOR AT DIMENSION LEVEL DIM_CALENDAR."YEAR")
are eligible for query rewrites or these are considered advanced for query rewrite purposes.
I was hoping to find an example with YTD window function on physical fact dim tables with optimizer rewriting it to Cube Org. MV but not much success.
Thanks in advanceI dont think this is possible.
(My own reasoning)
Part of the reason query rewrite works for base measures only (not calc measures in olap like ytd would be) is due to the fact that the data is staged in olap but its lineage is understandable via the olap cube mappings. That dependency/source identification is lost when we build calculated measures in olap and i think its almost impossible for optimizer to understand the finer points relating to an olap calculation defined via olap calculation (olap dml or olap expression) and also match it with the equivalent calculation using relational sql expression. The difficulty may be because both the olap ytd as well as relational ytd defined via sum() over (partition by ... order by ...) have many non-standard variations of the same calculation/definition. E.g: You can choose to use or choose not to use the option relating to IGNORE NULLs within the sql analytic function. OLAP defn may use NASKIP or NASKIP2.
I tried to search for query rewrite solutions for Inventory stock based calculations (aggregation along time=last value along time) and see if olap cube with cube aggregation option set to "Last non-na hierarchical value" works as an alternative to relational calculation. My experience has been that its not possible. You can do it relationally or you can do it via olap but your application needs to be aware of each and make the appropriate backend sql/call. In such cases, you cannot make olap (aw/cubes/dimensions) appear magically behind the scenes to fulfill the query execution while appearing to work relationally.
HTH
Shankar -
Materialized Views with Query Rewrite is not getting re-written
I have tried everything that has been mentioned in all the forums here and on metalink to fix this issue, has any smart APEX user found a solution?
The issue is the MV with Query rewrite capability is not being re-written.
Things I have tried
1) give all Query Rewrite privileges to all 3 APEx schemas and parsing schema;
2) check trace files with tkprof;
3) dynamically printed explain plan from v$_SQL on the page while executing the query;
4) to test in a different environment i created an another DAD using the pl/sql webtool kit and tried the same thing and rewrite works like a charm...
whats the issue here...why are apex schemas not re-writing the queries????
appreciate any help...thanksJes, per your request
--create materialized view
CREATE MATERIALIZED VIEW "RPLANSWEB"."MV_FCG_ALL_SUMMARY_TAB"
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 81920 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "RPLANSWEB"
BUILD IMMEDIATE
USING INDEX
REFRESH FORCE ON DEMAND
USING DEFAULT LOCAL ROLLBACK SEGMENT
ENABLE QUERY REWRITE
AS SELECT fcg, year, fcg_desc,
fac, efr, fac_desc, efr_desc,
ums_round, fcg_allow_drillable allow_drillable,
MAX(category_code_um1) category_code_um1,
SUM(perm_asset) perm_asset,
SUM(temp_asset) temp_asset,
SUM(semi_asset) semi_asset,
SUM(lease_asset) lease_asset,
SUM(planned_constr) planned_constr,
SUM(all_perm_asset) all_perm_asset,
SUM(total_asset) total_asset,
SUM(allow) allow, SUM(rqmt) rqmt,
SUM(perm_planned_constr) perm_planned_constr,
SUM(perm_planned_constr_rqmt_delta) perm_planned_constr_rqmt_delta,
ROUND(DECODE(SUM(rqmt), 0, 0, SUM(all_perm_asset)/SUM(rqmt)*100)) perm_rqmt_pctsat,
ROUND(DECODE(SUM(allow), 0, 0, SUM(all_perm_asset)/SUM(allow)*100)) perm_allw_pctsat,
ROUND(DECODE(SUM(rqmt), 0, 0, SUM(total_asset)/SUM(rqmt)*100)) total_rqmt_pctsat,
ROUND(DECODE(SUM(allow), 0, 0, SUM(total_asset)/SUM(allow)*100)) total_allw_pctsat,
ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(rqmt)/SUM(all_perm_asset)*100)) perm_rqmt_pctutl,
ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(allow)/SUM(all_perm_asset)*100)) perm_allw_pctutl,
ROUND(DECODE(SUM(total_asset), 0, 0, SUM(rqmt)/SUM(total_asset)*100)) total_rqmt_pctutl,
ROUND(DECODE(SUM(total_asset), 0, 0, SUM(allow)/SUM(total_asset)*100)) total_allw_pctutl,
SUM(coarse_screen_asset) coarse_screen_asset,
SUM(total_excess) total_excess,
SUM(total_deficit) total_deficit,
SUM(perm_excess) perm_excess,
SUM(perm_deficit) perm_deficit,
SUM(all_perm_excess) all_perm_excess,
SUM(all_perm_deficit) all_perm_deficit,
SUM(temp_excess) temp_excess,
SUM(satisfy_rqmt) satisfy_rqmt
FROM summary_tab_dd
GROUP BY fcg, year, fcg_desc,
fac, efr, fac_desc, efr_desc,
ums_round, fcg_allow_drillable;
sql plus> log in as parsing schema user (not APEX_PUBLIC_USER)
sql plus> SELECT fcg, year, fcg_desc,
SUM(perm_asset) perm_asset,
SUM(perm_excess) perm_excess,
SUM(perm_deficit) perm_deficit,
SUM(all_perm_excess) all_perm_excess,
SUM(all_perm_deficit) all_perm_deficit,
SUM(temp_excess) temp_excess,
SUM(satisfy_rqmt) satisfy_rqmt
FROM summary_tab_dd
where year=2007
GROUP BY fcg, year, fcg_desc;
--execution plan
SELECT STATEMENT ALL_ROWS 12 291 17460
HASH(GROUP BY) 12 291 17460
MAT_VIEW REWRITE ACCESS(FULL) RPLANSWEB.MV_FCG_ALL_SUMMARY_TAB ANALYZED 11 291 17460 "MV_FCG_ALL_SUMMARY_TAB"."YEAR"=2007
--execution plan from sql workshop (application express)
SELECT STATEMENT 42,341 55 3,882 1,990,027
HASH GROUP BY 42,341 55 3,882 1,990,027
TABLE ACCESS FULL SUMMARY_TAB_DD 109,158 47 3,329 5,130,426 "YEAR" = 2007
--execution plan from an APEX page (displayed from v$sql and V$SQL_PLAN)
OPERATION: SELECT STATEMENT OPTIONS: OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: ALL_ROWS SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: BYTES: CPU_COST: IO_COST: ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION:
OPERATION: HASH OPTIONS: GROUP BY OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: 109158 BYTES: 8732640 CPU_COST: 549150132 IO_COST: 4569 ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION: "FCG"[VARCHAR2,6], "FCG_DESC"[VARCHAR2,15], SUM("PERM_DEFICIT")[22], SUM("PERM_EXCESS")[22], SUM("SATISFY_RQMT")[22], SUM("TEMP_EXCESS")[22], SUM("ALL_PERM_EXCESS")[22], SUM("ALL_PERM_DEFICIT")[22], SUM("PERM_ASSET")[22]
OPERATION: TABLE ACCESS OPTIONS: FULL OBJECT_NAME: SUMMARY_TAB_DD OBJECT_ALIAS: SUMMARY_TAB_DD@SEL$1 OBJECT_TYPE: TABLE OPTIMIZER: SEARCH_COLUMNS: 0 COST: 3329
as you can see while executing the script in sql developer the optimizer is finding the relevant materialized view, not in the case of APEX's SQL Workshop or Page.
appreciate your time -
Materialized views - query rewrite -- optional joins & dimensions
Hi,
I've implemented a number of materialized views that are accessible via query rewrite.
Most of these views make use of duplicate tables (DD_TIME table is joined via purchase, load, process, ... date columns)
I've also created a dimension to make Oracle aware of the time relation (month is child of year...)
The issue:
--> If I create the mat. view with inner joins, query rewrite works with the dimensions, but I need to provide ALL joined tables in the query
--> If I create the mat. view with outer joins, query rewrite works even with 1 joined table, but the dimension seems to be ignored
How can I create 'optional' joins in the Mat. View while making use of dimensions for rollup?
(the limitations on materialized view delta joins mentioned on [oracle docs|http://docs.oracle.com/cd/B28359_01/server.111/b28313/qradv.htm#autoId16] kinda has me worried)
Example Mat. View:
CREATE MATERIALIZED VIEW DA_REPOSITORY_MERCHANT_MM
... ENABLE QUERY REWRITE
AS SELECT
DDFPC.YEAR_NO,
DDFPC.YEAR_MONTH,
DDPUR.YEAR_NO,
DDPUR.YEAR_MONTH,
SUM( DF.TRANSACTION_AMOUNT )
FROM DF_REP DF,
DD_TIME DDFPC,
DD_TIME DDPUR
WHERE DF.FPC_DTE = DDFPC.DAY_DATE(+)
AND DF.PUR_DTE = DDPUR.DAY_DATE(+)
GROUP BY
DDFPC.YEAR_NO,
DDFPC.YEAR_MONTH,
DDPUR.YEAR_NO,
DDPUR.YEAR_MONTH
Example query launched:
SELECT
DDFPC.YEAR_NO,
SUM( DF.TRANSACTION_AMOUNT )
FROM DF_REP DF,
DD_TIME DDFPC
WHERE DF.FPC_DTE = DDFPC.DAY_DATE
GROUP BY
DDFPC.YEAR_NOThe problem was resolved by setting foreign keys in the fact table and making them not nullable + using inner joins.
--> this informs oracle there can be no difference between a query without the dimensions and a query with the dimensions.
As a result, the materialized view can contain 1 fact linked to 2 dimension tables, but the query rewrite will work for queries on the 1 fact joined with only 1 dimension -
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 PMBingo!
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 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. -
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
TheodoreHello 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 -
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 - ProductionThanks 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] -
is there a way to log how often materialized views are accessed in general or by query rewrite enabled option?
i would like to find out which materialized views are useless, because they are never used by query rewrite.890408 wrote:
is there a way to log how often materialized views are accessed in general or by query rewrite enabled option?
i would like to find out which materialized views are useless, because they are never used by query rewrite.How about you check the mview properties from the view mv_capabilities_table ?
Aman.... -
Query Rewrite with regular database Views
Hi all,
I'm trying to make my programmer's life easier by creating a database view for them to query the data, so they don't have to worry about joining tables. However, query rewrite doesn't work no matter how I define the MV and View. Here's an example:
I've Sales tables with columns: PDate, CustCode, Amount
and Customer table with columns: CustCode, CustDesc
I create a view SALES_V with columns: PDate, CustCode, CustDesc, Amount by joining Sales table with Customer table as follows:
create or replace view SALES_V as
select PDate, c.CustCode, c.CustDesc, Amount
from Sales s
join Customer c on (s.CustCode=c.CustCode);
For the sake of speed, I create a materialized view SALES_TOT_MV with columns: PDate, Amount with the following SQL:
create materialized view SALES_TOT_MV
enable query rewrite
as select PDate, sum(Amount) Amount from Sales
group by PDate;
When I run the following query, I expect it to be rewritten to make use of SALES_TOT_MV:
select PDate, sum(Amount) from SALES_V
group by PDate;
However, explain plan always tell me it's using SALES table, not the SALES_TOT_MV.
Can somebody tell me it's a limitation of Oracle optimizer or I'm just missing something for this?
Thanks in advance!!
- Andrew
Edited by: blackhole001 on Jan 28, 2010 12:34 PMblackhole001 wrote:
Hi all,
I'm trying to make my programmer's life easier by creating a database view for them to query the data, so they don't have to worry about joining tables. This sounds like a pretty horrible idea. I say this because you will eventually end up with programmers that know nothing about your data model and how to properly interact with it.
Additionally, what you will get is a developer that takes one of your views and see's that of the 20 columns in it, it has 4 that he needs. If all those 4 columns comes from a simple 2 table join, but the view has 8 tables, you're wasting a tonne of resources by using the view (and heaven forbid they have to join that view to another view to get 4 of the 20 columns from that other view as well).
Ideally you'd write stored routines that satisfy exactly what is required (if you are the database resource and these other programmers are java, .net, etc... based) and the front end developers would call those routines customized for an exact purpose.
Creating views is not bad, but it's by no means a proper solution to having developers not learn or understand SQL and/or the data model. -
Query Rewrite (QSM-01263) and Views in Execution Plan
Hello!
I created a query rewrite enabled materialized view from a query, which contains only tables (no views). Query rewrite didn't work, so i checked the query with dbms_mview.explan_rewrite, which told my that my query contains references to views or dictionary tables. I checked my query again, but there are only tables, no views, no dictionary tables.
When I look in the execution plan of my query I see that the query optimizer generates views, I guess from my subquery (?). "A view definition was processed, either from a stored view...or as defined by steps...".
I suppose that's the reason why my query rewrite doesn't work. All my other mat views are working fine, so the usual parameters (query_rewrite_enabled, integrity, etc.) are set correctly.
Do you have any ideas how to get my query rewrite enabled work?
Thanks!Modifying the query (potentially with hints) so that Oracle doesn't do the view transformation would be one option.
-
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,
Peterstreefpo 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? -
Materialized views - schedule, indexes, query rewrite, etc.
I'm trying to get the hang of materialized views and need some help . . .
running Oracle 10gR2
I created a materialized view as follows:
CREATE MATERIALIZED VIEW "MY_SCHEMA"."USERS"
AS
SELECT * FROM "USERS"@PRODUCTION -- to copy the USERS table from my production database to this database
Worked fine. So far so good. Then, I altered it to schedule the refresh:
ALTER MATERIALIZED VIEW "MY_SCHEMA"."USERS" REFRESH FORCE START WITH SYSDATE NEXT TRUNC(SYSDATE + 1) + 4/24
-- to schedule a refresh immediately (SYSDATE) and every morning thereafter at 4:00 am (I think)
then, I wanted to enable query rewrite, so I issued the following command:
ALTER MATERIALIZED VIEW "MY_SCHEMA"."USERS" ENABLE QUERY REWRITE;
and I got the
ALTER MATERIALIZED VIEW succeeded.
message for both of those commands (I'm doing this in SQL Developer).
Then, I edit the materialized view in SQL Developer, click on the 'SQL' tab, and get the following:
CREATE MATERIALIZED VIEW "MY_SCHEMA"."USERS"
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "TBLSPC_PHIGH"
BUILD IMMEDIATE
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "TBLSPC_PHIGH"
REFRESH FORCE ON DEMAND START WITH sysdate+0 NEXT TRUNC(SYSDATE + 1) + 4/24
WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
DISABLE QUERY REWRITE
AS SELECT "USERS"."User" "User","USERS"."Logon" "Logon","USERS"."Name" "Name","USERS"."Password"
"Password","USERS"."Level" "Level","USERS"."Producer" "Producer","USERS"."Deleted" "Deleted","USERS"."ClaimDoctor"
"ClaimDoctor","USERS"."UserType" "UserType","USERS"."Locked" "Locked","USERS"."Scheduler"
"Scheduler","USERS"."RestrictDays" "RestrictDays","USERS"."First" "First","USERS"."DisableAutoChart"
"DisableAutoChart","USERS"."MaxChartOut" "MaxChartOut","USERS"."MaxHoursOut" "MaxHoursOut","USERS"."EffDate"
"EffDate","USERS"."ExpDate" "ExpDate","USERS"."SwipeLogon" "SwipeLogon","USERS"."SwipePassword"
"SwipePassword","USERS"."PwdLastChanged" "PwdLastChanged","USERS"."Audit" "Audit","USERS"."IsInstructor"
"IsInstructor" FROM "USERS"@PRODUCTION.REGRESS.RDBMS.DEV.US.ORACLE.COM "USERS";
The problems I've encountered so far:
1) I created this two days ago and changed the value of one column in one row in the 'source' USERS table
(USERS@PRODUCTION) as a test case. So far, that change has not propagated over to my materialized view even though
it has had two chances to do so (yesterday morning at 4:00 am and this morning at 4:00 am).
2) I enabled QUERY REWRITE. Why does it still show DISABLE?
3) The primary key of the table came over (as far as I can tell) because it shows in SQL Developer. However, the
indexed columns are no longer indexed. Do I need to recreate those indexes manually and will they persist?
4) As you have guessed, I have just taken the plunge into materialized views, and have not been able to find
anything on the Web along the lines of 'Materialized Views for Dummies'. So, any and all advice/suggestions/help
will be welcome.
Thanks,
CarlThe Refresh would be executed by a job submitted in the background.
Query USER_JOBS (or DBA_JOBS) to see if a job has been submitted and if it has been running (you'd be able to see LAST_DATE, LAST_SEC and NEXT_DATE and NEXT_SEC). \
If the Refresh job has been failing the FAILURES count would be incremented. If there are 16 consecutive failures, the job is marked BROKEN. (if a job fails, Oracle retries it automatically and keeps retrying till it is BROKEN). If the job has been failing you would get messages in the database instance alert log file and trace files.
If the Refresh job has not been running check the parameter value for JOB_QUEUE_PROCESSES -- a value of 0 would not run in jobs in the USER_JOBS/DBA_JOBS view. Ask the DBA to increase set this parameter to at least 1.
Hemant K Chitale
http://hemantoracledba.blogspot.com
Maybe you are looking for
-
Image does not update in loop with control
Hi all, I am trying to make a data playback vi. I have some data recorded, and images recorded from another vi saved onto my computer. I want to sync the data with the video, so we can tell what was happening visually when there is something interes
-
Error in generating/deleting the index of the cube in Process chain
Hi All, I am getting an error in the process chain during the deletion/generation of index in the cube.... error says: " Deleting/reconstructing indexes for InfoCube 0CSAL_C01 is not permitted " Need your input for the same..... Thanks & Regards, Anu
-
Strange characters instead of PDF-file
when I forward to a servlet called Test.java, my browser return a PDF file. but when I write the method of the servlet in a bean, called WinkelWagen.java, and I write the rest of the code of the servlet in a jsp file (pdf.jsp, this jsp calls the meth
-
How to debug reports in Reports 10g
Hi, I'm customizing one R12 seeded report.Seeded report is working fine but when I modify the report by changing the query criterion then it's failing.Is there any debug feature like dbsm_output with sqlerrm in reports 10g .I can use srw.message to p
-
Error in XPRA_EXECUTION PHASE on SAINT transacction installing BPC 7.5
Hi I am installing Bussines Planning & Consolidation 7.5 on an Netweaver 7.01 with EHP1 (enhacement package 1) system but when I used SAINT transacction to install the ADDON for this ABAP component . First I received a message about some "conficts"