In this Document

Purpose

Scope

Details

APPLIES TO:

 

Oracle Database - Enterprise Edition -Version 10.1.0.2 and later

Oracle Database - Standard Edition -Version 10.1.0.2 and later

Oracle Database - Personal Edition -Version 10.1.0.2 and later

Information in this document applies to anyplatform.

PURPOSE

 

 Outline a reason why a SQL statement may havea PLAN_HASH_VALUE of zeroin V$SQL

 

SCOPE

 

 Thisinformation may assist people trying to understand details of statements inV$SQL

 

DETAILS

 

The V$SQL view externalises variousinformation about SQL statements that are being stored in the shared pool tousers and one of these is the PLAN_HASH_VALUE which is a reference to theaccess path that has been generated for the a query. This is usually a largenumber but sometimes it is zero. When you are looking at a DELETE or an INSERTwithout a query, then a zero PLAN_HASH_VALUE is quite normal as there is noplan. In these cases no access path has been calculated and none is needed.

 

However it is possible to sometimes see aSELECT with a zero PLAN_HASH_VALUE which is less easy to explain.

 

The main reason for this is  key to this is that the query uses bindvariables and the cursor has been parsed BUT the generation of an executionplan has been deferred until execution time since that is when the bind valueswill be supplied (which may have a significant bearing on the access pathgenerated). Until the query is 'bound' and executed, there is no plan and sothe PLAN_HASH_VALUE will be zero.

 

This can be illustrated through an example:

 

If we create a cursor containing a bindvariable parse it, but then do not execute it and do not link any bind valuesto it, then it will defer the parsing until execution time (when you supply thebinds). Here we have used DBMS_SQL.PARSE() to open a cursor using a test SQLstatement containing a bind variable: 'select dummy zero from dual where dummy> :x' :

 

SQL> declare

cursor_name INTEGER;

begin

cursor_name := dbms_sql.open_cursor;

DBMS_SQL.PARSE(cursor_name, 'select dummyzero from dual where dummy > :x', DBMS_SQL.NATIVE);

DBMS_SQL.CLOSE_CURSOR(cursor_name);

END;

/

 

PL/SQL procedure successfully completed.

 

At this point there is an entry placed in V$SQL for the parsed SQLstatement, but because the plan generation has been deferred, thePLAN_HASH_VALUE is zero:

 

 

SQL> select sql_id ,sql_text,PLAN_HASH_VALUE from v$sql where sql_text like 'sel%zero%';

 

SQL_ID

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

SQL_TEXT

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

PLAN_HASH_VALUE

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

...

fzgydxr7yjcxd

select dummy zero from dual where dummy> :x

0