Is Query Rewrite being used?

How do I check if query rewrite is being used?
This is an 8174 database. When I run explain plan on the query used to create the MV, the plan shows all the tables/indexes to be used. It doesn't show the MV name in the explain plan.
Is this the correct way of verifying if query rewrite is being used?

Yes it is correct to see execution plan to check if query rewrite is used.
But keep in mind, than you must enable query_rewrite at least on session level and MV must be created with query rewrite option too.
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE;
CREATE MATERIALIZED VIEW sales_by_month_by_state
TABLESPACE example
PARALLEL 4
BUILD IMMEDIATE
REFRESH COMPLETE
ENABLE QUERY REWRITE
AS SELECT t.calendar_month_desc, c.cust_state_province,
SUM(s.amount_sold) AS sum_sales
FROM times t, sales s, customers c
WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id
GROUP BY t.calendar_month_desc, c.cust_state_province;
See doc for more details

Similar Messages

An index can not being used and still afect a query performance?

Hi i have a query with a high cost so i created two indexes, A and B, to improve its performance.
After the creation of the indexes when i reviewed the execution plan of the query the cost had been reduced, but i noticed that the index B is not being used,
and if i try to force the query to use index B with a HINT the cost increases, so i decided to drop the index B.
Once i droped the index B i checked the execution plan again and then i noticed that the cost of the query increased, if i recreate the index B the explain plan
shows a lower cost even though its not being used by the execution plan.
Does anyone know why is this happening?
An index can, not being used by the execution plan and still affect a query performance?

user11173393 wrote:
Hi i have a query with a high cost so i created two indexes, A and B, to improve its performance.
After the creation of the indexes when i reviewed the execution plan of the query the cost had been reduced, but i noticed that the index B is not being used,
and if i try to force the query to use index B with a HINT the cost increases, so i decided to drop the index B.
Once i droped the index B i checked the execution plan again and then i noticed that the cost of the query increased, if i recreate the index B the explain plan
shows a lower cost even though its not being used by the execution plan.
Does anyone know why is this happening?
An index can, not being used by the execution plan and still affect a query performance?You said that is what is happening, & I believe you.

How to assure index is being used for Query

Hi All,
Indexed are best way to speedup the data retrieval process selectively.
however i wanted to how to trace that weather index is being used in a particular query.
1. Table tab1 has composite index on a and b.
2. Select a,b,c from tab1 where a>500 ;
Will this query use index create from 1 ?
Conceptually it should not because where as part contains only field A where as index is composit on field A and B.
However , i wanted to know to trace that a perticual query is using index or not ?
This question was asked to me in an interview.
Pls le me know at [email protected]
Thanks in Advance
Alok

Hi,
Use explain plan to know if index is use.
As you can see in the following example, even if index is composed and I use only a part in query, index can be used :
SQL> create table test (col1 number, col2 number, col3 varchar2(10));
Table created.
SQL> insert into test select object_id, data_object_id, substr(object_name,1,10) from dba_objects;
70211 rows created.
SQL> create index idx on test(col1,col2);
Index created.
SQL> explain plan for
2 select col1,col2,col3 from test where col1 > 500;
Explained.
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls
PLAN_TABLE_OUTPUT
| Id | Operation                   | Name       | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT            |             |       |       |       |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST        |       |       |       |
|* 2 |   INDEX RANGE SCAN          | IDX         |       |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   2 - access("TEST"."COL1">500)
       filter("TEST"."COL1">500)
Note: rule based optimization
16 rows selected.
--If stats are collected, index is no more used
SQL> analyze table test compute statistics;
SQL> explain plan for
2 select col1,col2,col3 from test where col1 > 500;
Explained.
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls
PLAN_TABLE_OUTPUT
| Id | Operation            | Name       | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT     |             | 69808 | 1227K|    16 |
|* 1 | TABLE ACCESS FULL   | TEST        | 69808 | 1227K|    16 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter("TEST"."COL1">500)
Note: cpu costing is off
14 rows selected.
--But if you use an equlity in your query instead of >, index is still used
SQL> explain plan for
2 select col1,col2,col3 from test where col1 = 500;
Explained.
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls
PLAN_TABLE_OUTPUT
| Id | Operation                   | Name       | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT            |             |     1 |    18 |     3 |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST        |     1 |    18 |     3 |
|* 2 |   INDEX RANGE SCAN          | IDX         |     1 |       |     2 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   2 - access("TEST"."COL1"=500)
Note: cpu costing is off
15 rows selected.
SQL> Nicolas.

Audit mviews which are used by query rewrite

Hi all,
on of our main customers want to find out which MVIEWS are used after an automated query rewrite.
Example:
select * from OP_SUM_BACKLOG_DAY_SAP_001;
select * from dba_audit_trail
where timestamp > trunc(sysdate)
and username = 'SMITH'
and obj_name = 'OP_SUM_BACKLOG_DAY_SAP_001'
This following statement is using the same MVIEW because of aggregations and the use of query rewrite:
SELECT fbld_ddat_sales_month,
         SUM (fbld_dummy_zero) fbld_dummy_zero,
         SUM (fbld_dummy_null_number) fbld_dummy_null_number,
         SUM (fbld_oab_quantity) fbld_oab_quantity
    FROM op_fct_backlog_day_sap
GROUP BY fbld_ddat_sales_month;
This query is never listed in dba_audit_trail!!!
Plan
3 SELECT STATEMENT ALL_ROWS Cost: 291 Bytes: 52 Cardinality: 2 CPU Cost: 0 IO Cost: 0 Time: 00:00:00 Partition #: 0
2 HASH GROUP BY Projection: (#keys=1) "OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_DDAT_SALES_MONTH"[VARCHAR2,6], SUM("OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_OAB_QUANTITY")[22], SUM("OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_DUMMY_NULL_NUMBER")[22], SUM("OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_DUMMY_ZERO")[22] Cost: 291 Bytes: 52 Cardinality: 2 CPU Cost: 0 IO Cost: 0 Time: 00:00:00 Partition #: 0
1 MAT_VIEW REWRITE ACCESS FULL DWHOP.OP_SUM_BACKLOG_DAY_SAP_001 [Analyzed] Projection: "OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_DDAT_SALES_MONTH"[VARCHAR2,6], "OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_DUMMY_ZERO"[NUMBER,22], "OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_DUMMY_NULL_NUMBER"[NUMBER,22], "OP_SUM_BACKLOG_DAY_SAP_001"."FBLD_OAB_QUANTITY"[NUMBER,22] Cost: 290 Bytes: 1.016.600 Cardinality: 39.100 CPU Cost: 0 IO Cost: 0 Time: 00:00:00 Partition #: 0
Any ideas how to audit this access???
Regards
Stephan

Hi,
Get the UID of your query from the query designer (select query in the properties window, goto Advanced tab).
Pass it to table RSZELTXREF (pass query UID to field SELTUID and 'VAR' to field LAYTP). This gives the list of variables used in the query. Now got to table RSZGLOBV, pass all the variable IDs (field values for TELTUID from table RSZELTXREF) to the field VARUNIID and restrict VPROCTP to '6'. This gives a list of all the auth variables used in a query.
Regards,
Murali.

How to find CPU_time being used by currently executing query

Hello,
Is there a way to know how much CPU is being used by a query that is currently being runninng? I tried to look into dm_exec_sessions or even dm_exec_requests dmv but it looks like CPU_time stat doesn't get updated to those views until the query actually
completes or get cancelled. Sometimes, it's important to find out among the actively running queries, which session/query is consuming the most CPU and there seem to be no way to find out that stat until the query actually completes or get cancelled. I was
testing it on SQL 2008 r2 but behavior could be same on 2014 or 2012.
Appreciate any feedback.
thanks,
Raj

I have been using Adam's great utility
Who Is Active? v10.00 (2010-10-21)
(C) 2007-2010, Adam Machanic
Updates: http://sqlblog.com/blogs/adam_machanic/archive/tags/who+is+active/default.aspx
"Beta" Builds: http://sqlblog.com/files/folders/beta/tags/who+is+active/default.aspx
License:
Who is Active? is free to download and use for personal, educational, and internal
corporate purposes, provided that this header is preserved. Redistribution or sale
of Who is Active?, in whole or in part, is prohibited without the author's express
written consent.
CPU filter
/*CPU*/
EXEC dbo.sp_WhoIsActive
@get_transaction_info=0,
@output_column_list ='[session_id][start_time]
[cpu][status][context_switches][wait_info][program_name]
[database_name][sql_text][host_name][open_tran_count]',
@sort_order='[CPU]DESC'
/*delta*/
EXEC dbo.sp_WhoIsActive
@delta_interval=5, @get_task_info = 2,
@output_column_list ='[session_id][start_time][context switches]
[CPU_delta][reads_delta][writes_delta][tempdb_writes_delta]
[tempdb_reads_delta][tempdb_current_delta]
[database_name][host_name][login_name]',
@sort_order='[CPU_delta]DESC'
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence

Very high parse times for query rewrite using cube materialized views

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

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

How to know if a specific InfoObject is being used in any Query

Dear SDN members,
I have an InfoObject which is being used for one of the InfoCube. This specific Infocube has more than 100 queries created. Is there any way I can find out if above mentioned Info Object is being used anywhere in one of those queries without manually checking one by one.
I tried where used list which appears on the InfoObject screen. This is just showing Cubes, ODS, TRs, Infosources... but not covering the queries.
Your help is much appreciated.
many thanks
Shanthi

Hi Shanti,
You can see this in the Metadata repository.
Select infoobject and the the specific infoobject.
It will show you a list of queries where the infoobject is used.
Success
Udo

Please let me know a good query to find out the memory being used in DB

Hi All,
We are using Automotic memory management by using parameter memory_target option. I want to find out the total memory being used and which is free.
ie;(SGA+PGA). Please let me know.
Thanks & Regards,
Vikas Krishna

Since we are using memry_target we will not get an accurate value there I guess.
SQL> show parameter memory
NAME TYPE VALUE
hi_shared_memory_address integer 0
memory_max_target big integer 12G
memory_target big integer 12G
shared_memory_address integer 0
SQL> select round(used.bytes /1024/1024 ,2) used_mb
2 , round(free.bytes /1024/1024 ,2) free_mb
3 , round(tot.bytes /1024/1024 ,2) total_mb
4 from (select sum(bytes) bytes
5 from v$sgastat
6 where name != 'free memory') used
7 , (select sum(bytes) bytes
8 from v$sgastat
9 where name = 'free memory') free
10 , (select sum(bytes) bytes
11 from v$sgastat) tot;
USED_MB FREE_MB TOTAL_MB
1660.92 378.71 2039.62
Thanks & Regards,
Vikas Krishna

Materialized view not being used in the report

I have had a materialized view (MV) for a particular report. Recently, the report definition has changed little bit, so the existing MV is not being used by the report anymore. I copied the code Discoverer's SQL Inspection and recreated the materialized view. But still it is not working. Obviously, I am missing something at the database level. Does anyone have any idea? The database is 9i and Discoverer is 9.0.2. Thank you!

The SQL that you see from the Inspect SQL option will provide you with the SQL that Discoverer sends to the database. The database then may do a query rewrite to point to an available materialized view if available. This rewrite won't be seen from the inspect sql option. You need to check at the database level to verify if a query rewrite did in fact take place.
You may want to check the section titled "Query Rewrite with Materialized Views" from Ch1 - "Introduction to the Optimizer" in the Oracle9i Database Performance Tuning Guide and Reference, Release 2 (9.2), Part Number A96533-02, available at http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96533/optimops.htm#37287
Regards
Abhinav Agarwal
Oracle Business Intelligence Product Management
http://www.oracle.com/bi
http://www.oracle.com/technology/documentation/bi_ee.html
http://www.oracle.com/technology/software/products/ias/htdocs/101320bi.html
http://oraclebi.blogspot.com/

Index not being used in access path

Hi,
I have been trying to rewrite a query which currently is taking almost 1min and 25 secs to execute. The database version is 11.1.0.7.
The query is -
SELECT COUNT(1)
FROM TAB1 p
WHERE p.ACODE = 24377
AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
AND p.rflag = 'Y';
The table originally didn't have an index on p.ACODE. So, I created this index and set it to visible and set the optimizer_use_invisible_indexes parameter also to TRUE. I set the monitoring on this index too. Even though I have created the index on the ACODE column, the access path doesn't use it. Can someone please tell me why this is not being used.
Below is the explain plan for the sql stmt and the usage of the index -
I have changed the actual table and column names -
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.ACODE = 24377
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.ACODE = 24377
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3942424611
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 214K (2)| 00:42:57 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 214K (2)| 00:42:57 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 209K (2)| 00:41:56 |
|* 4 | TABLE ACCESS FULL | TAB1 | 1 | 32 | 209K (2)| 00:41:55 |
| 5 | INDEX FAST FULL SCAN| PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AKey")
3 - access("PHS"."PKey"="P"."AKey")
4 - filter(TO_NUMBER("P"."ACODE")=24377 AND "P"."rflag"='Y')
20 rows selected.
Elapsed: 00:00:00.03
SQL> select index_name,VISIBILITY from user_indexes where index_name='IDX_TAB1_ACODE';
INDEX_NAME VISIBILIT
IDX_TAB1_ACODE VISIBLE
Elapsed: 00:00:00.01
SQL> show parameter visible
NAME TYPE VALUE
optimizer_use_invisible_indexes boolean TRUE
SQL>
SQL> SELECT v.index_name, v.table_name,
v.monitoring, v.used,
start_monitoring, end_monitoring
FROM v$object_usage v, dba_indexes u
WHERE v.index_name = u.index_name
AND v.index_name = 'IDX_TAB1_ACODE';
INDEX_NAME TABLE_NAME MON USE START_MONITORING END_MONITORING
IDX_TAB1_ACODE TAB1 YES NO 05/26/2010 14:13:41
Elapsed: 00:00:00.10
Edited by: user12158503 on May 26, 2010 1:24 PM

Thanks Centinul.
I apologize for posting in both sections. I put it in the Database General too because I thought I originally posted it in the wrong section.
The index was not being used because it was doing the implicit type conversion. When I enclosed it in quotes, it returns the result within a second and it uses the index.(whereas without the index it takes around 1min 25 sec)
Here is the explain plan and execution time after enclosing it in quotes -
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.AKey = '24377'
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 2008452282
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 5134 (1)| 00:01:02 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 5134 (1)| 00:01:02 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 60 (2)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 32 | 6 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | IDX_TAB1_AKey | 4 | | 1 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 7 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AGILITYKEY")
3 - access("PHS"."PKey"="P"."AGILITYKEY")
4 - filter("P"."rflag"='Y')
5 - access("P"."AKey"='24377')
22 rows selected.
Elapsed: 00:00:00.02
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.AKey = '24377'
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
Elapsed: 00:00:00.52
Can you give me some tips on where I could read about learning to understand the explain plan. I did read a few articles which did help me, but not much. I am looking for something in detail.

Materialized Views with Query Rewrite is not getting re-written

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

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

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]

Query rewrite don't work wor aggregate query but work for join query

Dear experts,
Let me know what's wrong for
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
I have two MATERIALIZED VIEW:
A) -- Only join
CREATE MATERIALIZED VIEW "SCOTT"."TST_MV"
ENABLE QUERY REWRITE AS
SELECT "T57410"."MEMBER_KEY" "MEMBER_KEY",
"T57410"."ANCESTOR_KEY" "ANCESTOR_KEY",
"T57410"."DISTANCE" "DISTANCE",
"T57410"."IS_LEAF" "IS_LEAF",
"T57460"."DEPARTMENTID" "DEPARTMENTID",
"T57460"."NAME" "NAME","T57460"."PARENT"
"PARENT","T57460"."SHORTNAME" "SHORTNAME",
"T57460"."SKIMOID" "SKIMOID"
FROM "BI_OIV_HIER" "T57410",
"BI_DEPARTMENTS" "T57460"
WHERE "T57410"."ANCESTOR_KEY"="T57460"."DEPARTMENTID";
B) -- Join with aggregation
CREATE MATERIALIZED VIEW "SCOTT"."TST_MV2"
("C41", "C42", "C43",
"C44", "C45", "C46",
"C47", "C48", "C49",
"C50", "C51", "C52",
"C53", "C54", "C55",
"C56", "C57", "C58",
"C59", "C60", "C61",
"INCIDENTTYPE")
ENABLE QUERY REWRITE
AS SELECT COUNT(T56454.TOTAL) AS c41,
T56840.CATEGORYID AS c42,
T56840.PARENT AS c43,
T56908.DOCSTATEID AS c44,
T56908.PARENT AS c45,
T56947.EXPIREDID AS c46,
T56947.PARENT AS c47,
T56986.ISSUESTATEID AS c48,
T56986.PARENT AS c49,
T57025.LOCATIONID AS c50,
T57025.PARENT AS c51,
T57064.NEWID AS c52,
T57064.PARENT AS c53,
T57103.PARENT AS c54,
T57103.RESOLUTIONID AS c55,
T57142.PARENT AS c56,
T57142.RESPONSIBLEID AS c57,
T57181.PARENT AS c58,
T57181.SOURCEID AS c59,
T57460.DEPARTMENTID AS c60,
T57460.PARENT AS c61,
T56454.INCIDENTTYPE
FROM BI_OIV_HIER T57410
BI_DEPARTMENTS T57460
BI_SOURCE_HIER T57176
SOURCE T57181
BI_RESPONSIBLE_HIER T57137
RESPONSIBLE T57142
BI_RESOLUTIONS_HIER T57098
RESOLUTIONS T57103
BI_NEW_HIER T57059
NEW T57064
BI_LOCATIONS_HIER T57020
LOCATIONS T57025
BI_ISSUESTATES_HIER T56981
ISSUESTATES T56986
BI_EXPIRED_HIER T56942
EXPIRED T56947
BI_DOCSTATES_HIER T56903
DOCSTATES T56908
BI_CATEGORY_HIER T56835
CATEGORY T56840
INCIDENTS T56454
WHERE ( T56454.RESOLUTION = T57098.MEMBER_KEY
AND T56454.CATEGORY = T56835.MEMBER_KEY
AND T56454.DOCSTATE = T56903.MEMBER_KEY
AND T56454.EXPIRED = T56942.MEMBER_KEY
AND T56454.ISSUESTATE = T56981.MEMBER_KEY
AND T56454.LOCATION = T57020.MEMBER_KEY
AND T56454.NEW = T57059.MEMBER_KEY
AND T56454.RESPONSIBLE = T57137.MEMBER_KEY
AND T56454.SOURCE = T57176.MEMBER_KEY
AND T56454.DEPARTMENTID = T57410.MEMBER_KEY
AND T56835.ANCESTOR_KEY = T56840.CATEGORYID
AND T56903.ANCESTOR_KEY = T56908.DOCSTATEID
AND T56942.ANCESTOR_KEY = T56947.EXPIREDID
AND T56981.ANCESTOR_KEY = T56986.ISSUESTATEID
AND T57020.ANCESTOR_KEY = T57025.LOCATIONID
AND T57059.ANCESTOR_KEY = T57064.NEWID
AND T57098.ANCESTOR_KEY = T57103.RESOLUTIONID
AND T57137.ANCESTOR_KEY = T57142.RESPONSIBLEID
AND T57176.ANCESTOR_KEY = T57181.SOURCEID
AND T57410.ANCESTOR_KEY = T57460.DEPARTMENTID
GROUP BY T56840.CATEGORYID,
T56840.PARENT,
T56908.DOCSTATEID,
T56908.PARENT,
T56947.EXPIREDID,
T56947.PARENT,
T56986.ISSUESTATEID,
T56986.PARENT,
T57025.LOCATIONID,
T57025.PARENT,
T57064.NEWID,
T57064.PARENT,
T57103.PARENT,
T57103.RESOLUTIONID,
T57142.PARENT,
T57142.RESPONSIBLEID,
T57181.PARENT,
T57181.SOURCEID,
T57460.DEPARTMENTID,
T57460.PARENT,
T56454.INCIDENTTYPE;
So, optimizer uses query rewrite in
select * from TST_MV
and don't use query rewrite in
select * from TST_MV2
within one session.
select * from TST_MV should be read as underlying select for TST_MV:
SELECT "T57410"."MEMBER_KEY" "MEMBER_KEY",
"T57410"."ANCESTOR_KEY" "ANCESTOR_KEY",
"T57410"."DISTANCE" "DISTANCE",
"T57410"."IS_LEAF" "IS_LEAF",
"T57460"."DEPARTMENTID" "DEPARTMENTID",
"T57460"."NAME" "NAME","T57460"."PARENT"
"PARENT","T57460"."SHORTNAME" "SHORTNAME",
"T57460"."SKIMOID" "SKIMOID"
FROM "BI_OIV_HIER" "T57410",
"BI_DEPARTMENTS" "T57460"
WHERE "T57410"."ANCESTOR_KEY"="T57460"."DEPARTMENTID";
So, select * from TST_MV2 should be read by similar way as underlying select to TST_MV2
DBMS_STATS.GATHER_TABLE_STAT is done for each table and MV.
Please help to investigate the issue.
Why TST_MV2 don't used for query rewrite ?
Kind regards.

Hi Carlos
It looks like you have more than one question in your posting. Would I be right in saying that you have an issue with how long Discoverer takes when compared with SQL, and a second issue with regards to MVs not being used? I will add some comments on both. If one of these is not an issue please inform.
Issue 1:
Have you compared the explain plan from Discoverer with SQL? You may need to use a tool like TOAD to see it.
Also, is Discoverer doing anything complicated with the data after it comes back? By complicated I mean do you have a large number of Page Items and / or Group Sorted items? SQL wouldn't have this overhead you see.
Because SQL would create a table, have you tried creating a table in Discoverer and seeing how long it takes?
Finally, what version of the database are you using?
Issue 2:
Your initial statement was that query rewrite works with several MV but not with others, yet in the body of the report you only show explain plans that do use the MV. Could you therefore go into some more detail regarding this situation.
Best wishes
Michael

Usage of Query Rewrite in Materialized Views

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

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

How to get table and column names thats being used in SQL , that's generating all my reports on SSRS.

Good day,
I searched through the forum and cant find anything.
I have around 300 published reports on SSRS and we are busy migrating to a new system.
They have already setup their tables on the new system and I need to provide them with a list of table names and column names that are being used currently to generate the 300 reports on SSRS.
We use various tables and databases to generate these reports, and will take me forever to go through each query to get this info.
Is it at all possible to write a query in SQL 2008 that will give me all the table names and columns being used?
Your assistance is greatly appreciated.
I thank you.
Andre.

There's no straightforward method for that I guess. There are couple of things you can use to get these details
1. query the ReportServer.dbo.Catalog table
for getting details
you may use script below for that
http://gallery.technet.microsoft.com/scriptcenter/42440a6b-c5b1-4acc-9632-d608d1c40a5c
2. Another method is to run the reports and run sql profiler trace on background to retrieve queries used.
But in some of these cases the report might be using a procedure and you will get only procedure. Then its upto you to get the other details from procedure like tables used, columns etc
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Is Query Rewrite being used?

Similar Messages

Maybe you are looking for