Oracle SQL Explain Plan | January 23, 2008 10:22:36 PM IST | |||
Version: Oracle 10.2.0.2.0 | |
Database: AVSEDWP | |
Schema: SYS | |
Date: Jan 23, 2008 12:00:00 AM |
|
COST ALL ROWS (optimizer: CHOOSE) |
1,334 |
Step # | Step Name |
---|
27 | SELECT STATEMENT |
26 | PX COORDINATOR |
25 | SYS.:TQ10005 PX SEND [QC (RANDOM)] |
24 | SORT [GROUP BY] |
23 | PX RECEIVE |
22 | SYS.:TQ10004 PX SEND [HASH] |
21 | HASH JOIN [BUFFERED] |
4 | BUFFER [SORT] |
3 | PX RECEIVE |
2 | SYS.:TQ10001 PX SEND [HASH] |
1 | EISUSER.EIS_DISTRIBUTION_CHANNEL TABLE ACCESS [FULL] |
20 | PX RECEIVE |
19 | SYS.:TQ10003 PX SEND [HASH] |
18 | HASH JOIN |
8 | PX RECEIVE |
7 | SYS.:TQ10002 PX SEND [HASH] |
6 | PX BLOCK [ITERATOR] |
5 | EISUSER.EIS_TIME TABLE ACCESS [FULL] |
17 | BUFFER [SORT] |
16 | PX RECEIVE |
15 | SYS.:TQ10000 PX SEND [HASH] |
14 | EISUSER.EIS_FACT TABLE ACCESS [BY GLOBAL INDEX ROWID] |
13 | NESTED LOOPS |
11 | INLIST ITERATOR |
10 | EISUSER.EIS_LOC_CCRG TABLE ACCESS [BY INDEX ROWID] |
9 | EISUSER.EIS_LOC_RNT_LOC_MNEMONIC INDEX [RANGE SCAN] |
12 | EISUSER.EISFACT_DW_CO_LOC_ID_IX INDEX [RANGE SCAN] |
Step # | Description | Est. Cost | Est. Rows Returned | Est. KBytes Returned |
---|
1 | This plan step retrieves all rows from table EIS_DISTRIBUTION_CHANNEL. | 3 | 17 | 0.515 |
2 | This plan step has no supplementary description information. | 3 | 17 | 0.515 |
3 | This plan step has no supplementary description information. |
4 | This plan step sorts the buffer row source. | -- | -- | -- |
5 | This plan step retrieves all rows from table EIS_TIME. | 3 | 730 | 17.822 |
6 | This plan step has no supplementary description information. |
7 | This plan step has no supplementary description information. | 3 | 730 | 17.822 |
8 | This plan step has no supplementary description information. |
9 | This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index EIS_LOC_RNT_LOC_MNEMONIC. | 2 | 10 | -- |
10 | This plan step retrieves rows from table EIS_LOC_CCRG through ROWID(s) returned by an index. | 4 | 10 | 0.313 |
11 | This plan step loops through the query's IN list predicate, executing its child step for each value found. |
12 | This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index EISFACT_DW_CO_LOC_ID_IX. | 2 | 71,748 | -- |
13 | This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. | 1,327 | 553,497 | 43,241.953 |
14 | This plan step retrieves rows from table EIS_FACT through ROWID(s) returned by a global partitioned index. | 134 | 55,994 | 2,624.719 |
15 | This plan step has no supplementary description information. | 134 | 55,994 | 2,624.719 |
16 | This plan step has no supplementary description information. |
17 | This plan step sorts the buffer row source. | -- | -- | -- |
18 | This plan step accepts two sets of rows, each from a different table. A hash table is built using the rows returned by the first child. Each row returned by the second child is then used to probe the hash table to find row pairs which satisfy a condition specified in the query's WHERE clause. Note: The Oracle cost-based optimizer will build the hash table using what it thinks is the smaller of the two tables. It uses the statistics to determine which is smaller, so out of date statistics could cause the optimizer to make the wrong choice. | 1,330 | 317,153 | 32,520.571 |
19 | This plan step has no supplementary description information. | 1,330 | 317,153 | 32,520.571 |
20 | This plan step has no supplementary description information. |
21 | This plan step accepts two sets of rows, each from a different table. A hash table is built using the rows returned by the first child. Each row returned by the second child is then used to probe the hash table to find row pairs which satisfy a condition specified in the query's WHERE clause. Note: The Oracle cost-based optimizer will build the hash table using what it thinks is the smaller of the two tables. It uses the statistics to determine which is smaller, so out of date statistics could cause the optimizer to make the wrong choice. | 1,332 | 317,153 | 42,121.883 |
22 | This plan step has no supplementary description information. | 1,332 | 317,153 | 42,121.883 |
23 | This plan step has no supplementary description information. |
24 | This plan step accepts a set of rows from its child node, and sorts them into groups based on the columns specified in the query's GROUP BY clause. | 1,334 | 317,153 | 42,121.883 |
25 | This plan step has no supplementary description information. | 1,334 | 317,153 | 42,121.883 |
26 | This plan step has no supplementary description information. |
27 | This plan step designates this statement as a SELECT statement. | 1,334 | 317,153 | 42,121.883 |