Explain Plan shows not good results.

Similar Questions

• 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 |
  

• Explain plan shows no relevant tables

  Hi all
  
  spin 10.2.0.4 on solaris
  
  
  I have a duration long query explain plan... The explain plan displays the name of the other tables (table full access) that don't exist anywhere in the query that problem...
  
  
  Please notify
  
  Kai

  "BOLD" names the table not in the query (* IVM_INVOICE_RECORD *)

  They are referenced in the ARM_SUBS_BALANCE view.

• Type dialog open shows not all results

  I have a workspace with 11 projects with different interdependencies. If I open the Type dialog box open and always look for a type not all types appears. It seems that it only shows the types that are part of the project of the currently selected file dependencies.

  It should work this way? How to list all of the types in the workspace so that I can easily switch from one project to another? Currently I still find myself using the Open Resource dialog box instead, but it's not ideal.

  Currently he is the expected behavior. Please vote for the https://bugs.adobe.com/jira/browse/FB-11801 to make the open type collection space of whole work rather than the current project research.

• USB 3.0 not good results

  Hi, I use a HP-g009ax on Win8.1 64-bit.

  I couldn't find the correct drivers for the laptop, so I used the HP g002ax drivers for it.

  I have a USB 3.0 external drive and after connection to a USB port on the left side of the laptop, the speeds are always those USB 2.0 (20mpbs to 33mpbs).

  I installed the driver of USB duplicator I found for the g002ax series, always the speed seems to be the same.

  In Device Manager, I can find the ' AMD USB 3.0 eXtensible Host Controller - 0100 Microsoft "is installed and the drivers are working properly.

  How to activate the correct USB 3.0 feature for my laptop? Any help is appreciated

  sudhingr8 wrote:

  I ran the test on the hard drive and 37mbps on it. So, the hard drive is capable of only that much huh.

  If these are the results you get, then that's pretty much all. The next time you buy a disk inherited, make sure it is SATA600 specification. I noticed that even in the product information sheets Transcend gives no figures on data transfer bandwidth. They seem to use usb 3.0 as selling point without providing any data specific to the future owners. Marketing is what it is all. I am owner of a Transcend 16 GB USB stick and it was marketed very differently from your own external drive of transcend rugged usb 3.0

  My preference is for SSDS and hybrid high speed for data transfer.  Old hard disks will probably be that a memory in ten years if we consider how the speed at which technology is evolving.

• SQL not using indexes at runtime, but by using the index in "explain plan".

  Hi all

  I am facing a problem here that I don't get to think.

  I have a SQL that makes a FULL ACCESS of TABLE into two tables and its costs are very high, but it occurs only when I run it in my program (I saw it in the session trace). If I do a "explain plan" sqlplus (SQL Navigator or PLSQL Developer) it shows that he use indexes and have a low cost. I already checked the statistics from both tables, and they are up to date.

  Did someone never facing a similar problem or knows something I can do to find my problem?

  Thank you all very much.

  Hello

  As far as I KNOW, optimizer Oracle never guarantees that an Index scan in query explain plan will be necessarily used during query execution.

  ORACLE-BASE - DBMS_XPLAN: Oracle display execution Plans

  Could you please read the above, run the query, as described and check the execution using DBMS_XPLAN plan. The cursor cache DISPLAY_CURSOR and not PLAN_TABLEs.

• explain plan for the same query diff

  Hi experts,

  Please, help me understand explain the plan.  I have tow Server (server and two server). The server are same table, even the type of database, even version Oracle (gr 11 (2), same operating system (linux Redhat 5.5) and same table and index.

  but when I explain the plan for the same query on the two server. I got diff--diff to explain the plan. reason it has different, according to my understanding, it should be same. explain please, I share the explain plan and lower indices for the two server.

  Server a

  SQL > col COLUMN_NAME format a20

  SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.

  INDEX_NAME COLUMN_NAME POSITION_COLONNE

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

  DATE_IND1_S LOANDATETIME 1

  IND_MSI_LN_LNS1_S MSISDN 1

  IND_MSI_LN_LNS1_S LOANDATETIME 2

  IND_MSI_LN_LNS1_S LOANSTATUS 3

  LAST_INDEX L_INDX_MSISDN_S 1

  MSISDN L_INDX_MSISDN_S 2

  SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status

  2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.

  3 union

  4. Select 'Local' ind_type, index_name, nom_partition, status

  5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')

  6 order of 1,2,3;

  IND_TYPE INDEX_NAME NOM_PARTITION STATUS

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

  Global DATE_IND1_S VALID

  Global IND_MSI_LN_LNS1_S VALID

  Global L_INDX_MSISDN_S VALID

  SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;

  He explained.

  SQL > SQL > set line 200

  @?/rdbms/admin/utlxpls.sql

  SQL >

  PLAN_TABLE_OUTPUT

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

  Hash value of plan: 3659874059

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

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

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

  |   0 | SELECT STATEMENT |                            |  1448K |    58 M | 21973 (2) | 00:04:24 |       |       |

  |*  1 |  FILTER |                            |       |       |            |          |       |       |

  |   2.   PARTITION LIST ALL |                            |  1448K |    58 M | 21973 (2) | 00:04:24 |     1.    11.

  |*  3 |    TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH |  1448K |    58 M | 21973 (2) | 00:04:24 |     1.    11.

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

  PLAN_TABLE_OUTPUT

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

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

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

  1 - filter(SYSDATE@!-2>SYSDATE@!-15)

  3 - filter("LOANTYPE"=1 AND "LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)

  16 selected lines.

  Second server

  SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.

  INDEX_NAME COLUMN_NAME POSITION_COLONNE

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

  DATE_IND1_S LOANDATETIME 1

  IND_MSI_LN_LNS1_S MSISDN 1

  IND_MSI_LN_LNS1_S LOANDATETIME 2

  IND_MSI_LN_LNS1_S LOANSTATUS 3

  LAST_INDEX L_INDX_MSISDN_S 1

  MSISDN L_INDX_MSISDN_S 2

  SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status

  2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.

  Union

  3 4 Select 'Local' ind_type, index_name, nom_partition, status

  5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')

  6 order of 1,2,3;

  IND_TYPE INDEX_NAME NOM_PARTITION STATUS

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

  Global DATE_IND1_S VALID

  Global IND_MSI_LN_LNS1_S VALID

  Global L_INDX_MSISDN_S VALID

  SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;

  SQL > set line 200

  @?/rdbms/admin/utlxpls.sql

  SQL >

  PLAN_TABLE_OUTPUT

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

  Hash value of plan: 1161680601

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

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

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

  |   0 | SELECT STATEMENT |                            |     2.    84.     5 (0) | 00:00:01 |       |       |

  |*  1 |  FILTER                             |                            |       |       |            |          |       |       |

  |*  2 |   TABLE ACCESS BY INDEX ROWID | LOAN_RUNNING_DETAILS_SOUTH |     2.    84.     5 (0) | 00:00:01 | ROWID | ROWID |

  |*  3 |    INDEX RANGE SCAN | DATE_IND1_S |     2.       |     3 (0) | 00:00:01 |       |       |

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

  PLAN_TABLE_OUTPUT

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

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

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

  1 - filter(SYSDATE@!-2>SYSDATE@!-15)

  2 - filter ("LOANTYPE" = 1)

  3 - access("LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)

  17 selected lines.

  Reg,

  Hard

  Hi , HemantKChitale,

  I also update statistics manual as you say, but not see 'TABLE ACCESS FULL' good result

  What should I do? my need of production tuning, but I cannot able tune this...

  SQL > exec dbms_stats.gather_table_stats (-online 'ttt' ownname, tabname => 'LOAN_RUNNING_DETAILS_SOUTH', cascade => TRUE, estimate_percent => NULL, method_opt => 'for all columns size 254', => of degree 4);

  PL/SQL procedure successfully completed.

  SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME<=sysdate-2 and="" loandatetime="">sysdate-15 and LOANTYPE = 1;

  He explained.

  SQL > set line 200

  @?/rdbms/admin/utlxpls.sql

  SQL >

  PLAN_TABLE_OUTPUT

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

  Hash value of plan: 3659874059

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

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

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

  |   0 | SELECT STATEMENT |                            |  1874K |    75 M | 19626 (2) | 00:03:56 |       |       |

  |*  1 |  FILTER |                            |       |       |            |          |       |       |

  |   2.   PARTITION LIST ALL |                            |  1874K |    75 M | 19626 (2) | 00:03:56 |     1.    11.

  |*  3 |    TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH |  1874K |    75 M | 19626 (2) | 00:03:56 |     1.    11.

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

  PLAN_TABLE_OUTPUT

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

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

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

  1 - filter(SYSDATE@!-2>SYSDATE@!-15)

  3 - filter("LOANDATETIME">SYSDATE@!-15 AND "LOANTYPE"=1 AND "LOANDATETIME")<>

  16 selected lines.

• 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

• Explain plan used

  Hello

  on 11.2.0.3, I use the following to check the explain Plan used for an executed query.

  SELECT * FROM
  TABLE (DBMS_XPLAN. DISPLAY_AWR ('< sql_id >', '< plan_hash >'));

  For example

  SELECT * FROM TABLE (DBMS_XPLAN. DISPLAY_AWR ('cx8m90z5n57g1','3867296312'));

  The problem is that it does not always return a result to display. Every now and then it does not find any Plan to explain. Why?

  Any other way that find a used Plan explain for sure?

  Thank you and best regards.

  SQL cannot be captured by AWR as he may not be among the SQLs ' n top of page in a snapshot.

  However, if the SQL code is still present in the cache of the library, you can use DBMS_XPLAN. DISPLAY_CURSOR

  Hemant K Collette

• Book advises explain plan

  Hi guys,.
  
  I have 2 questions. The first is as you know before, I would like to learn the secrets behind explain plan and how how oracle works behind the scene. I have studied some books. I found Oracle SQL Tuning: A Close Look at explain Plans by Dan Hotka. Do you recommend this book? I just read a page of this book, I thnik the language of this book is simple and he explains the situation from the beginning. In my view, it is helpful for beginners like me. Because things get difficult to learn in first time for beginners. As a result I just want to learn you recommend this book?
  
  My second question is, I want to buy this book, but I couldn't find in England (Paperback, not e book). But appereantly I have to buy online as ebook. Do you know any site web confidence that I can buy the ebook of this book version?
  
  Thanks a lot for your help.

  944258 wrote:
  Hi guys,.

  I have 2 questions. The first is as you know before, I would like to learn the secrets behind explain plan and how how oracle works behind the scene. I have studied some books. I found Oracle SQL Tuning: A Close Look at explain Plans by Dan Hotka. Do you recommend this book? I just read a page of this book, I thnik the language of this book is simple and he explains the situation from the beginning. In my view, it is helpful for beginners like me. Because things get difficult to learn in first time for beginners. As a result I just want to learn you recommend this book?

  Hi, why not start here everything first: http://www.orafaq.com/node/1420. There is probably more information about execution plans available online, as it is in the books. At least the part that you want to find out and try to remember will be available online :-)

  >

  My second question is, I want to buy this book, but I couldn't find in England (Paperback, not e book). But appereantly I have to buy online as ebook. Do you know any site web confidence that I can buy the ebook of this book version?

  http://www.Amazon.com/Oracle-SQL-Tuning-close-explain/DP/1453804196

  See you soon
  FJFranken

• EXPLAIN Explain plan

  Hello
  can someone point me to full details of the Plan, including how to understand the syntax in the statement "3-filter...". "marked in red.
  This cross-history. I expect to see <>(not the equal sign) between these columns, but there is nothing:
  Actual results is also 14 ranks, but I do not see that the figure anywhere in the plan, only "12" will be one any correlation between the numbers of plan and result?
  

  T1 (col_1 number):
  1
  2
  3
  4
  
  T2 (col_1 number):
  3
  4
  5
  6
  
  
  SQL> explain plan for  select t1.col_1 from t1, t2 where t1.col_1 != t2.col_1;
   
  Explained.
   
  SQL> select * from table(dbms_xplan.display);
   
  PLAN_TABLE_OUTPUT
  ------------------------------------------------------------------------------------------------------------------------------------
  Plan hash value: 1967407726
   
  ---------------------------------------------------------------------------
  | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
  ---------------------------------------------------------------------------
  |   0 | SELECT STATEMENT   |      |    12 |   312 |     6   (0)| 00:00:01 |
  |   1 |  NESTED LOOPS      |      |    12 |   312 |     6   (0)| 00:00:01 |
  |   2 |   TABLE ACCESS FULL| T1   |     4 |    52 |     2   (0)| 00:00:01 |
  |*  3 |   TABLE ACCESS FULL| T2   |     3 |    39 |     1   (0)| 00:00:01 |
  ---------------------------------------------------------------------------
   
  Predicate Information (identified by operation id):
  ---------------------------------------------------
   
     3 - filter("T1"."COL_1""T2"."COL_1")          ---/*XXX
   
  Note
  -----
     - dynamic sampling used for this statement
   

  the cost based optimizer uses internal statistics to determine the number of rows that an operation will be back. For the simple query in your example, these estimates would be quite accurate if statistics have been sufficient - but they are not since we see the dynamic sampling note that indicates the missing statistics: http://blogs.oracle.com/optimizer/entry/dynamic_sampling_and_its_impact_on_the_optimizer

  -- without statistics
  ---------------------------------------------------------------------------
  | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
  ---------------------------------------------------------------------------
  |   0 | SELECT STATEMENT   |      |    12 |   312 |    13   (0)| 00:00:01 |
  |   1 |  NESTED LOOPS      |      |    12 |   312 |    13   (0)| 00:00:01 |
  |   2 |   TABLE ACCESS FULL| T1   |     4 |    52 |     4   (0)| 00:00:01 |
  |*  3 |   TABLE ACCESS FULL| T2   |     3 |    39 |     2   (0)| 00:00:01 |
  ---------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     3 - filter("T1"."ID"<>"T2"."ID")
  
  Note
  -----
     - dynamic sampling used for this statement (level=2)
  
  -- gather statistics
  exec dbms_stats.gather_table_stats(user, 'T1')
  exec dbms_stats.gather_table_stats(user, 'T2')
  
  -- with statistics (we see the 4 * 4 = 16 rows we expect)
  ---------------------------------------------------------------------------
  | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
  ---------------------------------------------------------------------------
  |   0 | SELECT STATEMENT   |      |    16 |    96 |    13   (0)| 00:00:01 |
  |   1 |  NESTED LOOPS      |      |    16 |    96 |    13   (0)| 00:00:01 |
  |   2 |   TABLE ACCESS FULL| T1   |     4 |    12 |     4   (0)| 00:00:01 |
  |*  3 |   TABLE ACCESS FULL| T2   |     4 |    12 |     2   (0)| 00:00:01 |
  ---------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     3 - filter("T1"."ID"<>"T2"."ID")
  

  The filter says that operation 3 complete analysis results are filtered by the given condition. If we had clues you might see an access descriptor.

  Concerning

  Martin Preiss

• DECODE is changing the explain plan

  I have a statement with a decoding function in the where clause like this:
  

  AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)

  When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.
  
  Below plans to explain and tkprofs to 1 (no decode) and 2 (decode).
  
  * explain 1 *.
  {code}
  SQL statement that produced these data:
  Select * from table (dbms_xplan.display)
  
  PLAN_TABLE_OUTPUT
  
  ---------------------------------------------------------------------------------------------------------------
  | ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU).
  ---------------------------------------------------------------------------------------------------------------
  | 0 | SELECT STATEMENT | 7080 | 2413K | 43611 (2) |
  | 1. SORT ORDER BY | 7080 | 2413K | 5224K | 43611 (2) |
  |* 2 | FILTER |
  |* 3 | HASH JOIN | 7156. 2 438 K | 43075 (2) |
  | 4. TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745. 363KO | 83 (0) |
  |* 5 | OUTER HASH JOIN | 7156. 2292K | 42991 (2) |
  |* 6 | HASH JOIN | 7156. 1355K | 42907 (2) |
  |* 7 | HASH JOIN | 6987. 1187K | 19170 (2) |
  |* 8 | HASH JOIN | 6947 | 963K | 10376 (1) |
  |* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3. 144. 3 (0) |
  | 10. NESTED LOOPS | 6907. 897K | 8577 (1) |
  | * 11 | HASH JOIN | 2264 | 187K | 1782 (2) |
  | 12. TABLE ACCESS BY INDEX ROWID | SAMPLE | 190. 4370. 17 (0) |
  | 13. NESTED LOOPS | 2264 | 152K | 107 (1) |
  | 14. NESTED LOOPS | 12. 552. 25 (0) |
  | * 15 | TABLE ACCESS FULL | SDG_USER | 12. 288. 13 (0) |
  | 16. TABLE ACCESS BY INDEX ROWID | SDG | 1. 22. 1 (0) |
  | * 17. INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0) |
  | * 18. INDEX RANGE SCAN | FK_SAMPLE_SDG | 597. 2 (0) |
  | 19. TABLE ACCESS FULL | SAMPLE_USER | 1078K | 16 M | 1669 (1) |
  | * 20. INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0) |
  | 21. TABLE ACCESS FULL | ALIQUOT_USER | 3403K | 29 M | 1781 (3) |
  | 22. TABLE ACCESS FULL | TEST | 3423K | 104 M | 8775 (2) |
  | * 23. TABLE ACCESS FULL | RESULT | 3435K | 65 M | 23718 (2) |
  | 24. VIEW | PLATE | 21787 | 2851K | 84 (2).
  | * 25. FILTER |
  | 26. TABLE ACCESS FULL | PLATE | 21787 | 574K | 84 (2).
  | * 27. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
  | * 28. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
  | * 29. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
  | * 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
  | * 31. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
  ---------------------------------------------------------------------------------------------------------------
  
  Information of predicates (identified by the operation identity card):
  ---------------------------------------------------
  
  2. ((«GROUP_ID» EST NULL ou EXISTE (SELECT / * + * / 0 DE "AGIL".) filter)) "OPERATOR_GROUP"
  "OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B1)) AND ('GROUP_ID' IS NULL) "'". "
  OR EXISTS (SELECT / * + * / 0 "LIMS".) ' ' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE
  "OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B2)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * +)) "" "."
  * / 0 "LIMS". "' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "."
  (('GROUP_ID' =: B3)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * + * / 0 "LIMS".)) "" OPERATOR_GROUP ".
  'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B4)))".
  3 - access ("U_ABS_DETERMINATION" ="DETERMINATION_ASSIGNMENT")
  5 - access("PLT".") PLATE_ID"(+) ="PLATE_ID")
  6 - access ("TEST_ID" ="TEST_ID")
  7 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
  8 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
  9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
  11 - access ("SAMPLE_ID" ="SAMPLE_ID")
  15 - filter ("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE" = 'QC' AND
  "U_WEEK_OF_PROCESSING"= TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY' = TO_NUMBER (:YEAR)).
  17 - access ("SDG_ID" ="SDG_ID")
  18 - access ("SDG_ID" ="SDG_ID")
  20 - access ("SAMPLE_ID" ="SAMPLE_ID")
  23 - filter ('NAME' = 'End result')
  25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS".")) OPERATOR_GROUP ".
  'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B1))".
  27 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
  28 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
  29 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
  30 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
  31 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
  
  Note
  -----
  -"PLAN_TABLE' is old version
  {code}
  
  
  * tkprof 1 *.
  {code}
  
  TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009
  
  Copyright (c) 1982, 2005, Oracle. All rights reserved.
  
  Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
  Sorting options: by default
  
  ********************************************************************************
  Count = number of times OIC procedure has been executed
  CPU = time in seconds cpu execution
  elapsed = elapsed time in seconds the execution
  disc = number of physical reads from disk buffers
  Query = number of buffers for a consistent reading
  current = number of buffers in current mode (usually for the update)
  rows = number of rows processed by extracting or execute the call
  ********************************************************************************
  
  SELECT sdu.u_crop_group,
  SD. Name as sdg_name,
  ad.variety_name,
  ad.batch_number,
  B.SID as aliquot_name,
  Sau.u_box_code as box_code,
  Sau.u_box_position as box_position,
  t.Nom as test_name,
  r.original_result,
  PLT. Name as plate_name,
  Concat (chr (a.plate_row + 64), a.plate_column) as plate_position,
  au.u_replicate_number as replicate_number
  OF lims_sys.sdg sd,.
  lims_sys.sdg_user STO,
  lims_sys. Sample his.
  lims_sys.sample_user sau,
  lims_sys.aliquot has,
  to the lims_sys.aliquot_user,.
  lims_sys.test t,
  lims_sys. Result r,
  PLT lims_sys.plate,
  Ad lims_sys.abs_determination
  WHERE sd.sdg_id = sdu.sdg_id
  AND sd.sdg_id = sa.sdg_id
  AND sa.sample_id = sau.sample_id
  AND sau.sample_id = a.sample_id
  AND a.aliquot_id = au.aliquot_id
  AND au.aliquot_id = t.aliquot_id
  AND t.test_id = r.test_id
  AND plt.plate_id (+) = a.plate_id
  AND sdu.u_abs_determination = ad.determination_assignment
  AND a.status IN ('V', 'P', 'C')
  AND r.name = 'result '.
  AND sdu.u_client_type = "QC".
  AND sdu.u_year_of_sample_delivery = (: year)
  AND sdu.u_week_of_processing = (: week)
  - AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
  ORDER BY box_code, box_position, replicate_number
  
  call the query of disc elapsed to cpu count current lines
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Parse 1 0.00 0.00 0 0 0 0
  Run 1 1.15 1.16 0 0 0 0
  Fetch 1 8.53 16.10 227649 241266 0 500
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Total 3 9.68 17,27 227649 241266 0 500
  
  Chess in the library during parsing cache: 1
  Lack in the library during execution cache: 1
  Optimizer mode: ALL_ROWS
  The analysis of the user id: 97
  
  Rows Row Source operation
  ------- ---------------------------------------------------
  SORT ORDER BY 500 (cr = 241266 pr = 227649 pw = time 0 = 16104631 en)
  FILTER 21311 (cr = 241266 pr = 227649 pw = time 0 = 16246749 en)
  21311 HASH JOIN (cr = 241266 pr = 227649 pw = time 0 = 16225434 en)
  17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr = 374 pr = 0 pw = time 0 = 69 fr)
  21311 HASH JOIN RIGHT OUTER (cr = 240892 pr = 227649 pw = time 0 = 16170607 en)
  21895 VIEW PLATE (cr = 316 pr = 0 pw = time 0 = 43825 US)
  21895 FILTER (cr = 316 pr = 0 pw = time 0 = 43823 US)
  21895 TRAY FULL ACCESS (cr = 316 pr = 0 pw = time 0 = 31 US)
  0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
  21311 HASH JOIN (cr = 240576 pr = 227649 pw = time 0 = 16106174 en)
  21311 HASH JOIN (cr = 133559 pr 121596 pw = time = 0 = 9594130 en)
  21311 HASH JOIN (cr = 94323 pr = 83281 pw = time 0 = 6917067 en)
  21311 HASH JOIN (cr = 86383 pr 75547 pw = time = 0 = 5509672 en)
  JOIN by HASH 7776 (cr = 8134 pr = 0 pw = time 0 = 285364 en)
  TABLE ACCESS BY INDEX ROWID SAMPLE 7776 (cr = 572 pr = 0 pw = time 0 = 27152 US)
  7876 NESTED LOOPS (cr = 377 pr = 0 pw = time 0 = 488287 en)
  JOIN by HASH 99 (cr = 160 pr = 0 pw = time 0 = US 4168)
  99 TABLE ACCESS FULL SDG_USER (cr = 53 pr = 0 pw = time 0 = US 1209)
  5719 TABLE ACCESS FULL SDG (cr = 107 pr = 0 pw = time 0 = 17 US)
  7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr = 217 pr = 0 pw = time 0 = 623 en)(object id 45990)
  1079741 TABLE ACCESS FULL SAMPLE_USER (cr = 7562 pr = 0 pw = time 0 = 24 US)
  3307948 TABLE ALIQUOT FULL ACCESS (cr = 78249 pr = pw 75547 time = 0 = 3331129 en)
  3406836 TABLE ACCESS FULL ALIQUOT_USER (cr = 7940 pr 7734 pw = time = 0 = 556 en)
  3406832 TABLE TEST FULL ACCESS (cr = 39236 pr 38315 pw = time = 0 = 3413192 en)
  3406832 TABLE ACCESS FULL RESULTS (cr = 107017 pr = 106053 pw = time 0 = 6848487 en)
  0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
  0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
  0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
  0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
  
  ********************************************************************************
  
  Select 'x '.
  Of
  Double
  
  
  call the query of disc elapsed to cpu count current lines
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Parse 1 0.00 0.00 0 0 0 0
  Run 1 0.00 0.00 0 0 0 0
  Fetch 1 0.00 0.00 0 0 0 1
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Total 3 0.00 0.00 0 0 0 1
  
  Chess in the library during parsing cache: 0
  Optimizer mode: ALL_ROWS
  The analysis of the user id: 97
  
  Rows Row Source operation
  ------- ---------------------------------------------------
  1 DOUBLE QUICK (cr = 0 pr = 0 pw = time 0 = 3 US)
  
  ********************************************************************************
  
  Start: id: = sys.dbms_transaction.local_transaction_id; end;
  
  
  call the query of disc elapsed to cpu count current lines
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Parse 1 0.00 0.00 0 0 0 0
  Run 1 0.00 0.00 0 0 0 1
  Fetch 0 0.00 0.00 0 0 0 0
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Total 2 0.00 0.00 0 0 0 1
  
  Chess in the library during parsing cache: 0
  Optimizer mode: ALL_ROWS
  The analysis of the user id: 97
  
  
  
  ********************************************************************************
  
  TOTALS FOR ALL NON RECURSIVE INSTRUCTIONS
  
  call the query of disc elapsed to cpu count current lines
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Parse 3 0.00 0.00 0 0 0 0
  Run 3 1.15 1.16 0 0 0 1
  Pick 2 8.53 16.10 227649 241266 0 501
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Total 8 9.68 17,27 227649 241266 0 502
  
  Chess in the library during parsing cache: 1
  Lack in the library during execution cache: 1
  
  
  TOTALS FOR ALL RECURSIVE INSTRUCTIONS
  
  call the query of disc elapsed to cpu count current lines
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Parse 30 0.00 0.00 0 0 0 0
  Run 30 0.00 0.00 0 0 0 0
  Get 30 0.00 0.00 0 40 0 10
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Total 90 0.00 0.00 0 40 0 10
  
  Chess in the library during parsing cache: 0
  
  3 the session user SQL statements.
  30 internal to SQL statements in session.
  33 SQL statements in session.
  ********************************************************************************
  Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
  Compatibility of trace files: 10.01.00
  Sorting options: by default
  
  8 sessions in the trace file.
  3 SQL statements of the user in the trace file.
  30 internal SQL instructions in the trace file.
  33 SQL statements in the trace file.
  6 unique SQL statements in the trace file.
  633 lines in the trace file.
  23 seconds in the trace file.
  {code}

  ZI wrote:
  I have a statement with a decoding function in the where clause like this:

  AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
  

  When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.

  I would interpret the results displayed differently.

  Execution which took 17 s according to the 241 266 coherent block played tkprof output gets but in order to do so he read 227 649 the disk blocks. Note that most of the table addressed by this query blocks were read through scanning of complete table that can take advantage of multiple blocks readings, for example if you unset the db_file_multiblock_read_count 10.2 (recommended) it usually try to read 1 MB with a read request, which are 128 blocks in case of standard block size 8 k. Due to several reasons not always the full size can be requested with each read request, lets say about 200 000 blocks could have been read by about 2,000 blocks multiple readings. Each read request would turn into a physical read, could you get an estimate approximate 25 MS per read times 2,000 applications-online 50 seconds (your system is running obviously better that the average assumed by ost g 10 base optimizer without collected statistics system workload, can be that some additional file caching system is involved).

  On the other hand, the execution plan that finished within 2 seconds completed 221 420 coherent block gets but did No physical reads at all. Note that most of the table blocks should be processed using one-piece random searches (ACCESS BY ROWID of the TABLE), according to the grouping of the indices factor, it could have been as many blocks that the lines have been returned to the range index scans. So you could have done with lets say more than 60,000 randomly accessed table blocks => until 60 000 monobloc required reading. So in the worst case, this may take 60 000 requests time 10ms by read-online 600 seconds, even if in reality at least some of the blocks will be stored in the buffer cache, so it should be less.

  It would be interesting to know how these two declarations with a cold buffer cache, so that both had to physical reads. I suppose the first is actually faster. Of course, if the second corresponds more to your typical situation that most of the blocks is in the buffer anyway, then it could be faster, because the blocks read by random access are more likely to stay in memory blocks read by complete sweep of the table, but in a true perspective of I/O the first is expected to be higher.

  Moreover, the change in the plan is probably caused by the fact that the additional predicate (DECODING) lowers the cardinality of the table of SDG_USER conduct so that LOOP IMBRIQUEE approach seems to be cheaper to the optimizer that the hash join/full scan table approach. Apparently the estimate is way off (by two orders of magnitude, in fact 100 instead of 1), then the plan is not really cheap, because it seems like the optimizer.

  By the way: two actual execution plans displayed in the output from tkprof are actually different from the displayed output of EXPLAIN the PLAN, so the statement has executed a little differently provided the facility to EXPLAIN the PLAN.

  Your PLAN_TABLE is old, since you are on 10g you should drop any PLAN_TABLEs that are in non - SYS diagrams, since 10 g already provides a global temporary Table as part of the default dictionary (SYS. Plan_table$ presentations via public synonym PLAN_TABLE).

  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/

• How can I show all the results returned by a sql query?

  Hi guys,.
  
  I need your help.
  Let's say I have a table: TableA. Fields in TableA are aleg, anon, monkeys. The following sentence can return, in general, several rows: select anon from TableA where aleg = somevalue. I would like to show the result of the anon column but no luck. If I try to display the results in a TextArea and the origin is a sql query shows that the first value of the line. I tried to see the like: display text (based in PLSQL) and a block anonymous plsql and coding
  DECLARE
  v_anon TableA.anon%TYPE;
  CURSOR v_cur IS
  Select anon from TableA where aleg = somevalue;
  BEGIN
  OPEN v_cur.
  LOOP
  SEEK v_cur INTO v_anon;
  EXIT WHEN v_cur % NOTFOUND;
  : FIELD_IN_FORM: = v_anon;
  END LOOP;
  CLOSE V_cur;
  END;
  but in this case, he showed no results.
  So the first question is what type of field can I use to show the result. And the second is what can I do to be able to show all the results returned by the query (if more than one line).
  
  concerning

  GMC

  We are all happy that you found a solution, but you must sign your messages and change your ID forum. It is always good to know the real name of the person you are communicating with. In addition, if you plan to get answer to your questions in the future, you must mark responses as useful or correct if they helped you solve your problems.

  Denes Kubicek
  -------------------------------------------------------------------
  http://deneskubicek.blogspot.com/
  http://www.Opal-consulting.de/training
  http://Apex.Oracle.com/pls/OTN/f?p=31517:1
  -------------------------------------------------------------------

• On Google, Ffox 3.6.12 shows only 10 results even when I specify 100; Mac G4 10.4.11. other browsers show 100 without problem.

  On my Mac G4 two-way to 1.25 GHz Power PC with OS X 10.4.11 and Firefox 3.6.12, when I opened Google and specify 100 results like this...

  http://www.Google.com/advanced_search?hl=en & num = 100

  .. .it always shows just 10 results. While Opera and Safari (I don't use Internet Extorter) show 100 results no problem to use this URL.

  Problem was occurring at least since Firefox 3.6.9 if I remember correctly. Not sure if it was going on before that.

  Google has recently made a few changes on the site to Google search with the addition of instant search and who made the adjustment of the number of results in the settings of Google to stop working.

  If Instant Search is enabled in the settings of Google search page (link at the top right) then you get only 10 results.
  
  You must disable Instant Search and reload the result page, and then set the number of results to your preferred choice.
  
  It may not work if you change both at the same time.

  There is a link directly to the right of the Google search box on the Google results page.

  It's a button with a drop-down list: moment is On / Off.

  There is also a radio check box in the page settings of Google, which has replaced the previously used Suggestions.

  • http://www.Google.com/preferences?hl=en