Difference explain plan "Select 1' and"Select column-name".

Hi all
I use Oracle 10.2.0.4.0. I have two queries that looks like below.

Select Count (a.id)
of a, b
where a.c1 = b.c1
and a.c1 = 'USD'
and b.c2 = 234
and rownum < = 1;

Select 1
of a, b
where a.c1 = b.c1
and a.c1 = 'USD'
and b.c2 = 234
and rownum < = 1;

Here 'id' corresponds to the primary key column and the index are all used in the join columns. so I expect the execution of the two queries above path should be the same. But I do not get the same result. There is a different set of indexes used in the two plans, and this resulted in a total elapsed time difference of ~ 15 minutes.

Can you please help me, why this is happening.

930254 wrote:
in my plan, I see "unique Index Scan" that is to say access a primary key for the query "Select 1'. But I'm getting slower than 15-minute result set that to use 'Select column_name', what must be the reason?

Again, I will have another one with different join tables which is just the opposite, I mean, using the ' Select count (1) "19 minutes 55 seconds have passed where using the" 1 Select ' equipped with 22 dry.»

To answer your question why you see this difference in performance: the 'rapid' plan uses a different index that allows access to a straight line through the index and does not require a visit to the table:

-----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                                |     1 |    27 |       | 15229   (6)| 00:01:18 |       |       |
|   1 |  SORT AGGREGATE                |                                |     1 |    27 |       |         |             |       |       |
|*  2 |   COUNT STOPKEY                |                                |       |       |       |         |             |       |       |
|*  3 |    HASH JOIN                   |                                |   252K|  6658K|  5920K| 15229   (6)| 00:01:18 |       |       |
|   4 |     TABLE ACCESS BY INDEX ROWID| POCACHELINEDISB                |   252K|  2959K|       | 12922   (4)| 00:01:07 |       |       |
|*  5 |      INDEX RANGE SCAN          | IDX_POLINEDISB_UOMCD           |   252K|       |       |   384  (18)| 00:00:02 |       |       |
|   6 |     PARTITION RANGE ALL        |                                |   368K|  5395K|       |  1519   (8)| 00:00:08 |     1 |    51 |
|   7 |      PARTITION HASH ALL        |                                |   368K|  5395K|       |  1519   (8)| 00:00:08 |     1 |     8 |
|*  8 |       INDEX RANGE SCAN         | IDX_PCHD_PAYPK_LASTD_STAT_POPK |   368K|  5395K|       |  1519   (8)| 00:00:08 |     1 |   408 |
-----------------------------------------------------------------------------------------------------------------------------------------

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

2 - filter(1>=ROWNUM)
3 - access("POCACHEHEADERDISB"."PO_PK"="POCACHELINEDISB"."PO_PK")
5 - access("POCACHELINEDISB"."UNITOFMEASURECD"='USD')
8 - access("POCACHEHEADERDISB"."PAYPK"=8135488395)

The disadvantage of this implementation plan is that the index is composed of 408 subpartitions all are to be visited.

The 'slow' plan uses a different index that is global, but you can only filter the corresponding lines after the visit of the table, so you could find yourself with a lot of lines that match on the PK, visit the row in the table only to discover that the line is not eligible. In addition to this, it could be that each iteration of this nested loop may have to visit a table row in another block to your table, as a result, many of these visits could really turn into physical i/o.

------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                 | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                      |     1 |    27 |     4   (0)| 00:00:01 |       |       |
|*  1 |  COUNT STOPKEY                        |                      |       |       |            |       |          |       |
|   2 |   NESTED LOOPS                        |                      |     2 |    54 |     4   (0)| 00:00:01 |       |       |
|   3 |    TABLE ACCESS BY INDEX ROWID        | POCACHELINEDISB      |   245K|  2877K|     2   (0)| 00:00:01 |       |       |
|*  4 |     INDEX RANGE SCAN                  | IDX_POLINEDISB_UOMCD |   252K|       |     2   (0)| 00:00:01 |       |       |
|   5 |    PARTITION HASH ITERATOR            |                      |     1 |    15 |     1   (0)| 00:00:01 |   KEY |   KEY |
|*  6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| POCACHEHEADERDISB    |     1 |    15 |     1   (0)| 00:00:01 | ROWID | ROWID |
|*  7 |      INDEX UNIQUE SCAN                | P_POCACHEHEADERDISB  |     1 |       |     1   (0)| 00:00:01 |   KEY |   KEY |
------------------------------------------------------------------------------------------------------------------------------

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

1 - filter(1>=ROWNUM)
4 - access("POCACHELINEDISB"."UNITOFMEASURECD"='USD')
6 - filter("POCACHEHEADERDISB"."PAYPK"=8135488395)
7 - access("POCACHEHEADERDISB"."PO_PK"="POCACHELINEDISB"."PO_PK")

This may explain the long-run: number of iterations to find a first row involving a lot of single random physical i/o block.

You could check by using DBMS_XPLAN. DISPLAY_CURSOR with the option "LAST ALLSTATS" and enabling statistical Rowsource, for example as shown here: http://oracle-randolf.blogspot.de/2011/12/extended-displaycursor-with-rowsource.html

It's probably an effect secondary different pricing when using optimization of the first K rows, as mentioned by Jonathan. It would be interesting to see the cost estimate if you forced the use of the index of the other for the approach of NL.

If you check the slow plans you see what approach they use - use access primary key because internal table could cause these runtimes very variable, depending on the speed at which the first line given in the table.

Hope this helps,
Randolf

Tags: Database

Similar Questions

How to export data to excel that has 2 tables with the same number of columns and the column names?

Hi everyone, yet once landed upward with a problem.
After trying many things to myself, finally decided to post here...
I created a form in form builder 6i in which clicking on a button, the data gets exported to the excel sheet.
It works very well with a single table. The problem now is that I cannot do the same with 2 tables.
Because the tables have the same number of columns and the columns names.
Here are the 2 tables with column names:
Table-1 (MONTHLY_PART_1) Table-2 (MONTHLY_PART_2)
SL_NO SL_NO
MODEL MODEL
END_DATE END_DATE
U-1 U-1
U-2 U-2
U-4 U-4
.......... ........
.......... ........
U-20 U-20
U-25 U-25
Given that the tables have the same column names, I get the following error :
402 error at line 103, column 4
required aliases in the SELECT list of the slider to avoid duplicate column names.
So how to export data to excel that has 2 tables with the same number of columns and the column names?
Should I paste the code? Should I publish this query in 'SQL and PL/SQL ' Forum?
Help me with this please.
Thank you.

Wait a second... is this a kind of House of partitioning? Shouldn't it is a union of two tables instead a join?

see you soon

Weird to explain plan structured multi-level XmlType column

Hello
spin an explanation on the follwing on 11.2.0.2 query:
```
SELECT
T1.EVENT_ID,
ACTION_SUB_ID,
PARAM_KEY,
PARAM_VALUE,
TO_DATE('2013-12-10', 'YYYY-MM-DD')
FROM  T_C_RMP_MNTRNG_XML_FULL_IL ,
  XMLTABLE('/monitoring' PASSING XML_CONTENT COLUMNS
  EVENT_ID VARCHAR2(4000) PATH 'eventId',
  ACTIONS XMLTYPE PATH 'action'
) T1,
  XMLTABLE('/action' PASSING T1.ACTIONS COLUMNS
  ACTION_SUB_ID NUMBER(10,0) PATH 'actionSubId',
  PARAMS xmltype PATH 'param'
) T2,
  XMLTABLE('/param' PASSING T2.params columns
  PARAM_KEY VARCHAR2(4000) PATH 'key',
  PARAM_VALUE VARCHAR2(1000) PATH 'value'
) T3
WHERE MESSAGE_ID = 4972102 ;
```
Even if MESSAGE_ID is the primary key of the T_C_RMP_MNTRNG_XML_FULL_IL and so there isn't that one record corresponding to the condition, I get a plan to explain with huge costs, 500 MB of data and a duration of 10 hours:

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------

Hash value of plan: 4011854835

--------------------------------------------------------------------------------------------------------

| ID | Operation | Name                  | Lines | Bytes | Cost (% CPU). Time |

--------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT |                       |   223KO |   489 M | 3111K (1) | 10:22:17 |

|   1. NESTED LOOPS |                       |       |       |            |          |

|   2.   NESTED LOOPS |                       |   223KO |   489 M | 3111K (1) | 10:22:17 |

|   3.    NESTED LOOPS |                       |   140K |    11 M | 1678 (1) | 00:00:21 |

|* 4 |     INDEX RANGE SCAN | X1B                   |     1.    53.     3 (0) | 00:00:01 |

|   5.     TABLE ACCESS BY INDEX ROWID | T_OR_MON_ACTION |   140K | 4542K | 1675 (1) | 00:00:21 |

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------

|* 6 |      INDEX RANGE SCAN | X3                    |   140K |       |     4 (25) | 00:00:01 |

|* 7 |    INDEX RANGE SCAN | X4G                   | 4083.       |    22 (0) | 00:00:01 |

|   8.   TABLE ACCESS BY INDEX ROWID | T_OR_MON_ACTION_PARAM |     2. 4428.    52 (0) | 00:00:01 |

--------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):

---------------------------------------------------

4 - access ("MESSAGE_ID" = 4972102)

6 - access("SYS_ALIAS_0".") NESTED_TABLE_ID "=" T_C_RMP_MNTRNG_XML_FULL_IL. " ("' SYS_NC0001200013$ ')

7 - access ("NESTED_TABLE_ID"= "SYS_ALIAS_0"." ("SYS_NC0000500006$")

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------

Note

-----

-dynamic sample used for this survey (level = 2)

When I run the query, the result comes back within 0.3 seconds.
Why is the plan to explain to the wide like that?
It's just the way it is, or is there something wrong here?

How did you finally to create the column 'XML_CONTENT' in the T_C_RMP_MNTRNG_XML_FULL_IL table / create the T_C_RMP_MNTRNG_XML_FULL_IL table?

That said, SQL * more explain the scheme, spends most of the time especially bananas when it comes with XMLTYPE and or objects which has no statistics created for them (dynamic sampling used for this survey (level = 2))

Using DBMS_XPLAN etc to get the 'real' values instead of "estimates".

https://blogs.Oracle.com/optimizer/entry/how_do_i_know_if

404 error when the lowest selection (column name) for the metadata 11 g dictionary

Hi all
I get a 404 error when I select a column name and click the link for dictionary of metadata. I get the 404 because obiee is allowing more 179 characters for the web link. You do not get a 404 error if you click on one of the shorter column names.
When you select the number of offices with commands and then click the metadata dictionary button you get the error 404 below and the web address is truncated causing the 404
This is the product link
http / / self/analyticsRes/SampleAppLite_BI0024/SubjectArea/PRCAT_Sample_Sales_Lite80cb6a2e /.
PRT_Calculated_Facts80cb6aa9/PRC_N_of_Offices_with_Or80cb6cfb.x
If you type the ml at the end, you can see the Web page you want. Also if you click on the area in question and then click the dictionary of metadata and access the column from here the link works.

We receive this error in our Dictionary of metadata generated, but I can also reproduce the problem with the sample app, we have placed the dictionary in the folder anlyticsRes.
I just wanted to check to see if someone else has this problem.
Thanks in advance!
S. Clark

I opened a SR and a bug has already been reported, and the solution is in the latest patch.

Solution

The fix for the Bug 17449036

is included in the bundle 20124371 Patch (patch bundle 11.1.1.7.150120). See this note for more information:

Note 1488475.1: OBIEE 11 g: required and recommended patches and Patch Sets

There is also a one-off Patch 17449036 on top of previous patch bundle for different platforms.
It is advisable to be in the latest patch bundle. In this case, you prefer to apply exceptional measures, you can do but
It is not for all platforms and all the patches together.

Table-1 (MONTHLY_PART_1)	Table-2 (MONTHLY_PART_2)
SL_NO	SL_NO
MODEL	MODEL
END_DATE	END_DATE
U-1	U-1
U-2	U-2
U-4	U-4
..........	........
..........	........
U-20	U-20
U-25	U-25

Help me explain Plan of reading and understanding

Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production

SELECT SRC2.PGM_MSTR_NBR,
                                              SRC2.PGM_TRK_NBR,
                                              SRC2.CNTL_LOCN,
                                              SRC2.PGM_NAME,
                                              SRC2.PGM_STS,
                                              SRC2.SIS_PGM_START_DATE,
                                              SRC2.SIS_PGM_END_DATE,
                                              SRC2.AWARD_TRGT,
                                              SRC2.AWARD_MAX,
                                              SRC2.COMPLNC_TYPE,
                                              SRC2.CMPNY_VNDR_LOCN,
                                              SRC2.CMPNY_VNDR_NBR,
                                              LKP3.ADDR_NAME,
                                              SRC2.INV_IND,
                                              SRC2.LAST_INV_THRU_DATE,
                                              SRC2.INV_RPT_DAY,
                                              SRC2.INV_RPT_CYCLE,
                                              SRC2.BEG_COLL_DATE,
                                              SRC2.END_COLL_DATE,
                                              SRC2.SLS_CONT_DIST,
                                              SRC2.SLS_CONT_NBR,
                                              SRC2.ORD_INV_START_DATE,
                                              SRC2.ORD_INV_END_DATE,
                                              SRC2.CMPLNC_RPT_IND,
                                              SRC2.PROD_ENTRY_LVL,
                                              SRC2.DIST_ENTRY_LVL,
                                              SRC2.CUST_ENTRY_LVL,
                                              SRC2.VNDR_ENTRY_LVL,
                                              SRC2.VNDR_CONT,
                                              SRC2.SIS_CMPNY_VNDR_NBR
                                              FROM CASADM.SBA_REB_PGM SRC2 
                                              INNER JOIN(SELECT PGM_MSTR_NBR,PGM_TRK_NBR,CNTL_LOCN  FROM CASADM.ACCR_SIS_PURCH_DTL
                                                         UNION SELECT PGM_MSTR_NBR,PGM_TRK_NBR,CNTL_LOCN  FROM CASADM.ACCR_SIS_EXCL_DTL)ACCR2
                                                    ON  (SRC2.PGM_MSTR_NBR=ACCR2.PGM_MSTR_NBR AND SRC2.PGM_TRK_NBR=ACCR2.PGM_TRK_NBR AND SRC2.CNTL_LOCN=ACCR2.CNTL_LOCN)
                                              LEFT OUTER JOIN
                                                        CASADM.MT_CMPNY_VNDR LKP3
                                                    ON (LKP3.CMPNY_VNDR_NBR=SRC2.CMPNY_VNDR_NBR);

Record Count in each table:
-----------------------------
select count(*) from casadm.accr_sis_purch_dtl --375,968
select count(*) from casadm.accr_sis_excl_dtl --1,988,867
select count(*) from casadm.sba_reb_pgm --526,133
select count(*) from casadm.mt_cmpny_vndr --20743

Execution Plan
----------------------------------------------------------
Plan hash value: 1465316812

--------------------------------------------------------------------------------

------------------------------

| Id  | Operation                    | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time|

--------------------------------------------------------------------------------



|   0 | SELECT STATEMENT             |                       |     9 |  1908 | | 26988   (2)| 00:06:18 |

|   1 |  NESTED LOOPS OUTER          |                       |     9 |  1908 | | 26988   (2)| 00:06:18 |

|*  2 |   HASH JOIN                  |                       |     9 |  1656 |83M| 26979   (2)| 00:06:18|

|   3 |    TABLE ACCESS FULL         | SBA_REB_PGM           |   536K|    77M| |  2624   (2)| 00:00:37 |

|   4 |    VIEW                      |                       |  2364K|    74M| | 16424   (2)| 00:03:50 |

|   5 |     SORT UNIQUE              |                       |  2364K|    49M|72M| 16424  (86)| 00:03:50|

|   6 |      UNION-ALL               |                       |       |       ||            |          |

|   7 |       INDEX FAST FULL SCAN   | ACCR_SIS_PURCH_DTL_PK |   375K|  8077K||   871   (1)| 00:00:13 |
|   8 |       TABLE ACCESS FULL      | ACCR_SIS_EXCL_DTL     |  1988K|    41M||  5634   (1)| 00:01:19 |

|   9 |   TABLE ACCESS BY INDEX ROWID| MT_CMPNY_VNDR         |     1 |    28 | |     1   (0)| 00:00:01 |

|* 10 |    INDEX UNIQUE SCAN         | MT_CMPNY_VNDR_PK      |     1 |       | |     0   (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------------


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

   2 - access("SRC2"."PGM_MSTR_NBR"="ACCR2"."PGM_MSTR_NBR" AND
              "SRC2"."PGM_TRK_NBR"="ACCR2"."PGM_TRK_NBR" AND "SRC2"."CNTL_LOCN"=

"ACCR2"."CNTL_LOCN")

  10 - access("LKP3"."CMPNY_VNDR_NBR"(+)="SRC2"."CMPNY_VNDR_NBR")


Statistics
----------------------------------------------------------
        102  recursive calls
          0  db block gets
      34558  consistent gets
      23241  physical reads
         88  redo size
     531258  bytes sent via SQL*Net to client
       2760  bytes received via SQL*Net from client
        361  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
       5392  rows processed

With respect to the HASH JOIN, there two operands a TABLE ACCESS FULL and VIEW. Oracle joins these results together based on the following predicate:

 2 - access("SRC2"."PGM_MSTR_NBR"="ACCR2"."PGM_MSTR_NBR" AND
              "SRC2"."PGM_TRK_NBR"="ACCR2"."PGM_TRK_NBR" AND "SRC2"."CNTL_LOCN"="ACCR2"."CNTL_LOCN")

The VIEW is the result of the union between the CASADM. ACCR_SIS_PURCH_DTL and CASADM. ACCR_SIS_EXCL_DTL o place access to the CASADM table. ACCR_SIS_PURCH_DTL Oracle was able to buy all the data of the index ACCR_SIS_PURCH_DTL_PK.

The FULL ACCESS TABLE is exactly what said access to a table full of SBA_REB_PGM.

The OUTSIDE of LOOPS IMBRIQUEES has two operands as the HASH JOIN. The way it works is for each result returned by the hash JOIN operation, it accesses the MT_CMPNY_VNDR_PK index, then the table that mt_cmpny_vndr based on the following predicate:

10 - access("LKP3"."CMPNY_VNDR_NBR"(+)="SRC2"."CMPNY_VNDR_NBR")

It would probably be useful for you to review the document following by Christian Antognini Interpreter of execution Plans as well.

questions to move a column name as parameter. Please advice.
Hi all

I have some difficulties with oracle reports. I am a novice with the beginner 2 days.
I am not able to use the lexical settings in reports. my query is as easy as

Select & column-name abc xyz;

I tried to make a setting before creating the SQL but I always get the error saying that ORA-00922: lack of expression.
also I tried with bind variables like

Select: col_name abc xyz;

but it gives a: inplace Column of records the data.

some could help me with step by step procedure to create a lexical parameter.

I am using reports 6i.

Please let me know for details.

Thanks in advance!
Hello

I suggest you create a sing an example 'Basic' of the EMP table: (see the demobld.sql script provided with Developer Suite to create this table)

Create a new report
Create a COLUMN name parameter:
Name = COLNAME
DataType = character
Width = 20
Initial value = ENAME

Create a SQL query: select & emp colname

Create a page layout manually or with the wizard

Click on the button «Run paper Layout»

Enter a valid value for the 'column' name (ENAME / JOB / SAL / COMM /...)

Concerning

3 clues on 3 different columns, but explain plan shows full table scan for select queries

I have a table - used and have index - functional ind1 (upper (f_name)), index - (emp_id) ind2 ind3 (upper (l_name) functional on 3 columns diffferent - what, emp_id, l_name respectively.) Now when I check explain plans for sub queries, they all have two shows complete table for the employee of the table scan. FYI - employee table is non-parittioned.

Can someone tell me why 3 indices are not used here?

(1) select emp_id, upper (f_name), upper (l_name) of the employee

(2) select upper (f_name), mp_id, upper (l_name) of the employee

where upper (f_name) = upper (f_name)

and emp_id = emp_id

and upper (l_name) = upper (l_name)

If I can push oracle (version 11) to use these indexes somewho - maybe using tips? Any help is appreciated.


Observations:

SQL> desc emp1;
 Name                                      Null?    Type
 ----------------------------------------- -------- -----------------
 EMPID                                      NOT NULL NUMBER
 F_NAME                                    NOT NULL VARCHAR2(3)
 L_NAME                                    NOT NULL VARCHAR2(3)
 SALARY                                    NUMBER
 JOB_ROLE                                 VARCHAR2(5)
 DEPTID                                     NUMBER

create index idx2 on emp1(empid);
create index idx1 on emp1(upper(f_name) );
create index idx3 on emp1(f_name,empid, l_name);
exec dbms_stats.gather_table_stats(user,'EMP1', cascade=>true);

8 rows selected.

SQL> explain plan for
  2  select /*+ index_join(e idx1 idx2 idx3)*/   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select    upper(f_name),empid,upper(l_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select /*+ index_ffs(e idx3)*/   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2496145112

-----------------------------------------------------------------------------
| Id  | Operation            | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-----------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select /*+ index(e idx3)*/   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select    upper(f_name),empid,upper(l_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> drop index idx3;

Index dropped.

SQL> explain plan for
  2     select   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3330885630

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 20000 |   175K|    18   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| EMP1 | 20000 |   175K|    18   (0)| 00:00:01 |
--------------------------------------------------------------------------

8 rows selected.

SQL> create index idx3 on emp1(f_name,empid, l_name );

Index created.

SQL>  explain plan for
  2     select   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |

Difference of cardinality estimate on explain plan and implementation plan

I think some of you know the 5% rule, which is explained in the note on metalink # 68992.1.
In short, this means that (with bind peeking out voltage)

- c1 > :b1 : 5% of selectivity
- c1 >= :b1 :5% of selectivity
- c1 between :b1 and :b2 : 0.25% of selectivity (5% * 5%)

It is also well explained fundamentals of the CBO by Jonathan Lewis.

But I found a few odd cases where the 5% rule is broken DURATION estimate.
The most interesting part is explain plan watch again the 5% rule.
Why the difference?

I think that with bind peeking out, explain the plan and the implementation plan should show the same things.
(Assuming that all values of the environment are identical)
Am I wrong?

It's the long story to tell, but simple test cases will show what I mean.

UKJA@ukja102> @version

BANNER
---------------------------------------------------------------------
---------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

UKJA@ukja102>
UKJA@ukja102> set echo on
UKJA@ukja102>
UKJA@ukja102> drop table t1 purge;

Table dropped.

Elapsed: 00:00:00.09
UKJA@ukja102>
UKJA@ukja102> create table t1(c1 int, c2 int)
  2  ;

Table created.

Elapsed: 00:00:00.01
UKJA@ukja102>
UKJA@ukja102> insert into t1
  2  select 1, level
  3  from dual
  4  connect by level <= 10000
  5  union all
  6  select 2, level
  7  from dual
  8  connect by level <= 1000
  9  union all
 10  select 3, level
 11  from dual
 12  connect by level <= 100
 13  union all
 14  select 4, level
 15  from dual
 16  connect by level <= 10
 17  union all
 18  select 5, level
 19  from dual
 20  connect by level <= 1
 21  ;

11111 rows created.

Elapsed: 00:00:00.32
UKJA@ukja102>
UKJA@ukja102> exec dbms_stats.gather_table_stats(user, 't1', method_opt=>'for all columns size 1');

PL/SQL procedure successfully completed.

* Disable bind peeking. *

UKJA@ukja102>
UKJA@ukja102> alter session set "_optim_peek_user_binds" = false;

In the following result, explain the plan following the 5% rule.
(11111 * 0.05 = 555)

UKJA@ukja102>
UKJA@ukja102> explain plan for
  2  select count(*)
  3  from t1
  4  where c1 > :b1
  5  ;

Explained.

Elapsed: 00:00:00.01
UKJA@ukja102>
UKJA@ukja102> @plan
UKJA@ukja102> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT                                                              
--------------------------------------------------------------------------------
Plan hash value: 3724264953                                                    
                                                                               
---------------------------------------------------------------------------    
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |    
---------------------------------------------------------------------------    
|   0 | SELECT STATEMENT   |      |     1 |     3 |     6   (0)| 00:00:01 |    
|   1 |  SORT AGGREGATE    |      |     1 |     3 |            |          |    
|*  2 |   TABLE ACCESS FULL| T1   |   556 |  1668 |     6   (0)| 00:00:01 |    
---------------------------------------------------------------------------    
                                                                               
Predicate Information (identified by operation id):                            
---------------------------------------------------                            
                                                                               
   2 - filter("C1">TO_NUMBER(:B1))                                             

14 rows selected.

Elapsed: 00:00:00.01

But the term plan does'nt follow the 5% rule. It uses its own density
(11111 * density (c1) = 11111 * 0.2 = 2222)

UKJA@ukja102> select /*+ gather_plan_statistics */
  2    count(*)
  3  from t1
  4  where c1 > :b1
  5  ;

  COUNT(*)                                                                     
----------                                                                     
      1111                                                                     

Elapsed: 00:00:00.00
UKJA@ukja102>
UKJA@ukja102> @stat
UKJA@ukja102> select * from table
  2  (dbms_xplan.display_cursor(null,null,'allstats cost last'));

PLAN_TABLE_OUTPUT                                                              
--------------------------------------------------------------------------------
SQL_ID  0nmqsysmr3ap9, child number 0                                          
-------------------------------------                                          
select /*+ gather_plan_statistics */   count(*) from t1 where c1 > :b1         
                                                                               
Plan hash value: 3724264953                                                    
                                                                               
--------------------------------------------------------------------------------
------------------                                                             
                                                                               
| Id  | Operation          | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-
Time   | Buffers |                                                             
                                                                               
--------------------------------------------------------------------------------
------------------                                                             
                                                                               
|   1 |  SORT AGGREGATE    |      |      1 |      1 |            |      1 |00:00
:00.01 |      23 |                                                             
                                                                               
|*  2 |   TABLE ACCESS FULL| T1   |      1 |   2223 |     6   (0)|   1111 |00:00
:00.01 |      23 |                                                             
                                                                               
--------------------------------------------------------------------------------
------------------                                                             
                                                                               
                                                                               
Predicate Information (identified by operation id):                            
---------------------------------------------------                            
                                                                               
   2 - filter("C1">:B1)                                                        
                                                                               

18 rows selected.

the 5% rule seems to be
-applied to explain the plan always
-applied at the level of enforcement only when density 5 < %. When the density > 5%, he uses the density not 5%

I'm not sure it's a designed feature or a bug.
But estimates of different cardinality explain a plan and DURATION (with bind peeking out voltage) is not that desirable thing.

One's opinion on this?

Dion Cho

Sorry to take some time to get back on this one.

I can reproduce your results in 10.2.0.1, but the anomaly is not present in 9.2.0.8 and 10.2.0.3 and 11.1.0.6.
As Charles, the calculation has a boundary condition when a num_diistinct falls below 20
(i.e. when a value is more than 5% of the total data set - average).

However, the fact that explain the plan and the run time you give estimates of different cardinality is a bug.
Everything they say, they should say the same thing at least that the introduction of the variable binding
introduced a possible type conversion or the NLS conversion feature that has changed the
calculation of the expected cardinality. In this case there is no reason why the use of links should be
cause confusion - so we can reasonably assume that it is a bug.

Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK

"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." (Stephen Hawking)

Explain plan for select distinct

I got 1 of the online test and there the question has been asked. I have already answered but curious to cross-check my response with your advice...

Question

Explain what information plan if the show room in SQL indicates that a separate select statement is made in the SQL.

The choices are:

Sort by a join

b sort by

c single fate

d sort aggregate

group e - sort by

My answer

I gave aggregates of SORT but it seems that his unique kind, because when I run explain plan then I see (unique) hash. Please guide

SEPARATE will identify unique rows. So in the given choice it would be KIND of UNIQUE. But oracle could go other plans as UNIQUE HASH or same INDEX FULL SCAN.

Look at the oracle does not SORT.

SQL> select distinct ename from emp;
ENAME
------
SMITH
BLAKE
CLARK
KING
ADAMS
TURNER
ALLEN
SCOTT
JONES
MARTIN
WARD
11 rows selected.
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------
SQL_ID  6b32yqumjmp9b, child number 0
-------------------------------------
select distinct ename from emp
Plan hash value: 984151148
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |     3 (100)|          |
|   1 |  HASH UNIQUE       |      |    11 |    66 |     3  (34)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMP  |    11 |    66 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

14 rows selected.

Let me make an explicit ORDER BY for her to performa SORT.

SQL> select distinct ename from emp order by 1;
ENAME
------
ADAMS
ALLEN
BLAKE
CLARK
JONES
KING
MARTIN
SCOTT
SMITH
TURNER
WARD
11 rows selected.
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------
SQL_ID  f72vjx5rmm0z4, child number 0
-------------------------------------
select distinct ename from emp order by 1
Plan hash value: 725351111
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |     4 (100)|          |
|   1 |  SORT UNIQUE       |      |    11 |    66 |     3  (34)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMP  |    11 |    66 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

14 rows selected.
SQL>

Version - 10.2.0.5.0

There are two select statement, which are as follows: 1) select project id, the name of ppm.pm_projects project_name and request_id 2) select id, name from request_type_name to kcrt_request_details. There is a column called entity that allows you to store

There are two select statement, which are as follows: 1) select project id, the name of ppm.pm_projects project_name and request_id 2) select id, name from request_type_name to kcrt_request_details. There is a column called entity that can store a value i.e. project or request. I want to write a select statement containing a condition that is if the entity name is project and then run the select statement 1 otherwise, if the name of the entity's request, then run the select statement 2. All this must be written in a select statement. Can someone help me how to write this select statement type.

Hello

Hello

2726057 wrote:

... There is a column called entity that can store a value i.e. project or request. ...

In which table is this column? Assuming that it is in a table called entity_table, you can do something like this:

SELECT project AS id

project name AS the name

OF ppm.pm_projects

WHEN THERE IS)

SELECT 1

Of entity_table

Entity WHERE = "Project".

)

UNION ALL

SELECT request_id ID

request_type_name AS name

OF kcrt_request_details

WHEN THERE IS)

SELECT 1

Of entity_table

Entity WHERE = 'ask '.

)

;

This does not have anything on the number of lines is entity_table, or what are the values in the column of the entity. In other words, the query works in all cases. If any line in entity_table entity = 'Project', then the pm_projects data will be included in the result set. If any line in entity_table entity = 'Request', kcrt_request_details data will be included.

I hope that answers your question.

If this isn't the case, please post a small example data (CREATE TABLE and only relevant columns, INSERT statements) for all of the tables involved and the results desired from these data.

Explain, using specific examples, how you get these results from these data.

Always say what version of Oracle you are using (for example, 11.2.0.2.0).

See the FAQ forum: https://forums.oracle.com/message/9362002#9362002

Can I use * and the list of the column names in a select query

PLSQL again. Can I use * and the list of the column names in a select query, i.e. Select *, col1, col2 from Mytable. When I do that my questions tend to the bomb. Can do in other databases.
Thank you
Mike

Hi, Mike,.

If there is something else in the more SELECT clause *, then * must be qualified with a table name or alias.

For example:

SELECT Mytable. *, col1, col2

FROM MyTable;

I have a subscription, it's almost over, but I need to change plans and cannot select one I need in the menu plan for change, and I can't cancel. Is it possible to cancel it?

I have a subscription, it's almost over, but I need to change plans and cannot select one I need in the menu plan for change, and I can't cancel. Is it possible to cancel it?

Hello

Please contact support by calling/chat for cancellation requests and billing queries:

Contact the customer service

* Be sure to stay connected with your Adobe ID before accessing the link above *.

You can also check the help below document:

https://helpx.Adobe.com/x-productkb/policy-pricing/cancel-membership-subscription.html

Please go through the Adobe - General conditions of subscription as well.

change the selected column puts loop nested in the hash join

Hi all

If "select * from...". «I "select table.* of...» "then plan changes.

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  a4fgvz5w6b0z8, child number 0
-------------------------------------
select * from ofertas ofe, ofertas_renting ofer where ofer.codigodeempresa = ofe.codigodeempresa    AND ofer.numerooferta =
ofe.numerooferta    AND ofe.captacion = '1'

Plan hash value: 3056192218

----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name            | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------------------------------
|*  1 |  HASH JOIN         |                 |      1 |  23766 |  4032   (2)|  27421 |00:00:00.96 |    5444 |  9608K|  1887K|   10M (0)|
|*  2 |   TABLE ACCESS FULL| OFERTAS         |      1 |  23969 |  1324   (2)|  27421 |00:00:00.14 |    2140 |       |       |          |
|   3 |   TABLE ACCESS FULL| OFERTAS_RENTING |      1 |  71297 |   937   (2)|  72385 |00:00:00.22 |    3304 |       |       |          |
----------------------------------------------------------------------------------------------------------------------------------------

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

   1 - access("OFER"."CODIGODEEMPRESA"="OFE"."CODIGODEEMPRESA" AND "OFER"."NUMEROOFERTA"="OFE"."NUMEROOFERTA" AND
              SYS_OP_DESCEND("OFER"."NUMEROOFERTA")=SYS_OP_DESCEND("OFE"."NUMEROOFERTA"))
   2 - filter("OFE"."CAPTACION"='1')


22 filas seleccionadas.

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  2410uqu059fgw, child number 0
-------------------------------------
select ofe.* from ofertas ofe, ofertas_renting ofer where ofer.codigodeempresa = ofe.codigodeempresa
AND ofer.numerooferta = ofe.numerooferta    AND ofe.captacion = '1'

Plan hash value: 4206210976

----------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name               | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------
|   1 |  NESTED LOOPS      |                    |      1 |  23766 |  1333   (3)|  27421 |00:00:00.58 |   33160 |
|*  2 |   TABLE ACCESS FULL| OFERTAS            |      1 |  23969 |  1324   (2)|  27421 |00:00:00.27 |    3910 |
|*  3 |   INDEX UNIQUE SCAN| PK_OFERTAS_RENTING |  27421 |      1 |     0   (0)|  27421 |00:00:00.26 |   29250 |
----------------------------------------------------------------------------------------------------------------

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

   2 - filter("OFE"."CAPTACION"='1')
   3 - access("OFER"."CODIGODEEMPRESA"="OFE"."CODIGODEEMPRESA" AND
              "OFER"."NUMEROOFERTA"="OFE"."NUMEROOFERTA")


22 filas seleccionadas.

Why change if the cost to access the complete table OFFERS is identical in the two plans?

Thank you very much.

Joaquin Gonzalez

Published by: Joaquín González on November 4, 2008 17:32

Joaquín González wrote:
Hello

Perhaps the reason for Blevel = 0 is?

"This is."
some common cases that could result in a variation between the basic formula and the
"result:

...

"Index where the blevel is set to 1 (the index goes directly from the root block in the).
leaf blocks). The optimizer ignores effectively the blevel if each column in the index
appears in a predicate of equality. "

Joaquin,

you're referring to the chapter "access Simple B-tree", it is a nested loop operation, so this does not apply. You can see that the 'Simple B-tree access' refers to a cost of 1, you have tested yourself.

I think that it is a special case, if you have a nested loop operation that uses access unique index as the source of the inner line, then the cost of access unique index is simply BLEVEL - 1. You might get a different cost if access additional table of rowid is involved, which is usually the case. But even in this case access to the unique index is always encrypted in BLEVEL - 1, and access the table by rowid is usually encrypted to 1 by iteration.

You can see on page 313 (chapter "Nested Loop") that Jonathan has used an example involving a unique index scan that also has a cost of 0.

Kind regards
Randolf

Oracle related blog stuff:
http://Oracle-Randolf.blogspot.com/

SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/

Select the column name when the value = something

Is there a way to select the column name when there is a specific value in it?
As follows:
create table (abc123)
COLUMN1 VARCHAR2 (50).
COLUMN2 VARCHAR2 (50).
Column3 varchar2 (50)
);
insert into abc123 values ('yes', 'Yes', 'No');
insert into abc123 values ('no', 'Yes', 'No');
INSERT INTO ABC123 VALUES ('no ',' no', 'No');
insert into abc123 values ('yes', 'Yes', 'Yes');
SELECT CASE WHEN COLUMN1 = 'Yes' THEN - the name of the column would be here somehow?
WHEN COLUMN2 = 'Yes' THEN - the name of the column would be here somehow?
WHERE Column3 = 'Yes' THEN - the name of the column would be here somehow?
Another null
finish as abc123 columnname
final results for the just Column1 would be:
COLUMN1
NULL VALUE
NULL VALUE
COLUMN1
I'm not sure what I use to get the name of column in there
Thank you.

Hello

708631 wrote:

Is there a way to select the column name when there is a specific value in it?

As follows:

create table (abc123)

COLUMN1 VARCHAR2 (50).

COLUMN2 VARCHAR2 (50).

Column3 varchar2 (50)

);

insert into abc123 values ('yes', 'Yes', 'No');

insert into abc123 values ('no', 'Yes', 'No');

INSERT INTO ABC123 VALUES ('no ',' no', 'No');

insert into abc123 values ('yes', 'Yes', 'Yes');

SELECT CASE WHEN COLUMN1 = 'Yes' THEN - the name of the column would be here somehow?

WHEN COLUMN2 = 'Yes' THEN - the name of the column would be here somehow?

WHERE Column3 = 'Yes' THEN - the name of the column would be here somehow?

Another null

finish as abc123 columnname

final results for the just Column1 would be:

COLUMN1

NULL VALUE

NULL VALUE

COLUMN1

I'm not sure what I use to get the name of column in there

Thank you.

Thanks for posting the CREATE TABLE and INSERT for the sample data.

Don't forget to post the exact results you want from these sample data. If the results depend on the parameters you want to pass a run time, then give a few different examples, with the the desired results of each.

You can hardcode the values you want, such as the column names in a query. For example:

SELECT CASE WHEN column1 = 'Yes' THEN 'Column1' END like y1

CASE WHEN column2 = 'Yes' THEN 'Column2' END like y2

CASE WHEN Column3 = 'Yes' THEN 'Column2' END like y3

, a. *-If wanted

Of abc123 one

;

There is no possibility of ambiguity in the SELECT clause because any identifier in the SELECT clause must be a database column name

Hello
Doc Oracle says the following on the identifiers in the SELECT in PL/SQL clause: there is no possibility of ambiguity in the SELECT clause because any identifier in the SELECT clause must be a database column name.
If we assume that only valid column identifier are allowed in the SELECT clause.
But I tried the following:
```
DECLARE
toto NUMBER := 10;
tata NUMBER := 0;
BEGIN
SELECT toto INTO tata FROM employees WHERE employee_id = 101;
DBMS_OUTPUT.PUT_LINE(tata);
END;
/
```
And there is no error telling me that toto is not a column in the employees table and the result is the same as: toto: = aunt;
Won't the doc or did I just miss something?
Thanks for your response!

Hello

rep0ne wrote:

Hello

Doc Oracle says the following on the identifiers in the SELECT in PL/SQL clause: there is no possibility of ambiguity in the SELECT clause because any identifier in the SELECT clause must be a database column name.

If we assume that only valid column identifier are allowed in the SELECT clause.

Post a link to this Oracle doc.

But I tried the following:
1. DECLARE
2. Toto NUMBER: = 10;
3. Auntie NUMBER: = 0;
4. BEGIN
5. SELECT toto IN Auntie FROM Employees WHERE employee_id = 101;
6. DBMS_OUTPUT. Put_line (Auntie);
7. END;
8. /
And there is no error telling me that toto is not a column in the employees table and the result is the same as: toto: = aunt;

...

You're right that toto is an identifier, but this isn't a column name. (Of a subquery) column alias are not database of the names of columns either, nor are the names of the user-defined function.

Also, there is a possibility for ambiguity even if all the names are the database column names.

Won't the doc or did I just miss something?

I can't say until I see the doc you're talking about.

Oracle documentation is sometimes misleading and sometimes just plain wrong. For each mistake outright example that I saw in the docs of Oracle, there might be 20 cases where the meaning is unclear or misleading and maybe 200 where I just read it wrong.

Difference explain plan "Select 1' and"Select column-name".

Similar Questions

Solution

Maybe you are looking for