However – the UNION / DISTINCT: if you take out the DISTINCT and turn the UNION into a UNION ALL, you will have changed the logic of the query: so, unless the need for uniqueness was an error, you can’t make those changes.

Note – you haven’t mentioned the version of Oracle, but most versions will postpone the DISTINCT operator, by doing a UNION ALL and then applying the SORT UNIQUE.

As far as setting session_cached_cursors is concerned, a simple guideline is to incrase it until the statistics about cached cursors suggest that you will get minimal extra benefit from incrasing the cache further. One way of viewing this is to see if the lots of sessions have reached the limit, and are still doing lots of parses which are not “parse count (hard)”.

I have a database with following behaviour.

only one SELECT statement is using 60% CPU, all other looks normal using 3-4-5% I dig more in to that SELECT statement and found it has SELECT DISTINCT….. UNION SELECT DISTINCT… kind format. After looking at Execution plan, I see all steps are using CPU normally excepting last statement ( In order of execution) SORT UNIQUE is spending 85% CPU out of 100% CPU for that statement.

There is some suggestion like use UNION ALL instead of UNION, dont use DISTINCT.

Second thing is, I thought to check how that statement is parse and executed. That statement was executed 4000 times, hardparse 1 time and soft parse 3999. It means it is doing soft parsing each time it execute it. SO question is how to resuce that part. I think that is causing some Library Cache, as I see that in AWR report as top 5 events.

ThenI thought to look at SESSION_CACHE_CURSORS, which is set to 150. In AWR, session cursor cache hits -67350 142.01 8.04 , this is based on 8 minute of AWR.

Now how to find out weather SESSION_CACHED_CURSORS is set to appropriate or needs to increase it. Please provide some direction about how to decide/tune SESSION_CACHE_CURSORS ?

We can not change application because it is third party application. how to tune this.

Please provide some lights on this topic.

Thanks

Looks like you still haven’t read the blog. Here’s a quote from Don Burleson’s own entry on his own forum (from 15th June 2005 until at least 4th Nov 2007):

“Now I haven’t had time to pour-over this AWR report in-detail, but I’m inclinded to agree in this case, that manual assignment of db_cache_size is appropriate.

Here is the report:
http://www.dbaoracle.com/reports/awr_report1.doc

I don’t think many people would read that and say that the intent was for the report to remain private. (The link no longer works – as I pointed out when I updated my blog entry)

By 11th Nov 2007 that comment had been edited out from Burleson’s posting, and from a posting by another user who had quoted that part of Burleson’s post.

Just because someone leaves the front door open doesn’t mean its legal for you to go in and sleep on the couch.

You only have to read this sentence from the blog to recognise the flaw in your argument:

The report is a Word document (dated 2nd June 2005) at this URL, and it is referenced from this thread (dated 15th June 2005) on the Burlseon Consulting Oracle Forum;

Unfortunately this is true; and the difference between the setting and the actual average read size has been a problem to the optimizer for many years. (If you set a multiblock read size of 128, say, the optimizer would “adjust” this to a value around 40 for the purposes of doing the arithmetic – but who knows what might really happen at run-time ?).

The effect of the defaults for optimizer exec and optimizer read counts will cause the optimizer to increase the relative costs of tablescans. If you view this as Oracle Corp’s attempt to minimise the number of queries that do the wrong thing, it’s probably a good strategy. Moreover, if a query uses an indexed access path when it should be doing a tablescan, putting in hints to do tablescans is probably going to be a less fragile fix than trying to hint a query that does tablescans when it should be using indexes.

So it’s a compromise – but I think it’s probably a statistically wise compromise.

Best Regards,
Davide