Comments on: Subquery Factoring http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/ Just another Oracle weblog Wed, 22 May 2013 12:40:08 +0000 hourly 1 http://wordpress.com/ By: CJ http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46795 Wed, 30 May 2012 15:37:41 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46795 Looks like I have found my answer. The NO_MERGE hint needs to be added not to the CTE, but to every query wherein the CTE referred.

[SOURCECODE]

explain plan for
with snp as (select f_test() snap_id from dual)
select /*+ no_merge(b) */ count(*)
from dba_hist_snapshot a, snp b
where (a.snap_id= b.snap_id)
union all
select /*+ no_merge(b) */ count(*)
from dba_hist_snapshot a, snp b
where (a.snap_id < b.snap_id) ;

————————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————————–
| 0 | SELECT STATEMENT | | 2 | 40 | 211 (51)| 00:00:01 |
| 1 | UNION-ALL | | | | | |
| 2 | SORT AGGREGATE | | 1 | 20 | | |
|* 3 | HASH JOIN | | 4 | 80 | 106 (2)| 00:00:01 |
| 4 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 5 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
|* 6 | TABLE ACCESS FULL| WRM$_SNAPSHOT | 16314 | 111K| 103 (1)| 00:00:01 |
| 7 | SORT AGGREGATE | | 1 | 20 | | |
| 8 | NESTED LOOPS | | 816 | 16320 | 105 (1)| 00:00:01 |
| 9 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 10 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
|* 11 | TABLE ACCESS FULL| WRM$_SNAPSHOT | 816 | 5712 | 103 (1)| 00:00:01 |
————————————————————————————–

Predicate Information (identified by operation id):
—————————————————

3 – access("SNAP_ID"="B"."SNAP_ID")
6 – filter("STATUS"=0)
11 – filter("STATUS"=0 AND "SNAP_ID"<"B"."SNAP_ID")

[/sourcecode]

This is contrary to my earlier perception that NO_MERGE hint had to be added to the CTE and not anywhere else. Which one is correct?

Many thanks.

]]> By: CJ http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46794 Wed, 30 May 2012 15:08:13 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46794 Jonathan sir,

A rather curious behaviour with NO_MERGE and UNION. NO_MERGE works with the query appearing last in UNION ALL, but not the query appearing before.



explain plan for
with snp as (select /*+ no_merge */ f_test() snap_id from dual)
select count(*)
from dba_hist_snapshot a, snp b
where (a.snap_id= b.snap_id) 
union all
select count(*)
from dba_hist_snapshot a, snp b
where (a.snap_id < b.snap_id) 
;


--------------------------------------------------------------------------------------
| Id  | Operation            | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |               |     2 |    27 |   218  (53)| 00:00:01 |
|   1 |  UNION-ALL           |               |       |       |            |          |
|   2 |   SORT AGGREGATE     |               |     1 |     7 |            |          |
|   3 |    NESTED LOOPS      |               |     4 |    28 |   113   (8)| 00:00:01 |
|   4 |     FAST DUAL        |               |     1 |       |     2   (0)| 00:00:01 |
|*  5 |     TABLE ACCESS FULL| WRM$_SNAPSHOT |     4 |    28 |   111   (9)| 00:00:01 |
|   6 |   SORT AGGREGATE     |               |     1 |    20 |            |          |
|   7 |    NESTED LOOPS      |               |   816 | 16320 |   105   (1)| 00:00:01 |
|   8 |     VIEW             |               |     1 |    13 |     2   (0)| 00:00:01 |
|   9 |      FAST DUAL       |               |     1 |       |     2   (0)| 00:00:01 |
|* 10 |     TABLE ACCESS FULL| WRM$_SNAPSHOT |   816 |  5712 |   103   (1)| 00:00:01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - filter("SNAP_ID"="F_TEST"() AND "STATUS"=0)
  10 - filter("STATUS"=0 AND "SNAP_ID"<"B"."SNAP_ID")

From the filter conditions you can see that the function will execute once for every row in the first part of UNION, whereas it will execute only once for the second part. I traced using DBMS_PROFILER to confirm this. What can be the reason? (BTW, this is why I was trying to push in the MATERIALIZE hint).

Many thanks.

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46724 Mon, 28 May 2012 16:57:39 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46724 CJ,

I’d like a preview option as well – but it’s not available.

The sourcecode tags (which you correctly put in square brackets) have an open and close form. To close you need a leading /, as in “/sourcecode” (but in square brackets, not quote marks).

If you look in view v$sql_hints you will find that the inline and materialize hints do not have an “outline version” which (I believe) means you can’t inject them through a stored outline, profile, or SQL Baseline. In your case it would be sufficient to inject a no_merge() hint into the subquery factoring clause (CTE). Since the query block in the clause is sel$1 you need a minimum of /*+ no_merge(@sel$1) */ in your outline/profile to get the plan:

-------------------------------------------------------------------------------------
| Id  | Operation           | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |               |     1 |    19 |     5  (20)| 00:00:01 |
|   1 |  SORT AGGREGATE     |               |     1 |    19 |            |          |
|*  2 |   HASH JOIN         |               |     1 |    19 |     5  (20)| 00:00:01 |
|   3 |    VIEW             |               |     1 |    13 |     2   (0)| 00:00:01 |
|   4 |     FAST DUAL       |               |     1 |       |     2   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS FULL| WRM$_SNAPSHOT |    54 |   324 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Technically an alternative hint would be /*+ outline_leaf(@sel$1) */, but the outline_leaf() hint is not documented, so should not be used.

]]> By: CJ http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46723 Mon, 28 May 2012 16:39:20 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46723 And maybe a facility to delete comments.. because my earlier comment is now redundant.

]]> By: CJ http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46721 Mon, 28 May 2012 15:33:24 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46721 I see that the ‘sourcecode’ tags haven’t been applied. A preview functionality here would be really helpful.

]]> By: CJ http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46720 Mon, 28 May 2012 15:31:26 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46720 Jonathan sir,

Is it possible to ‘push’ the effects of materialize hint in a query plan using SQL profile?

I am trying to attach materialize hint to a query using SQL profile, but the plan generated through the SQL profile doesn’t match with the one generated through direct hint. Version is 10.2.0.5 EE on RHEL.


create or replace function f_test
return number
as 
begin
  for r in (select min(snap_id) snap_id from dba_hist_snapshot)
	loop
		  return r.snap_id;
	end loop;
end;
/

explain plan for
with snp as (select f_test() snap_id from dual)
select count(*) 
from dba_hist_snapshot a, snp b
where a.snap_id= b.snap_id;

Plan hash value: 1583531653

select * from table(dbms_xplan.display);

-------------------------------------------------------------------------------------
| Id  | Operation           | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |               |     1 |     7 |   113   (8)| 00:00:01 |
|   1 |  SORT AGGREGATE     |               |     1 |     7 |            |          |
|   2 |   NESTED LOOPS      |               |     4 |    28 |   113   (8)| 00:00:01 |
|   3 |    FAST DUAL        |               |     1 |       |     2   (0)| 00:00:01 |
|*  4 |    TABLE ACCESS FULL| WRM$_SNAPSHOT |     4 |    28 |   111   (9)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - filter("SNAP_ID"="F_TEST"() AND "STATUS"=0)

This is not efficient, because the function will execute once per very row in the wrm$_snapshot table. An easy way to prevent this is to add a materialize hint to the CTE.


explain plan for
with snp as (select /*+ materialize */ f_test() snap_id from dual)
select count(*) 
from dba_hist_snapshot a, snp b
where a.snap_id= b.snap_id;

select * from table(dbms_xplan.display);

----------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                        | Rows  | Bytes | Cost (%CPU)| Time  |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                             |     1 |    20 |   108   (2)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION |                             |       |       |            |       |
|   2 |   LOAD AS SELECT           |                             |       |       |            |       |
|   3 |    FAST DUAL               |                             |     1 |       |     2   (0)| 00:00:01 |
|   4 |   SORT AGGREGATE           |                             |     1 |    20 |            |       |
|*  5 |    HASH JOIN               |                             |     4 |    80 |   106   (2)| 00:00:01 |
|   6 |     VIEW                   |                             |     1 |    13 |     2   (0)| 00:00:01 |
|   7 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D7979_73A6CAFD |     1 |    13 |     2   (0)| 00:00:01 |
|*  8 |     TABLE ACCESS FULL      | WRM$_SNAPSHOT               | 16314 |   111K|   103   (1)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("SNAP_ID"="B"."SNAP_ID")
   8 - filter("STATUS"=0)

With materialize hint, the function will be executed only once. The problem is – I don’t have access to the source code. So the only option for me is to use SQL profile.

I took the outline data resulting from the query with materialize hint, created a SQL profile. However, the plan generated by SQL profile looks different from the one generated with materialize hint. The code to generate SQL profile is too big, so giving below a ‘shortcut’ by using outline data as a hint.


select * from table(dbms_xplan.display(null, null, 'advanced'));

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      FULL(@"SEL$D67CB2D2" "T1"@"SEL$D67CB2D2")
      USE_HASH(@"SEL$335DD26A" "WRM$_SNAPSHOT"@"SEL$3")
      LEADING(@"SEL$335DD26A" "B"@"SEL$2" "WRM$_SNAPSHOT"@"SEL$3")
      FULL(@"SEL$335DD26A" "WRM$_SNAPSHOT"@"SEL$3")
      NO_ACCESS(@"SEL$335DD26A" "B"@"SEL$2")
      OUTLINE(@"SEL$3")
      OUTLINE(@"SEL$2")
      OUTLINE(@"SEL$1")
      MERGE(@"SEL$3")
      OUTLINE_LEAF(@"SEL$335DD26A")
      OUTLINE_LEAF(@"SEL$D67CB2D2")
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPT_PARAM('_gby_hash_aggregation_enabled' 'false')
      OPT_PARAM('optimizer_dynamic_sampling' 4)
      OPTIMIZER_FEATURES_ENABLE('10.2.0.5')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */

explain plan for
with snp as (select f_test() snap_id from dual)
select
  /*+ FULL(@"SEL$D67CB2D2" "T1"@"SEL$D67CB2D2")
      USE_HASH(@"SEL$335DD26A" "WRM$_SNAPSHOT"@"SEL$3")
      LEADING(@"SEL$335DD26A" "B"@"SEL$2" "WRM$_SNAPSHOT"@"SEL$3")
      FULL(@"SEL$335DD26A" "WRM$_SNAPSHOT"@"SEL$3")
      NO_ACCESS(@"SEL$335DD26A" "B"@"SEL$2")
      OUTLINE(@"SEL$3")
      OUTLINE(@"SEL$2")
      OUTLINE(@"SEL$1")
      MERGE(@"SEL$3")
      OUTLINE_LEAF(@"SEL$335DD26A")
      OUTLINE_LEAF(@"SEL$D67CB2D2")
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPT_PARAM('_gby_hash_aggregation_enabled' 'false')
      OPT_PARAM('optimizer_dynamic_sampling' 4)
      OPTIMIZER_FEATURES_ENABLE('10.2.0.5')
      IGNORE_OPTIM_EMBEDDED_HINTS  */
count(*) 
from dba_hist_snapshot a, snp b
where a.snap_id= b.snap_id;	

select * from table(dbms_xplan.display);

------------------------------------------------------------------------------------------
| Id  | Operation            | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                   |     1 |    26 |   106   (2)| 00:00:01 |
|   1 |  SORT AGGREGATE      |                   |     1 |    26 |            |          |
|*  2 |   HASH JOIN          |                   |     4 |   104 |   106   (2)| 00:00:01 |
|   3 |    VIEW              |                   |     1 |    13 |     2   (0)| 00:00:01 |
|   4 |     FAST DUAL        |                   |     1 |       |     2   (0)| 00:00:01 |
|   5 |    VIEW              | DBA_HIST_SNAPSHOT | 16314 |   207K|   103   (1)| 00:00:01 |
|*  6 |     TABLE ACCESS FULL| WRM$_SNAPSHOT     | 16314 |   111K|   103   (1)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("A"."SNAP_ID"="B"."SNAP_ID")
   6 - filter("STATUS"=0)

The plan generated by SQL profile is not much different from above:

-------------------------------
SQL_ID  8vncgw5ygpx1b, child number 1
-------------------------------------
with snp as (select f_test() snap_id from dual) select count(*) from
dba_hist_snapshot a, snp b where a.snap_id= b.snap_id

Plan hash value: 1587178679

-------------------------------------------------------------------------------------
| Id  | Operation           | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |               |       |       |   106 (100)|          |
|   1 |  SORT AGGREGATE     |               |     1 |    20 |            |          |
|*  2 |   HASH JOIN         |               |     4 |    80 |   106   (2)| 00:00:01 |
|   3 |    VIEW             |               |     1 |    13 |     2   (0)| 00:00:01 |
|   4 |     FAST DUAL       |               |     1 |       |     2   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS FULL| WRM$_SNAPSHOT | 16314 |   111K|   103   (1)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("SNAP_ID"="B"."SNAP_ID")
   5 - filter("STATUS"=0)

Note
-----
   - SQL profile "Test_Prof" used for this statement

In the latter two plan, it is using a HASH JOIN instead of NL, so I believe it will execute the function only once. But why does it not create a temp table, as it does with materialize hint? Is there any way to force this?

Many thanks.

]]> By: Log Buffer #273, A Carnival of the Vanities for DBAs | The Pythian Blog http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46619 Fri, 25 May 2012 09:31:45 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46619 [...] Jonathan Lewis blogs about subquery factoring. [...]

]]> By: lkafle http://jonathanlewis.wordpress.com/2012/05/24/subquery-factoring-7/#comment-46616 Fri, 25 May 2012 03:57:58 +0000 http://jonathanlewis.wordpress.com/?p=8937#comment-46616 Reblogged this on lava kafle kathmandu nepal.

]]>