Comments on: Oracle 11g Adaptive Cursor Sharing (ACS)

By: Amiel Davis

Amiel Davis — Thu, 14 Apr 2011 19:00:33 +0000

Update:
a. The 11.2 “Oracle® Database Performance Tuning Guide” state it clearly:

“…Adaptive cursor sharing is enabled for the database by default and cannot be disabled. Note that adaptive cursor sharing does not apply to SQL statements containing more than 14 bind variables…”

http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/optimops.htm#sthref874

looked in older documentation, and didn’t find it..

b. Great blog, keep up the good work!

Amiel Davis

By: Aychin

Aychin — Mon, 04 Apr 2011 20:54:20 +0000

Hi, very interesting article! Thank You for spending Your time to share it! Please review my thoughts about ACS on http://aychin.wordpress.com/2011/04/04/adaptive-cursor-sharing-and-spm/ it will be very interesting to me to hear Your opinion about this issue. Thank You again!

By: Jeff

Jeff — Wed, 23 Feb 2011 13:27:49 +0000

Update: Oracle believes it is due to the driver the app is using (ver 1 INet Seropto: http://www.inetsoftware.de/products/jdbc-driver/oracle/seropto). They believe the driver is not ‘passing the bind variables correctly for the compile parse’ – their words.

I’ve patched up the problem using SQL Profiles, but I have to wait till July/Aug so App team can update to latest Oracle JDBC drivers.

It seems odd that the CBO would care how the parms are passed.

By: Jeff

Jeff — Sat, 29 Jan 2011 01:58:41 +0000

The interesting thing is our Java app makes heavy use of binds and not one SQL is bind aware according to V$SQL (out of 15k SQLs!) . Good news is ODM guys were able to reproduce this but haven’t been able to explain it so far. Sometimes thats half the battle!

By: osborne

osborne — Tue, 25 Jan 2011 23:23:44 +0000

Thanks for the kind words Jeff. Pleas let me know what response you get to the SR. I expected this would be addressed in fairly short order but to be honest I have not tested with 11.2.0.2 yet, but I did test 11.2.0.1 and it did appear that the same limitation was in place in that release.

Kerry

By: Jeff

Jeff — Tue, 25 Jan 2011 18:01:06 +0000

Excellent article. We’re running Exadata 11gR2 (11.2.0.1.0) and I’ve encountered the same issue with some SQL that has 21 bind vars. I had a hunch that we had a BP issue, but your work here saved me a lot of time in proving it out. I’ve created an SR and I’m curious what they come back with. Thanks for your contributions to the Exadata community!

By: osborne

osborne — Fri, 22 Oct 2010 03:23:22 +0000

Well I don’t think ACS really solves the problem, so yes disabling peeking via setting _optim_peek_user_binds=false is still a viable option in my opinion.

Kerry

By: Mark

Mark — Tue, 19 Oct 2010 22:03:03 +0000

Hi Kerry,
In my 9i system I turned off the bind peeking. That was actually a recommendation from Oracle support which made sense to me. My app had a combination of SQLs with literals and bind variables. The idea was, those with literals would benefit from histograms, those with bind variables would be protected from plan instability.
I didn’t see you mentioning this approach at all. What’s your opinion on disabling bind peeking in 11g instead of relying on ACS?

By: osborne

osborne — Wed, 13 Oct 2010 20:25:41 +0000

I was trying to show why ACS doesn’t always solve our Bind Variable Peeking issues. One of the main issues was that statements that have over 14 bind variables don’t appear to ever be marked as bind sensitive. (i.e. ACS never evaluates them at all) This was done on 11.1.0.7 so the behavior may change with subsequent releases. There is really no relation between this and the number of child cursors that get created for a statement – whether it is marked as bind aware or not.

Kerry

By: hank

hank — Wed, 13 Oct 2010 15:12:05 +0000

Hi Kerry

i found something from ORACLE docs and it says :

The management of private SQL areas is the responsibility of the user process. The allocation and deallocation of private SQL areas depends largely on which application tool you are using, although the number of private SQL areas that a user process can allocate is always limited by the initialization parameter OPEN_CURSORS. The default value of this parameter is 50.

isn’t it what you are figuring out?