library cach lock

8/10/2019 Library Cach Lock

1/12

Platform: Microsoft Windows (32-bit)PowerView is On

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 laterOracle Database - Standard Edition - Version 10.2.0.1 and laterOracle Database - Personal Edition - Version 10.2.0.1 and laterInformation in this document applies to any platform.

Purpose

The Troubleshooting Guide is provided to assist in debugging SQL sharing issues. When possible, diagnostic tootroubleshooting problems. This document does not contain bugs/patches as these topics are addressed in the adocument.

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

Click hereto join the discussion where you can ask questions, get help from others, and share your experiencDiscover discussions about other articles and helpful subjects by clicking hereto access the main My OracleTuning.

Troubleshooting: High Version Count Issues [ID 296377.1]

Modified: 07-Jun-2013 Type: TROUBLESHOOTING Status: PUBLISHED Priority: 1

Dashboard Service Requests Patches & Updates CommunityKnowledge Search Knowl

Page 1 of 12Document 296377.1

11.06.2013https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=1020824 ...


2/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

versions, However, AWR reports start reporting versions over 20 for a particular cursor and so that is as good a

Once you start getting into the hundreds or thousands range, then these are definitely 'High' counts and the careduced so as to encourage the SQL to be shared.

What is shared SQL ?

The first thing to remember is that all SQL is implicitly sharable. When a SQL statement is entered, the RDBMSstatement and that hash value then helps the RDBMS to easily find SQL already in the shared pool. It is not in tgreat detail, so let's just assume entering a series of text results in a hash value being created.

For instance :- 'select count(*) from emp' hashes to the value 4085390015

We now create a parent cursor for this sql and a single child. It does not matter that a SQL statement may nevand a single child are created. The easy way to think of this is that the PARENT cursor is a representation of th

the metadata for that SQL

What is 'SQL Metadata'?

Metadata is all the information which enables a statement to run. For instance, in the example I have given EMOBJECT_ID which points to the EMP table owned by this user. When the user SCOTT logged in, optimizer parathe statement, so this too is used by the optimizer and is therefore metadata. There are other examples of Metdocument.

Let's say this session logs out and back in again now. It then runs the same command again (as the same user

shared pool (but we don't know this yet). What we do is hash the statement and then search for that hash valusearch through the children to determine if any of them are usable by us (ie the metadata is the same). If it is,

I would still have one version of that SQL in the shared pool because the metadata enabled me to share the stafundementals 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

1. The statement is hashed - it is hashed to the value 40853900152. The SQL will be found in the shared pool as it already exists3. The children are scanned (at this point we have one child)4. Because the OBJECT_ID of the EMP table owned by TEST is different the OBJECT_ID owned by scott we hav

(Essentially, what happens here is that we have a linked list of children which we move through in turn, compar




3/12


4/12

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

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

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

0000000386A91AA0 0000000386BC2E58 N N N N N N N N N N N N N Y N N N Y N N N N 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

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 mismatchand translation fails since we have different object_ids for the objects in each of our schemas.

What do the reasons given in v$SQL_SHARED_CURSOR mean?

Below are the list of reasons as well as some worked examples (Those denoted by ** are the ones most often

UNBOUND_CURSOR - The existing child cursor was not fully built (in other words, it was not optimized)

SQL_TYPE_MISMATCH - The SQL type does not match the existing child cursor**OPTIMIZER_MISMATCH - The optimizer environment does not match the existing child cursor.For example:

select count(*) from emp; ->> 1 PARENT, 1 CHILD

alter session set optimizer_mode=ALL_ROWS

select count(*) from emp; ->> 1 PARENT, 2 CHILDREN

(The optimizer mode has changed and therefore

the existing child cannot be reused)

(The same applies with events - if I turned on tracing with 10046 than I would get the OPTIMIZER_MIS

It is possible to see more details for the reason using cursortrace. Something like the following will be se

Optimizer mismatch(12)

The number is brackets gives the reason why

1 = Degree used is not the default DOP

2 = In (RAC) cases where instance count is not the same, or session CPU count is not the same, or threa

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 us

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




5/12

10 = Optimizer mode difference

11 = Materialized View mismatch

12 = Optimizer environment mismatch (ie an optimizer parameter is different)

13 = Cardinality Feedback is use

OUTLINE_MISMATCH - The outlines do not match the existing child cursor

If my user had created stored outlines previously for this command and they were stored in seperate cat

running:-

alter session set use_stored_outlines = OUTLINES1;

select count(*) from emp;

alter session set use_stored_oulines= OUTLINES2;

select count(*) from emp;

--> 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 100can 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 cursorEXPLAIN_PLAN_CURSOR - The child cursor is an explain plan cursor and should not be shared. Explain p

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 cursorSLAVE_QC_MISMATCH -The existing child cursor is a slave cursor and the new one was issued by the coissued by the coordinator and the new one is a slave cursor).

TYPECHECK_MISMATCH - The existing child cursor is not fully optimizedAUTH_CHECK_MISMATCH - Authorization/translation check failed for the existing child cursorThe user does not have permission to access the object in any previous version of the cursor. A typical e

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 cursorTRANSLATION_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 iss

object is different.

ROW_LEVEL_SEC_MISMATCH - The row level security policies do not matchINSUFF_PRIVS - Insufficient privileges on objects referenced by the existing child cursorINSUFF_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




6/12

OVERLAP_TIME_MISMATCH - error_on_overlap_time mismatch

SQL_REDIRECT_MISMATCH - sql redirection mismatchMV_QUERY_GEN_MISMATCH - materialized view query generation

USER_BIND_PEEK_MISMATCH - user bind peek mismatch

TYPCHK_DEP_MISMATCH - cursor has typecheck dependenciesNO_TRIGGER_MISMATCH - no trigger mismatch

FLASHBACK_CURSOR - No cursor sharing for flashbackANYDATA_TRANSFORMATION - anydata transformation change

INCOMPLETE_CURSOR - incomplete cursor.When bind length is upgradeable (i.e. we found a child cursor that matches everythingelse except that the bind length is not long enough), we mark the old cursor is not usableand build a new one. This means the version can be ignored.

TOP_LEVEL_RPI_CURSOR - top level/rpi cursorIn a Parallel Query invocation this is expected behaviour (we purposely do not share)

DIFFERENT_LONG_LENGTH - different long length

LOGICAL_STANDBY_APPLY - logical standby apply mismatchDIFF_CALL_DURN - different call duration

BIND_UACS_DIFF - bind uacs mismatchPLSQL_CMP_SWITCHS_DIFF - plsql compiler switches mismatch

CURSOR_PARTS_MISMATCH - cursor-parts executed mismatch

STB_OBJECT_MISMATCH - STB object different (now exists) ROW_SHIP_MISMATCH - row shipping capability mismatch

PQ_SLAVE_MISMATCH - PQ slave mismatchCheck you want to be using PX with this reason code, as the problem could be caused by running lots ofPX. If you are on < 11i you may be hitting Bug:4367986

TOP_LEVEL_DDL_MISMATCH - top-level DDL cursorMULTI_PX_MISMATCH - multi-px and slave-compiled cursor

BIND_PEEKED_PQ_MISMATCH - bind-peeked PQ cursorMV_REWRITE_MISMATCH - MV rewrite cursorROLL_INVALID_MISMATCH - rolling invalidation window exceededThis is caused by the rolling invalidation capability in DBMS_STATS. The child cannot be shared as it's in

Document 557661.1 Rolling Cursor Invalidations with DBMS_STATS in Oracle10g

OPTIMIZER_MODE_MISMATCH - optimizer mode mismatchPX_MISMATCH - parallel query mismatch

If running 11.1.0.6 and RAC see Bug:7352775. Check that if (on each instance) parallel_instance_groups

MV_STALEOBJ_MISMATCH - mv stale object mismatch

FLASHBACK_TABLE_MISMATCH - flashback table mismatchLITREP_COMP_MISMATCH - literal replacement compilation mismatch

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 mismatchSet to "Y" if sharing fails due to a hash mismatch, such as the case with mismatched histogram data or

replacement (See Bug 3461251)




7/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 (mar

USE_FEEDBACK_STATS - cardinality feedback

Cardinality feedback is being used and therefore a new plan could be formed for the current execution.

BIND_EQUIV_FAILURE - The bind value's selectivity does not match that used to optimize the existing c

There is no longer ROW_LEVEL_SEC_MISMATCH in 11.2.

Version_rpt script:

The script version_rpt can also be run to produce a summary report of the v$sql_shared_cursor view with additi

found in:

Document 438755.1High SQL Version Counts - Script to determine reason(s)

Running the Script:Generate reports for all cursors with more than 100 versions using SQL_ID (10g and up):

select b.* from v$sqlarea a ,table(version_rpt(a.sql_id)) b where loaded_versions >=100;

-- Generate reports for all cursors with more than 100 versions using HASH_VALUE:

select b.* from v$sqlarea a ,table(version_rpt(null,a.hash_value)) b where loaded_versions

-- Generate the report for cursor with sql_id cyzznbykb509s:

select * from table(version_rpt('cyzznbykb509s'));

What further tracing is available.

In 10G it is possible to use CURSORTRACE to aid the investigation of why cursors are not being shared. This evsupport and the resultant trace file is undocumented. To get the trace for a particular SQL statement you first o

select from v$sqlarea). You then set the trace on using:-

alter system set events'immediate trace name cursortrace level 577, address hash_value';

(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';




8/12

Please note: Bug 5555371exists in 10.2 (fixed in 10.2.0.4) where cursor trace cannot fully be turned off and sifile as a result. The w/a is to restart the instance. How invasive this BUG is depends on the executions of the cuadditions)

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 /* TEST */ * from emp where sal > 100;





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 bindexecution plan is going to change depending on the value of the literal. The reason for this is we _might_ get aThis would typically happen when depending on the value of the literal optimizer is going to chose a different pl

with > , if this was a equality we would always share the same child cursor. If application developers are readymemory , 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 areaSetting CURSOR_SHARING to FORCE forces similar statements to share the SQL area potentially deteriorating e

It is also possible to tell from 10046 trace (level 4/12 - BINDS) if a bind is considered to be unsafeThe flag oacfl2 in 9i and fl2 in 10g will show if a variable is unsafe.

BINDS #2:

bind 0: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24

offset=0

bfp=1036d6408 bln=22 avl=04 flg=09

value=16064

bind 1: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24

offset=0

bfp=1036d4340 bln=22 avl=04 flg=09

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';




9/12

select /* TEST */ * from emp where sal > :"SYS_B_0"

END OF STMT

..

BINDS #3071441600:

Bind#0

oacdty=02 mxl=22(03) mxlc=00 mal=00 scl=00 pre=00

oacflg=10 fl2=0300frm=00 csi=00 siz=24 off=0

kxsbbbfp=295c96f0 bln=22 avl=03 flg=09

value=103

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.1Unsafe Literals or Peeked Bind VariablesDocument 261020.1High Version Count with CURSOR_SHARING = SIMILAR or FORCE

Enhancement to obsolete parent cursors if Version Count exceeds a threshold

In 11gr2, an issue of Child cursors growing very long was introduced. An enhancement request was filed to adcursors grow beyond certain count be it 20 or 100, it obsoletes the parent cursors. In order to activate this en

1. If 11.2.0.3 and above, set the following parameters:

"_cursor_obsolete_threshold" to 100 (this is the number of child cursor after which we ob

2. If 11.2.0.2.2, then set:

"_cursor_features_enabled" to 1026

event 106001 with value 100 (as the parameter _cursor_obsolete_threshold is not present)

For more information, please read the following article regarding the enhancement involved:

Document 10187168.8Enhancement to obsolete parent cursors if Version Count exceeds a threshold

High Version Count with Adaptive Cursor Sharing

With introduction of adaptive cursor sharing in 11g, there may be increased version count due to more child cuadapt execution plans, depending on the selectivity of the bind variable. For more information on adaptive cur

Document 740052.1Adaptive Cursor Sharing Overview

Some known issues with Adaptive Cursor Sharing Overview:

Document 7213010.8Bug 7213010 - Adaptive cursor sharing generates lots of child cursorsDocument 8491399.8Bug 8491399 - Adaptive Cursor Sharing does not match the correct cursor version for q




10/12

Troubleshooting Other Issues

For guidance troubleshooting other performance issues take a look at:

Document 1377446.1Troubleshooting Performance Issues

Discuss High Version Count Issues

The window below is a live discussion of this article (not a screenshot). We encourage you to oinbelow for the entry you would like to provide feedback on. If you have questions or implementati

article above, please share that below.




11/12




12/12

References

NOTE:377847.1- Unsafe Literals or Peeked Bind Variables

NOTE:438755.1- High SQL Version Counts - Script to determine reason(s)NOTE:557661.1- Rolling Cursor Invalidations with DBMS_STATS.AUTO_INVALIDATENOTE:261020.1- High Version Count with CURSOR_SHARING = SIMILAR or FORCE

Related

Products

Oracle Database Products> Oracle Database> Oracle Database> Oracle Database - Enterprise Edition> RDBMS> DatabasOracle Database Products> Oracle Database> Oracle Database> Oracle Database - Standard Edition> Generic RDBMS>Oracle Database Products> Oracle Database> Oracle Database> Oracle Database - Personal Edition> RDBMS> Database

Keywords

BIND_MISMATCH; COUNT; CURSOR SHARING; CURSOR_SHARING; HIGH VERSION COUNT; LANGUAGE_MISMATCH; OPTIMIZE

TROUBLESHOOT;V$SQL_SHARED_CURSOR;VERSION

Back to Top

Copyright (c) 2013, Oracle. All rights reserved.

Legal Notices and Terms of Use

Privacy Statement


library cach lock

Documents