Comments on: Oracle 11.2: Cursor Mutex S wait event and too many (2^30) child cursors

By: Pawel Wadas

Pawel Wadas — Sat, 25 May 2013 17:49:51 +0000

Thank you for posting this info Martin – it helped me a lot with similar problem :)

By: usn

usn — Mon, 22 Oct 2012 11:45:28 +0000

Stalin, there are many bugs in 11.2.0.2.x, including the diagnostics views, especially v$sql_shared_cursor.

Try to upgrade or at least to reproduce on 11.2.0.3.x, you probably will be surprised.

By: Stalin

Stalin — Thu, 18 Oct 2012 21:43:34 +0000

Hi Martin, We are having similar problem in one of busy production database running 11.2.0.2.4 . Running the version_rpt script from MOS, i see that for the interested SQL with bind_mismatch... Cols 1,2,3 are timestamp datatype columns. Are they having differences in the precision/scale? Snip from output. Versions Summary ---------------- AUTH_CHECK_MISMATCH :199 BIND_MISMATCH :191 TRANSLATION_MISMATCH :199 ROLL_INVALID_MISMATCH :201 PURGED_CURSOR :176 Total Versions:200 Plan Hash Value Summary ----------------------- Plan Hash Value Count =============== ===== 1376985012 200 Details for BIND_MISMATCH : Consolidated details for : BIND_MISMATCH,USER_BIND_PEEK_MISMATCH,BIND_UACS_DIFF and BIND_EQUIV_FAILURE (Mislabled as ROW_LEVEL_SEC_MISMATCH BY bug 6964441 in 11gR1) from v$sql_bind_capture COUNT(*) POSITION MIN(MAX_LENGTH) MAX(MAX_LENGTH) DATATYPE (PRECISION,SCALE) ======== ======== =============== =============== ======== ================ 113 1 11 11 180 (,9) 88 1 11 11 180 (,) 120 2 11 11 180 (,9) 81 2 11 11 180 (,) 170 3 11 11 180 (,9) 31 3 11 11 180 (,) 201 4 22 22 2 (,) 201 5 22 22 2 (,) 201 6 32 32 1 (,) SUM(DECODE(column,Y, 1, 0) FROM V$SQL IS_OBSOLETE IS_BIND_SENSITIVE IS_BIND_AWARE IS_SHAREABLE =========== ================= ============= ============ 0 159 0 159 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By: Craig

Craig — Mon, 03 Oct 2011 22:47:07 +0000

A workaround is to create a stored outline for the affected cursor using dbms_outln.create_outline(a,b) where a=sql_hash_value and b=child_number of the one of the child cursors associated with the one plan you wish to enforce.

By: usn

usn — Wed, 23 Feb 2011 21:35:53 +0000

(Un)fortunately I am no developer. From a DBA perspective, you have to avoid anything that makes a cursor different – in this case it has been different datatypes, coming from the default behaviour of the setter method for NULL, using VARCHAR2 as default datatype.

Hopefully an abstraction layer as Hibernate has built in this knowledge. You can check by tracing the query as described in http://www.usn-it.de/index.php/2010/08/05/oracle-11g-trace-particular-sql-id/

Martin

By: jetlag

jetlag — Wed, 23 Feb 2011 19:51:49 +0000

What would that translate to in Hibernate? We don’t do anything directly with the ojdbc code, and certainly not provider specific. I don’t see anything about setNull.NUMBER in the oracle jdbc javadoc. the closest i could find was a setNull(int paramIndex, int sqlType) method on the Oracle prepared statement class. Are you saying we might need to override the behavior of Hibernate setting up the calls to jdbc to use specific Oracle types when setting our parameters to null in the prepared statements?

By: Usn’s IT Blog » Oracle 11g trace particular SQL_ID

Usn’s IT Blog » Oracle 11g trace particular SQL_ID — Thu, 05 Aug 2010 15:44:02 +0000

[...] a follow-up of my last post, I learned that creating traces is much simpler in 11g than I expected it to be. Dion Cho and Tanel [...]