Professional Documents
Culture Documents
Library Cach Lock
Library Cach Lock
Library Cach Lock
Page 1 of 12
PowerView is On
Type: TROUBLESHOOTING
Status: PUBLISHED
Priority: 1
In this Document
Purpose
Ask Questions, Get Help, And Share Your Experiences With This Article
Troubleshooting Steps
What is a 'High' Version Count?
What is shared SQL ?
What is 'SQL Metadata'?
Why should I be concerned about 'High' Versions?
How do I see the versions and why they are not shared ?
What do the reasons given in v$SQL_SHARED_CURSOR mean?
Version_rpt script:
What further tracing is available.
Are there any times when a high version count is expected even though BINDS are being used?
Explanation:
Enhancement to obsolete parent cursors if Version Count exceeds a threshold
High Version Count with Adaptive Cursor Sharing
Troubleshooting Other Issues
Discuss High Version Count Issues
References
Applies to:
Oracle Database - Enterprise Edition - Version 10.2.0.1 and later
Oracle Database - Standard Edition - Version 10.2.0.1 and later
Oracle Database - Personal Edition - Version 10.2.0.1 and later
Information in this document applies to any platform.
Purpose
The Troubleshooting Guide is provided to assist in debugging SQL sharing issues. When possible, diagnostic tools are includ
troubleshooting problems. This document does not contain bugs/patches as these topics are addressed in the articles
document.
Ask Questions, Get Help, And Share Your Experiences With This Article
Would you like to explore this topic further with other Oracle Customers, Oracle Employees, and Industry
Dashboard
Knowledge
Service Requests
Community
Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this
Discover discussions about other articles and helpful subjects by clicking here to access the main My Oracle Support Comm
Tuning.
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 2 of 12
Troubleshooting Steps
What is a 'High' Version Count?
There is no definitive definition of what a 'High' number of versions for a particular cursor is, different systems may be able
versions, However, AWR reports start reporting versions over 20 for a particular cursor and so that is as good an indicator o
Once you start getting into the hundreds or thousands range, then these are definitely 'High' counts and the causes should
reduced so as to encourage the SQL to be shared.
We now create a parent cursor for this sql and a single child. It does not matter that a SQL statement may never be shared
and a single child are created. The easy way to think of this is that the PARENT cursor is a representation of the hash value
the metadata for that SQL
Metadata is all the information which enables a statement to run. For instance, in the example I have given EMP is
OBJECT_ID which points to the EMP table owned by this user. When the user SCOTT logged in, optimizer parameters are in
the statement, so this too is used by the optimizer and is therefore metadata. There are other examples of Metadata which
document.
Let's say this session logs out and back in again now. It then runs the same command again (as the same user). This time w
shared pool (but we don't know this yet). What we do is hash the statement and then search for that hash value in the shar
search through the children to determine if any of them are usable by us (ie the metadata is the same). If it is, then
I would still have one version of that SQL in the shared pool because the metadata enabled me to share the statement with
fundementals are that the parent is not shared, it is the children which determine shareability.
Now - another user 'TEST' has it's own version of EMP. If that user was to now run the select statement above then what w
1.
2.
3.
4.
(Essentially, what happens here is that we have a linked list of children which we move through in turn, comparing the
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 3 of 12
of all the children. If there were 100 children then we would scan each of them (looking for a possible mismatch and moving
share. If we cannot share any (ie. have exhausted the list of children) then we need to create a new child)
5. We therefore have to create a new child - we now have 1 PARENT and 2 CHILDREN.
Unnecessary non-sharing of SQL, and the resultant versions of SQL, is a primary cause of library cache contention. Contenti
your database and, in extreme cases, can cause it to appear to 'hang'. When you have unnecessary versions of a cursor, ea
parse engine has to search through the list of versions to see which is the cursor that you want. This wastes CPU cycles tha
else.
How do I see the versions and why they are not shared ?
The easiest way to get version information in a clear format is to use the script in the following article:
Document 438755.1 High SQL Version Counts - Script to determine reason(s)
To find the reasons for mismatches see the following section: What do the reasons given in v$SQL_SHARED_CURSOR mean
If you are unable to use that script then you can select the same information from the base views as illustrated in the exam
Lets use the example above and take a look at what SQL we can use to see this in the shared pool.
SCOTT runs select count(*) from emp
I can now run the following to see the PARENT statement and it's hash value and address
select sql_text, hash_value,address from v$sqlarea where sql_text like 'select count(*) from emp%';
SQL_TEXT
HASH_VALUE
ADDRESS
------------------------ ------------ ---------------select count(*) from emp 4085390015
0000000386BC2E58
To see the CHILDREN (I expect to see 1 at this point) : Version 9.2.X.X and below :
select * from v$sql_shared_cursor where kglhdpar = '0000000386BC2E58'
Output:
ADDRESS
KGLHDPAR
U S O O S L S E B P I S T A B D L T R I I R L I O S M U T N F
---------------- ---------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0000000386BC2D08 0000000386BC2E58 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
ADDRESS
---------------0000000386BC2D08
0000000386A91AA0
Page 4 of 12
KGLHDPAR
---------------0000000386BC2E58
0000000386BC2E58
U
N
N
S
N
N
O
N
N
O
N
N
S
N
N
L
N
N
S
N
N
E
N
N
B
N
N
P
N
N
I
N
N
S
N
N
T
N
N
A
N
Y
B
N
N
D
N
N
L
N
N
T
N
Y
R
N
N
I
N
N
I
N
N
R
N
N
L
N
N
I
N
N
O
N
N
S
N
N
M
N
N
U
N
N
T N F
N N N
N N N
We can now see the 2nd child ( 0000000386A91AA0) and also the reasons why it could not be shared with the first (The 'Y'
are:
(1) AUTH_CHECK_MISMATCH and
(2) TRANSLATION_MISMATCH
This is because the objects under my new user do not map to those of SCOTT (the current child). A mismatch occurs becau
and translation fails since we have different object_ids for the objects in each of our schemas.
(The same applies with events - if I turned on tracing with 10046 than I would get the OPTIMIZER_MISMATCH again
It is possible to see more details for the reason using cursortrace. Something like the following will be see:
2 = In (RAC) cases where instance count is not the same, or session CPU count is not the same, or thread count is no
3 = _parallel_syspls_obey_force is FALSE
4 = The PQ mode does not match.
5 = The degree does not match.
6 = The parallel degree policy does not match.
7 = The session limit is not the same as the cursor limit but the cursor limit is the same as the degree used.
8 = The cursor limit is greater than the degree used and the session limit is less than the cursor limit
9 = The cursor limit is less than the degree used and the session limit is not the same as the cursor limit
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 5 of 12
--> Would create a 2nd child as the outline used is different than the first run.
STATS_ROW_MISMATCH - The existing statistics do not match the existing child cursor. Check that 10046/sql_trace
can cause this.
LITERAL_MISMATCH - Non-data literal values do not match the existing child cursor
SEC_DEPTH_MISMATCH - Security level does not match the existing child cursor
EXPLAIN_PLAN_CURSOR - The child cursor is an explain plan cursor and should not be shared. Explain plan statemen
default - the mismatch will be this.
BUFFERED_DML_MISMATCH - Buffered DML does not match the existing child cursor
PDML_ENV_MISMATCH - PDML environment does not match the existing child cursor
INST_DRTLD_MISMATCH - Insert direct load does not match the existing child cursor
SLAVE_QC_MISMATCH -The existing child cursor is a slave cursor and the new one was issued by the coordinator (or
issued by the coordinator and the new one is a slave cursor).
TYPECHECK_MISMATCH - The existing child cursor is not fully optimized
AUTH_CHECK_MISMATCH - Authorization/translation check failed for the existing child cursor
The user does not have permission to access the object in any previous version of the cursor. A typical example woul
copy of a table
**BIND_MISMATCH - The bind metadata does not match the existing child cursor. For example:
variable a varchar2(100);
select count(*) from emp where ename = :a ->> 1 PARENT, 1 CHILD
variable a varchar2(400);
select count(*) from emp where ename = :a ->> 1 PARENT, 2 CHILDREN
(The bind 'a' has now changed in definition)
DESCRIBE_MISMATCH - The typecheck heap is not present during the describe for the child cursor
LANGUAGE_MISMATCH - The language handle does not match the existing child cursor
TRANSLATION_MISMATCH - The base objects of the existing child cursor do not match.
The definition of the object does not match any current version. Usually this is indicative of the same issue as
object is different.
ROW_LEVEL_SEC_MISMATCH - The row level security policies do not match
INSUFF_PRIVS - Insufficient privileges on objects referenced by the existing child cursor
INSUFF_PRIVS_REM - Insufficient privileges on remote objects referenced by the existing child cursor
REMOTE_TRANS_MISMATCH - The remote base objects of the existing child cursor do not match
USER1: select count(*) from table@remote_db
USER2: select count(*) from table@remote_db
(Although the SQL is identical, the dblink pointed to
by remote_db may be a private dblink which resolves
to a different object altogether)
LOGMINER_SESSION_MISMATCH
INCOMP_LTRL_MISMATCH
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 6 of 12
New in 11g :
PLSQL_DEBUG - debug mismatch Session has debugging parameter plsql_debug set to true
LOAD_OPTIMIZER_STATS - Load optimizer stats for cursor sharing
ACL_MISMATCH - Check ACL mismatch
FLASHBACK_ARCHIVE_MISMATCH - Flashback archive mismatch
LOCK_USER_SCHEMA_FAILED - Failed to lock user and schema
REMOTE_MAPPING_MISMATCH - Remote mapping mismatch
LOAD_RUNTIME_HEAP_FAILED - Runtime heap mismatch
HASH_MATCH_FAILED - Hash mismatch
Set to "Y" if sharing fails due to a hash mismatch, such as the case with mismatched histogram data or a
replacement (See Bug 3461251)
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 7 of 12
New in 11.2 :
PURGED_CURSOR - cursor marked for purging
The cursor has been marked for purging with dbms_shared_pool.purge
BIND_LENGTH_UPGRADEABLE - bind length upgradeable
Could not be shared because a bind variable size was smaller than the new value beiing inserted
(marked as
Version_rpt script:
The script version_rpt can also be run to produce a summary report of the v$sql_shared_cursor view with additional diagnos
found in:
Document 438755.1 High SQL Version Counts - Script to determine reason(s)
(level 578/580 can be used for high level tracing (577=level 1, 578=level 2, 580=level 3)
This will write a trace file to user_dump_dest each time we try to reuse the cursor.
To turn off tracing use:alter system set events
'immediate trace name cursortrace level 2147483648, address 1';
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 8 of 12
Please note: Bug 5555371 exists in 10.2 (fixed in 10.2.0.4) where cursor trace cannot fully be turned off and single line entr
file as a result. The w/a is to restart the instance. How invasive this BUG is depends on the executions of the cursor (and
additions)
In 11.2 there is also cursordump:
alter system set events 'immediate trace name cursordump level 16'
(please ensure system , not session, is used as the level meaning changes)
This dumps some additional information such as expanding on the parameters for 'optimizer_mismatch' issues.
Are there any times when a high version count is expected even though BINDS are being used?
Consider the following where cursor_sharing=SIMILAR
select
select
select
select
select
/*
/*
/*
/*
/*
TEST
TEST
TEST
TEST
TEST
*/
*/
*/
*/
*/
*
*
*
*
*
from
from
from
from
from
emp
emp
emp
emp
emp
where
where
where
where
where
sal
sal
sal
sal
sal
>
>
>
>
>
100;
101;
102;
103;
104;
SELECT sql_text,version_count,address
FROM V$SQLAREA
WHERE sql_text like 'select /* TEST */%';
SELECT * FROM V$SQL_SHARED_CURSOR WHERE kglhdpar = '&my_addr';
You will see several versions , each with no obvious reason for not being shared
Explanation:
One of the cursor sharing criteria when literal replacement is enabled with cursor_sharing as similar is that bind value should
execution plan is going to change depending on the value of the literal. The reason for this is we _might_ get a sub
This would typically happen when depending on the value of the literal optimizer is going to chose a different plan. Thus in
with > , if this was a equality we would always share the same child cursor. If application developers are ready to live with a
memory , then they need to set the parameter to force.
"The difference between SIMILAR and FORCE is that SIMILAR forces similar statements to share the SQL area without deter
Setting CURSOR_SHARING to FORCE forces similar statements to share the SQL area potentially deteriorating execution pla
It is also possible to tell from 10046 trace (level 4/12 - BINDS) if a bind is considered to be unsafe
The flag oacfl2 in 9i and fl2 in 10g will show if a variable is unsafe.
BINDS #2:
bind 0: dty=2
offset=0
bfp=1036d6408
value=16064
bind 1: dty=2
offset=0
bfp=1036d4340
In 10g (10.2.0.5) and 11g using the example query above this looks like:
alter session set cursor_sharing=force;
alter session set events '10046 trace name context forever,level 12';
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 9 of 12
The "fl2=0300" entry indicates that this is and Unsafe literal and the bind was generated by replacement :
#define UACFBLTR 0x00000100 /* Bind was generated by LiTeRal replacement */
#define UACFUNSL 0x00000200 /* UNSafe Literal */
The 0x200 entry being the important flag for determination of literal 'safety'.
For additional details on this topic see:
Document 377847.1 Unsafe Literals or Peeked Bind Variables
Document 261020.1 High Version Count with CURSOR_SHARING = SIMILAR or FORCE
In 11gr2, an issue of Child cursors growing very long was introduced. An enhancement request was filed to address this iss
cursors grow beyond certain count be it 20 or 100, it obsoletes the parent cursors. In order to activate this enhancement b
1. If 11.2.0.3 and above, set the following parameters:
"_cursor_obsolete_threshold"
For more information, please read the following article regarding the enhancement involved:
Document 10187168.8 Enhancement to obsolete parent cursors if Version Count exceeds a threshold
With introduction of adaptive cursor sharing in 11g, there may be increased version count due to more child cursors. The
adapt execution plans, depending on the selectivity of the bind variable. For more information on adaptive cursor sharing, p
Document 740052.1 Adaptive Cursor Sharing Overview
Some known issues with Adaptive Cursor Sharing Overview:
Document 7213010.8 Bug 7213010 - Adaptive cursor sharing generates lots of child cursors
Document 8491399.8 Bug 8491399 - Adaptive Cursor Sharing does not match the correct cursor version for queries using
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 10 of 12
The window below is a live discussion of this article (not a screenshot). We encourage you to join the discuss
below for the entry you would like to provide feedback on. If you have questions or implementation issues w
article above, please share that below.
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 11 of 12
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013
Document 296377.1
Page 12 of 12
References
NOTE:377847.1 - Unsafe Literals or Peeked Bind Variables
Related
Products
Oracle Database Products > Oracle Database > Oracle Database > Oracle Database - Enterprise Edition > RDBMS > Database Level Perform
Oracle Database Products > Oracle Database > Oracle Database > Oracle Database - Standard Edition > Generic RDBMS > Database Level
Oracle Database Products > Oracle Database > Oracle Database > Oracle Database - Personal Edition > RDBMS > Database Level Performa
Keywords
BIND_MISMATCH; COUNT; CURSOR SHARING; CURSOR_SHARING; HIGH VERSION COUNT; LANGUAGE_MISMATCH; OPTIMIZER_MISMATCH
TROUBLESHOOT; V$SQL_SHARED_CURSOR; VERSION
Back to Top
Copyright (c) 2013, Oracle. All rights reserved.
Privacy Statement
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824... 11.06.2013