Comments on: Parallel Parking – What is causing the Query to be Executed in Parallel?

By: Mustafa KALAYCI

Mustafa KALAYCI — Thu, 16 Aug 2012 20:37:00 +0000

Hi Charles,

I finally got 10053 trace. here it is: http://yadi.sk/d/bwlTsyMpEYpz you can download it.

I did not worked much with 10053 trace so it is a bit hard to understand to me. I would be appreciate if you look at it too. also added to OTN forum:

https://forums.oracle.com/forums/thread.jspa?threadID=2420587&tstart=15&start=30

and as I mentioned in forum, I realized something that may be related to that subject. when I query V$DB_OBJECT_CACHE, I saw that, HAREKET_TABLE and all of it’s indexes are seems as “MULTI-VERSIONED OBJECT”

select * from V$DB_OBJECT_CACHE where type = ‘MULTI-VERSIONED OBJECT’ and owner = ‘SG’;

NAME NAMESPACE TYPE STATUS
I_NEW_HAREKET_1 MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
NEW_HAREKET81_NDX MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
NEW_HAREKET_NDX MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
NEW_TARIK_NDX MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
NEW_HAREKET_MAHEKOL_NDX MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
NEW_HAREKET6_NDX MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
NEW_HAREKET_POLICE_NDX MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
I_NEW_HAREKET_2 MULTI-VERSION OBJECT FOR INDEX MULTI-VERSIONED OBJECT VALID
HAREKET_TABLE MULTI-VERSION OBJECT FOR TABLE MULTI-VERSIONED OBJECT VALID

By: Charles Hooper

Charles Hooper — Fri, 10 Aug 2012 10:20:17 +0000

Dominic,

Thank you for the documentation reference. The behavior is spelled out quite clearly in the documentation… I was not expecting to see that clarification on the topic in the documentation.

By: Dom Brooks

Dom Brooks — Fri, 10 Aug 2012 07:47:02 +0000

Coming to this thread a bit late – the 1048575 is the max number of interval partitions as you guys have stated so yes, it’s expected behaviour.

To back this up with the documentation:
http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_avail.htm#BABEGHBB

“An execution plan with a full table scan on an interval-partitioned table shows 1 for PSTART, and 1048575 for PSTOP, regardless of how many interval partitions were created.”

By: Tony Sleight

Tony Sleight — Thu, 02 Aug 2012 13:23:20 +0000

Thanks Charles, that explains quite a lot. I think that with interval partitioning, Oracle does not know how many partitions will be created as it is a dynamic value dependent upon the inserts to the table and so the maximum allowed value is chosen. However, in your second example with fixed partitions, 7 were generated and that was fixed in stone for the pstop max value.

By: Charles Hooper

Charles Hooper — Thu, 02 Aug 2012 12:34:38 +0000

Tony, Good to see that you took an interest in the test case. I was also curious about the Pstop value displayed in the execution plan. A quick check suggests that I have 101 partitions, one without a segment:

COLUMN TABLE_NAME FORMAT A10
COLUMN PARTITION_NAME FORMAT A10
 
SELECT
  TABLE_NAME,
  PARTITION_NAME,
  HIGH_VALUE,
  INTERVAL,
  SEGMENT_CREATED
FROM
  USER_TAB_PARTITIONS
WHERE
  TABLE_NAME='T1'
ORDER BY
  PARTITION_NAME;
 
TABLE_NAME PARTITION_ HIGH_VALUE                                                                       INT SEG
---------- ---------- -------------------------------------------------------------------------------- --- ---
T1         P0         TO_DATE(' 2007-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA NO  NO
T1         SYS_P341   TO_DATE(' 2012-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P342   TO_DATE(' 2012-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P343   TO_DATE(' 2012-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P344   TO_DATE(' 2012-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P345   TO_DATE(' 2012-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P346   TO_DATE(' 2013-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P347   TO_DATE(' 2013-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P348   TO_DATE(' 2013-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P349   TO_DATE(' 2013-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P350   TO_DATE(' 2013-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P351   TO_DATE(' 2013-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P352   TO_DATE(' 2013-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P353   TO_DATE(' 2013-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P354   TO_DATE(' 2013-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P355   TO_DATE(' 2013-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P356   TO_DATE(' 2013-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P357   TO_DATE(' 2013-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P358   TO_DATE(' 2014-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P359   TO_DATE(' 2014-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P360   TO_DATE(' 2014-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P361   TO_DATE(' 2014-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P362   TO_DATE(' 2014-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P363   TO_DATE(' 2014-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P364   TO_DATE(' 2014-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P365   TO_DATE(' 2014-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P366   TO_DATE(' 2014-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P367   TO_DATE(' 2014-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P368   TO_DATE(' 2014-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P369   TO_DATE(' 2014-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P370   TO_DATE(' 2015-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P371   TO_DATE(' 2015-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P372   TO_DATE(' 2015-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P373   TO_DATE(' 2015-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P374   TO_DATE(' 2015-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P375   TO_DATE(' 2015-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P376   TO_DATE(' 2015-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P377   TO_DATE(' 2015-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P378   TO_DATE(' 2015-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P379   TO_DATE(' 2015-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P380   TO_DATE(' 2015-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P381   TO_DATE(' 2015-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P382   TO_DATE(' 2016-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P383   TO_DATE(' 2016-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P384   TO_DATE(' 2016-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P385   TO_DATE(' 2016-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P386   TO_DATE(' 2016-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P387   TO_DATE(' 2016-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P388   TO_DATE(' 2016-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P389   TO_DATE(' 2016-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P390   TO_DATE(' 2016-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P391   TO_DATE(' 2016-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P392   TO_DATE(' 2016-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P393   TO_DATE(' 2016-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P394   TO_DATE(' 2017-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P395   TO_DATE(' 2017-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P396   TO_DATE(' 2017-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P397   TO_DATE(' 2017-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P398   TO_DATE(' 2017-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P399   TO_DATE(' 2017-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P400   TO_DATE(' 2017-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P401   TO_DATE(' 2017-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P402   TO_DATE(' 2017-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P403   TO_DATE(' 2017-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P404   TO_DATE(' 2017-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P405   TO_DATE(' 2017-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P406   TO_DATE(' 2018-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P407   TO_DATE(' 2018-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P408   TO_DATE(' 2018-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P409   TO_DATE(' 2018-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P410   TO_DATE(' 2018-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P411   TO_DATE(' 2018-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P412   TO_DATE(' 2018-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P413   TO_DATE(' 2018-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P414   TO_DATE(' 2018-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P415   TO_DATE(' 2018-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P416   TO_DATE(' 2018-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P417   TO_DATE(' 2018-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P418   TO_DATE(' 2019-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P419   TO_DATE(' 2019-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P420   TO_DATE(' 2019-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P421   TO_DATE(' 2019-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P422   TO_DATE(' 2019-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P423   TO_DATE(' 2019-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P424   TO_DATE(' 2019-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P425   TO_DATE(' 2019-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P426   TO_DATE(' 2019-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P427   TO_DATE(' 2019-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P428   TO_DATE(' 2019-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P429   TO_DATE(' 2019-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P430   TO_DATE(' 2020-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P431   TO_DATE(' 2020-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P432   TO_DATE(' 2020-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P433   TO_DATE(' 2020-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P434   TO_DATE(' 2020-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P435   TO_DATE(' 2020-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P436   TO_DATE(' 2020-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P437   TO_DATE(' 2020-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P438   TO_DATE(' 2020-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P439   TO_DATE(' 2020-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
T1         SYS_P440   TO_DATE(' 2020-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA YES YES
  
101 rows selected.

Where is the Pstop number 1048575 coming from? Let's try flushing the shared pool and executing a test script with a 10053 trace enabled:

ALTER SYSTEM FLUSH SHARED_POOL;
 
ALTER SESSION SET TRACEFILE_IDENTIFIER='TESTING10053'; 
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
 
ALTER SESSION SET PARALLEL_DEGREE_POLICY=AUTO;
 
SELECT
  COUNT(*)
FROM
  T1;
 
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';

I did not see in the 10053 trace where the optimizer determined the number of partitions in the table T1. The plan from the 10053 trace file:

============
Plan Table
============
------------------------------------------+-----------------------------------+-------------------------+----------------+
| Id  | Operation               | Name    | Rows  | Bytes | Cost  | Time      |  TQ  |IN-OUT|PQ Distrib | Pstart| Pstop  |
------------------------------------------+-----------------------------------+-------------------------+----------------+
| 0   | SELECT STATEMENT        |         |       |       |   32K |           |      |      |           |       |        |
| 1   |  SORT AGGREGATE         |         |     1 |       |       |           |      |      |           |       |        |
| 2   |   PX COORDINATOR        |         |       |       |       |           |      |      |           |       |        |
| 3   |    PX SEND QC (RANDOM)  | :TQ10000|     1 |       |       |           |:Q1000| P->S |QC (RANDOM)|       |        |
| 4   |     SORT AGGREGATE      |         |     1 |       |       |           |:Q1000| PCWP |           |       |        |
| 5   |      PX BLOCK ITERATOR  |         |   95M |       |   32K |  00:01:07 |:Q1000| PCWC |           | 1     | 1048575|
| 6   |       TABLE ACCESS FULL | T1      |   95M |       |   32K |  00:01:07 |:Q1000| PCWP |           | 1     | 1048575|
------------------------------------------+-----------------------------------+-------------------------+----------------+
Predicate Information:
----------------------
6 - access(:Z>=:Z AND :Z<=:Z)
 
Content of other_xml column
===========================
nodeid/pflags: 6 17nodeid/pflags: 5 17  dop_op_reason  : scan of object TESTUSER.T1
  dop            : 2
  px_in_memory   : no
  db_version     : 11.2.0.3
  parse_schema   : TESTUSER
  plan_hash      : 974985148
  plan_hash_2    : 876471417
  Outline Data:
  /*+
    BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
      DB_VERSION('11.2.0.3')
      OPT_PARAM('optimizer_dynamic_sampling' 5)
      ALL_ROWS
      SHARED(2)
      OUTLINE_LEAF(@"SEL$1")
      FULL(@"SEL$1" "T1"@"SEL$1")
    END_OUTLINE_DATA
  */

Notice in the above that the Pstop value is 1048575, which is 2^20 - 1, that number might be important (see additional test below). Here is the section where the optimizer decided to re-cost for a parallel degree of 2:

kkeCostToTime: using io calibrate stats 
 maxmbps=0(MB/s) maxpmbps=200(MB/s) 
 block_size=8192 mb_io_count=13 mb_io_size=104858 (bytes) 
 tot_io_size=5980(MB) time=29899(ms)

AUTO DOP PLANS EVALUATION
***************************************
Compilation completed with Dop: 1.
  Cost_io:  58844.00  Cost_cpu: 20348604814.96
  Card:     1.00  Bytes:    0.00
  Cost:     59798.80  Est_time:  29899ms
kkopqCombineDop: Dop:2 Hint:no 
Query: compute:yes forced:no  computedDop:2 forceDop:0
Serial plan is expensive enough to be a candidate for parallelism (59799)
Signal reparse with DOP 2.
*****************************
Number of Compilations tried: 1
*****************************

Later in the trace file, we find the following block of text. The cost calculations appears to be consistent for a degree of parallel of 2:

Final cost for query block SEL$1 (#0) - All Rows Plan:
  Best join order: 1
  Cost: 33081.7322  Degree: 2  Card: 99899001.0000  Bytes: 0
  Resc: 59547.1180  Resc_io: 58844.0000  Resc_cpu: 14984850150
  Resp: 33081.7322  Resp_io: 32691.1111  Resc_cpu: 8324916750

A little further into the 10053 trace file we find the following block of text. Notice the calculated CPU cost of 20348604815 for the parallel degree (dop) of 1 - that number appears to be inconsistent with the Resc_cpu value (14984850150) above - I wonder if this is expected?

kkeCostToTime: using io calibrate stats 
 maxmbps=0(MB/s) maxpmbps=200(MB/s) 
 block_size=8192 mb_io_count=13 mb_io_size=104858 (bytes) 
 tot_io_size=3308(MB) time=16541(ms)

AUTO DOP PLANS EVALUATION
***************************************
Compilation completed with Dop: 2.
  Cost_io:  32691.11  Cost_cpu: 8324916750.00
  Card:     1.00  Bytes:    0.00
  Cost:     33081.73  Est_time:  16541ms
Comparing plan with dop=2 and plan with dop=1:
  dop=2 io=32691.11 cpu=8324916750 cost=33081.73 card=1 bytes=0 -> est=16541ms, scaled cost=33081.73
  dop=1 io=58844.00 cpu=20348604815 cost=59798.80 card=1 bytes=0 -> est=29899ms, scaled cost=59798.80
Plan with dop 2 is better. Scalability: 50
Current plan with dop=2 is better than best plan with dop=1
Costing completed. DOP chosen: 2.
AutoDop: kkopqSetMaxDopInCursorEnv:In the Cursor Session Env, max DOP is set to 16
*****************************
Number of Compilations tried: 2
*****************************
 
kkeCostToTime: using io calibrate stats 
 maxmbps=0(MB/s) maxpmbps=200(MB/s) 
 block_size=8192 mb_io_count=1 mb_io_size=8192 (bytes) 
 tot_io_size=258(MB) time=1292(ms)
kkeCostToTime: using io calibrate stats 
 maxmbps=0(MB/s) maxpmbps=200(MB/s) 
 block_size=8192 mb_io_count=1 mb_io_size=8192 (bytes) 
 tot_io_size=258(MB) time=1292(ms)
kkeCostToTime: using io calibrate stats 
 maxmbps=0(MB/s) maxpmbps=200(MB/s) 
 block_size=8192 mb_io_count=1 mb_io_size=8192 (bytes) 
 tot_io_size=258(MB) time=1292(ms)
kkeCostToTime: using io calibrate stats 
 maxmbps=0(MB/s) maxpmbps=200(MB/s) 
 block_size=8192 mb_io_count=1 mb_io_size=8192 (bytes) 
 tot_io_size=258(MB) time=1292(ms)

Another test using a much smaller dataset of 10 rows:

DROP TABLE T2 PURGE;
 
CREATE TABLE T2 (
  C1 NUMBER,
  C2 VARCHAR2(10),
  C3 DATE,
  C4 VARCHAR2(20))
  PARTITION BY RANGE(C3)
  INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
  ( PARTITION p0 VALUES LESS THAN (TO_DATE('1-1-2007', 'DD-MM-YYYY')));
 
INSERT INTO
  T2
SELECT
  ROWNUM,
  RPAD(ROWNUM,10,'A'),
  TRUNC(SYSDATE)+MOD(ROWNUM-1,3000),
  RPAD('A',20,'A')
FROM
  (SELECT
    1 C1
  FROM
    DUAL
  CONNECT BY
    LEVEL<=10);
 
COMMIT;
 
SELECT
  COUNT(*)
FROM
  T2;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'TYPICAL +OUTLINE'));
 
SQL_ID  dp4dnf1mug84c, child number 0
-------------------------------------
SELECT   COUNT(*) FROM   T2

Plan hash value: 611317447
 
-------------------------------------------------------------------------------------
| Id  | Operation            | Name | Rows  | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |      |       |     5 (100)|          |       |       |
|   1 |  SORT AGGREGATE      |      |     1 |            |          |       |       |
|   2 |   PARTITION RANGE ALL|      |    10 |     5   (0)| 00:00:01 |     1 |1048575|
|   3 |    TABLE ACCESS FULL | T2   |    10 |     5   (0)| 00:00:01 |     1 |1048575|
-------------------------------------------------------------------------------------
 
Outline Data
-------------
  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
      DB_VERSION('11.2.0.3')
      ALL_ROWS
      NO_PARALLEL
      OUTLINE_LEAF(@"SEL$1")
      FULL(@"SEL$1" "T2"@"SEL$1")
      END_OUTLINE_DATA
  */

Note
-----
   - dynamic sampling used for this statement (level=2)
   - automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold

The above plan, with just 10 rows, also shows a Pstop value of 1048575. Let's dig through the 11.2 documentation to find the page with the database limits listed: http://docs.oracle.com/cd/E11882_01/server.112/e24448/limits003.htm

"Maximum number of partitions allowed per table or index 1024K - 1"

Pstop value is 1048575, which is 2^20 - 1, which is also 1024 * 1024 - 1 (the documentation's "1024K - 1") Interesting? Let's try another test without interval partitioning:

DROP TABLE T3 PURGE;
 
CREATE TABLE T3 (
  C1 NUMBER,
  C2 VARCHAR2(10),
  C3 DATE,
  C4 VARCHAR2(20))
  PARTITION BY RANGE(C3)
  (
   PARTITION p0 VALUES LESS THAN (TO_DATE('1-1-2007', 'DD-MM-YYYY')),
   PARTITION SYS_P341 VALUES LESS THAN (TO_DATE('1-8-2012', 'DD-MM-YYYY')),
   PARTITION SYS_P342 VALUES LESS THAN (TO_DATE('1-9-2012', 'DD-MM-YYYY')),
   PARTITION SYS_P343 VALUES LESS THAN (TO_DATE('1-10-2012', 'DD-MM-YYYY')),
   PARTITION SYS_P344 VALUES LESS THAN (TO_DATE('1-11-2012', 'DD-MM-YYYY')),
   PARTITION SYS_P345 VALUES LESS THAN (TO_DATE('1-12-2012', 'DD-MM-YYYY')),
   PARTITION SYS_P346 VALUES LESS THAN (TO_DATE('1-1-2013', 'DD-MM-YYYY'))
);
 
INSERT INTO
  T3
SELECT
  ROWNUM,
  RPAD(ROWNUM,10,'A'),
  TRUNC(SYSDATE)+MOD(ROWNUM-1,3000),
  RPAD('A',20,'A')
FROM
  (SELECT
    1 C1
  FROM
    DUAL
  CONNECT BY
    LEVEL<=10);
 
COMMIT;
 
SELECT
  COUNT(*)
FROM
  T3;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'TYPICAL +OUTLINE'));
 
SQL_ID  c4tq02u8za731, child number 0
-------------------------------------
SELECT   COUNT(*) FROM   T3
 
Plan hash value: 2024532151
 
-------------------------------------------------------------------------------------
| Id  | Operation            | Name | Rows  | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |      |       |     5 (100)|          |       |       |
|   1 |  SORT AGGREGATE      |      |     1 |            |          |       |       |
|   2 |   PARTITION RANGE ALL|      |    10 |     5   (0)| 00:00:01 |     1 |     7 |
|   3 |    TABLE ACCESS FULL | T3   |    10 |     5   (0)| 00:00:01 |     1 |     7 |
------------------------------------------------------------------------------------- 
 
Outline Data
-------------
  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
      DB_VERSION('11.2.0.3')
      ALL_ROWS
      NO_PARALLEL
      OUTLINE_LEAF(@"SEL$1")
      FULL(@"SEL$1" "T3"@"SEL$1")
      END_OUTLINE_DATA
  */
 
Note
-----
   - dynamic sampling used for this statement (level=2)
   - automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold

Notice in the above that the Pstop value is 7, not 1048575 as we saw with interval partitioning. Perhaps this is expected behavior? (Edit: Aug 2, 2012, roughly 5 minutes after the comment was posted: the initial insert into table T3 failed - the insert statement had the HTML code for the less than (<) sign rather than the actual less than sign and I did not catch that error before posting the execution plan.)

By: Tony Sleight

Tony Sleight — Thu, 02 Aug 2012 12:31:37 +0000

I see, that leaves me clean out of new suggestions! Certainly the 10053 would show how the execution plan was reached.

From your post, I gather you are wishing to ensure parallel queries are not executed on your system? If so, the drastic way to ensure that would be to delete the existing record in RESOURCE_IO_CALIBRATE$.

By: Mustafa Kalayci

Mustafa Kalayci — Thu, 02 Aug 2012 12:23:52 +0000

Tony,

PARALLEL_DEGREE_POLICY has been set to MANUAL for all sessions and db but query still can run parallel. I will get 10053 and 10046 traces and look for the results

By: Charles Hooper

Charles Hooper — Thu, 02 Aug 2012 10:52:13 +0000

Mustafa, Great that you found this blog article. The problem that you descriibed in the OTN thread is an interesting one, and I think that Tony Sleight has provided a couple of interesting possibilities to investigate. First, how up to date are the statistics for the HAREKET_TABLE table (keep in mind that unless NO_INVALIDATE=>FALSE is specified when collecting the statistics, there could be a roughly 5 hour delay before the new statistics will result in a hard parse of a previously hard parsed SQL statement). Let's investigate Tony's suggestion that PARALLEL_DEGREE_POLICY may have been adjusted at the session level, possibly by the tool that executed the SQL statement. There are three views that might prove to be very useful in determining what is happening. As most readers of this blog likely know, the DESC command will list the columns and datatypes found in views and tables:

DESC V$SES_OPTIMIZER_ENV
 
DESC V$SQL_OPTIMIZER_ENV
 
DESC V$SYS_OPTIMIZER_ENV

A Google search may be used to find the description of any of these views: V$SES_OPTIMIZER_ENV 112 site:docs.oracle.com The first result is this page: If we go back to my example, I still have a test session connected to the database. I need the SID of that session (as you very likely know, you can use V$SESSION to determine the SID of another session, but I will use V$MYSTAT since this is my SQL*Plus session):

SELECT
  SID
FROM
  V$MYSTAT
WHERE
  ROWNUM=1;
 
       SID
----------
        96

Let's take a look at the (majority of the) optimizer parameters for the session that affect the decisions made by the Oracle query optimizer (note that I have an arrow pointing at one of the rows):

SELECT
  NAME,
  ISDEFAULT,
  VALUE
FROM
  V$SES_OPTIMIZER_ENV
WHERE
  SID=96
ORDER BY
  NAME;
 
NAME                                     ISD VALUE
---------------------------------------- --- -------------
_parallel_cluster_cache_policy           NO  cached
_pga_max_size                            NO  409600 KB
active_instance_count                    YES 1
bitmap_merge_area_size                   YES 1048576
cell_offload_compaction                  YES ADAPTIVE
cell_offload_plan_display                YES AUTO
cell_offload_processing                  YES true
cpu_count                                YES 8
cursor_sharing                           YES exact
db_file_multiblock_read_count            YES 128
deferred_segment_creation                YES true
dst_upgrade_insert_conv                  YES true
hash_area_size                           YES 131072
is_recur_flags                           YES 0
optimizer_capture_sql_plan_baselines     YES false
optimizer_dynamic_sampling               YES 2
optimizer_features_enable                YES 11.2.0.3
optimizer_index_caching                  YES 0
optimizer_index_cost_adj                 YES 100
optimizer_mode                           YES all_rows
optimizer_secure_view_merging            YES true
optimizer_use_invisible_indexes          YES false
optimizer_use_pending_statistics         YES false
optimizer_use_sql_plan_baselines         YES true
parallel_autodop                         YES 0
parallel_ddl_mode                        YES enabled
parallel_ddldml                          YES 0
parallel_degree                          YES 0
parallel_degree_limit                    YES 65535
parallel_degree_policy                   NO  auto           {---- here
parallel_dml_mode                        YES disabled
parallel_execution_enabled               YES true
parallel_force_local                     YES false
parallel_max_degree                      YES 16
parallel_min_time_threshold              YES 10
parallel_query_default_dop               YES 0
parallel_query_mode                      YES enabled
parallel_threads_per_cpu                 YES 2
pga_aggregate_target                     YES 2048000 KB
query_rewrite_enabled                    YES true
query_rewrite_integrity                  YES enforced
result_cache_mode                        YES MANUAL
skip_unusable_indexes                    YES true
sort_area_retained_size                  YES 0
sort_area_size                           YES 65536
star_transformation_enabled              YES false
statistics_level                         YES typical
total_cpu_count                          YES 8
total_processor_group_count              YES 1
transaction_isolation_level              YES read_commited
workarea_size_policy                     YES auto

In the above, we are able to see that the PARALLEL_DEGREE_POLICY for the session was adjusted to AUTO from the default parameter value that was in place when the database was brought online. We are also able to see the parameters that were in effect when a SQL statement was optimized. In the above test case examples, there were two child cursors for SQL_ID 5bc0v4my7dvr5, one with the default value for the PARALLEL_DEGREE_POLICY parameter and one with the value of AUTO for that parameter. Let's examine the optimizer parameters for this SQL_ID (again with an arrow pointing to the two rows that are of interest):

SELECT
  CHILD_NUMBER,
  NAME,
  ISDEFAULT,
  VALUE
FROM
  V$SQL_OPTIMIZER_ENV
WHERE
  SQL_ID='5bc0v4my7dvr5'
ORDER BY
  CHILD_NUMBER,
  NAME;
  
CHILD_NUMBER NAME                                     ISD VALUE
------------ ---------------------------------------- --- -------------
           0 _pga_max_size                            NO  409600 KB
           0 active_instance_count                    YES 1
           0 bitmap_merge_area_size                   YES 1048576
           0 cell_offload_compaction                  YES ADAPTIVE
           0 cell_offload_plan_display                YES AUTO
           0 cell_offload_processing                  YES true
           0 cpu_count                                YES 8
           0 cursor_sharing                           YES exact
           0 db_file_multiblock_read_count            YES 128
           0 deferred_segment_creation                YES true
           0 dst_upgrade_insert_conv                  YES true
           0 hash_area_size                           YES 131072
           0 is_recur_flags                           YES 0
           0 optimizer_capture_sql_plan_baselines     YES false
           0 optimizer_dynamic_sampling               YES 2
           0 optimizer_features_enable                YES 11.2.0.3
           0 optimizer_index_caching                  YES 0
           0 optimizer_index_cost_adj                 YES 100
           0 optimizer_mode                           YES all_rows
           0 optimizer_secure_view_merging            YES true
           0 optimizer_use_invisible_indexes          YES false
           0 optimizer_use_pending_statistics         YES false
           0 optimizer_use_sql_plan_baselines         YES true
           0 parallel_autodop                         YES 0
           0 parallel_ddl_mode                        YES enabled
           0 parallel_ddldml                          YES 0
           0 parallel_degree                          YES 0
           0 parallel_degree_limit                    YES 65535
           0 parallel_degree_policy                   YES manual           {---- here
           0 parallel_dml_mode                        YES disabled
           0 parallel_execution_enabled               YES true
           0 parallel_force_local                     YES false
           0 parallel_max_degree                      YES 16
           0 parallel_min_time_threshold              YES 10
           0 parallel_query_default_dop               YES 0
           0 parallel_query_mode                      YES enabled
           0 parallel_threads_per_cpu                 YES 2
           0 pga_aggregate_target                     YES 2048000 KB
           0 query_rewrite_enabled                    YES true
           0 query_rewrite_integrity                  YES enforced
           0 result_cache_mode                        YES MANUAL
           0 skip_unusable_indexes                    YES true
           0 sort_area_retained_size                  YES 0
           0 sort_area_size                           YES 65536
           0 star_transformation_enabled              YES false
           0 statistics_level                         YES typical
           0 total_cpu_count                          YES 8
           0 total_processor_group_count              YES 1
           0 transaction_isolation_level              YES read_commited
           0 workarea_size_policy                     YES auto
           2 _parallel_cluster_cache_policy           NO  cached
           2 _pga_max_size                            NO  409600 KB
           2 active_instance_count                    YES 1
           2 bitmap_merge_area_size                   YES 1048576
           2 cell_offload_compaction                  YES ADAPTIVE
           2 cell_offload_plan_display                YES AUTO
           2 cell_offload_processing                  YES true
           2 cpu_count                                YES 8
           2 cursor_sharing                           YES exact
           2 db_file_multiblock_read_count            YES 128
           2 deferred_segment_creation                YES true
           2 dst_upgrade_insert_conv                  YES true
           2 hash_area_size                           YES 131072
           2 is_recur_flags                           YES 0
           2 optimizer_capture_sql_plan_baselines     YES false
           2 optimizer_dynamic_sampling               YES 2
           2 optimizer_features_enable                YES 11.2.0.3
           2 optimizer_index_caching                  YES 0
           2 optimizer_index_cost_adj                 YES 100
           2 optimizer_mode                           YES all_rows
           2 optimizer_secure_view_merging            YES true
           2 optimizer_use_invisible_indexes          YES false
           2 optimizer_use_pending_statistics         YES false
           2 optimizer_use_sql_plan_baselines         YES true
           2 parallel_autodop                         NO  1
           2 parallel_ddl_mode                        YES enabled
           2 parallel_ddldml                          YES 0
           2 parallel_degree                          NO  2
           2 parallel_degree_limit                    YES 65535
           2 parallel_degree_policy                   NO  auto           {---- here
           2 parallel_dml_mode                        YES disabled
           2 parallel_execution_enabled               YES true
           2 parallel_force_local                     YES false
           2 parallel_max_degree                      YES 16
           2 parallel_min_time_threshold              YES 10
           2 parallel_query_default_dop               NO  16
           2 parallel_query_mode                      YES enabled
           2 parallel_threads_per_cpu                 YES 2
           2 pga_aggregate_target                     YES 2048000 KB
           2 query_rewrite_enabled                    YES true
           2 query_rewrite_integrity                  YES enforced
           2 result_cache_mode                        YES MANUAL
           2 skip_unusable_indexes                    YES true
           2 sort_area_retained_size                  YES 0
           2 sort_area_size                           YES 65536
           2 star_transformation_enabled              YES false
           2 statistics_level                         YES typical
           2 total_cpu_count                          YES 8
           2 total_processor_group_count              YES 1
           2 transaction_isolation_level              YES read_commited
           2 workarea_size_policy                     YES auto

In the above, notice that the PARALLEL_DEGREE_POLICY parameter value is MANUAL for child cursor 0, and the ISDEFAULT value is YES. For child cursor 2, the values are AUTO and NO, respectively. You will need to determine the SQL_ID and possibly the CHILD_NUMBER for the SQL statement that is executed in TOAD (or PLSQL Developer) to try the query of V$SQL_OPTIMIZER_ENV.

By: Tony Sleight

Tony Sleight — Thu, 02 Aug 2012 07:15:20 +0000

Thanks Mustafa for a swift answer. As there is a record in RESOURCE_IO_CALIBRATE$ (created 28 March 2012), setting PARALLEL_DEGREE_POLICY on a session level to AUTO will enable parallel execution. Which is what Charles’ web post has shown.

I guess the procedure DBMS_RESOURCE_MANAGER.CALIBRATE_IO must have been executed for the table entry to be created as it is not the manual value suggested by Charles’ article.

By: Mustafa Kalayci

Mustafa Kalayci — Thu, 02 Aug 2012 06:58:11 +0000

Hi Tony, as OP, I can show what is in RESOURCE_IO_CALIBRATE$:

START_TIME                       END_TIME                         MAX_IOPS MAX_MBPS MAX_PMBPS LATENCY NUM_DISKS
28/03/2012 07.31.30.582060000 PM 28/03/2012 07.44.03.792624000 PM     1099      290       182       9       130