Comments on: Stabilize Oracle 10G’s Bind Peeking Behaviour by Cutting Histograms

By: Alex Gorbachev

Alex Gorbachev — Wed, 18 Jun 2008 02:52:23 +0000

Well, there is no absolutely best approach aka silver bullet. Some environment are better off disabling bvp completely and some are fine just controlling histograms.

My most favorite would be to disable all workarounds unless there is very good reason to use them such as:
- _optim_peek_user_binds=false
- cursor_sharing=exact
- “FOR ALL COLUMNS SIZE 1″ followed by regular “FOR ALL COLUMNS SIZE REPEAT”
etc.

The first two workarounds in the list is for bad software while the third one is for “unusual” data.

So both BVP and histograms are evil but there is an exception for every rule. ;-)

By: Alex Fatkulin

Alex Fatkulin — Mon, 02 Jun 2008 12:59:20 +0000

Bernard,

given that you have only one SQL in a dozen you may find it is well appropriate to use outline. I wouldn’t argue on that one, however, we need not to forget that “system being run fine for months, nothing changed, then one day..” actually means what your single SQL statement is what you hit by far and you just don’t know about the other ones (yet).

By: Polarski Bernard

Polarski Bernard — Mon, 02 Jun 2008 07:07:04 +0000

Alex,

Addressing the root cause when dealing a system able to make decision is very a optimistic assertion. The question is not if you are good DBA or not, but only what will be the consequence if you made a mistake in the assumtion you solved the problem.

Once one recognize a problem, acknowlege a solution, acknowlege that everything that is not the solution may only cause harm, why on earth do you want to discover, post mortem, the reason the optimizer diverged?

We deal with a online banking transaction. the master SQL is run hundreds time per second with 9 gets. Shall it be 100 it is still good. But bind peeking may send it on FTS partition and that’s 27000 gets and machines down on its knee and transaction fall in timeout cancel third parties: a disaster it is.

Beside this SQL all others are fine and statistics are run with gather method_opt ‘auto’. the DB, 10.2.0.3, has created several hundred histogram. Good not good, why should you bother to analyze the perticence of any of them as long as the system is fast but weird behaviour on the master SQL (most run and primary SQL in the application).

So here your are with a system quite good out of the box but sometime a bind peeking may send the master SQL on the wrong path. Metling with the system gather statistics algorithm was not found to be a promising way since the problem is local to only one SQL.

The stored outlines is most appropirate in this case and you will find hard time to convince anybody in the department that we should leave even 0.0001% latitude to the optimzer to think otherwise in the futur.

You serie is interresting but the solution you propose is irrealistic in term of stability.
Manager want absolute stability, not adaptability.

Having said that, I am waiting to read on your third post in the serie :p

By: Alex Fatkulin

Alex Fatkulin — Fri, 30 May 2008 20:58:50 +0000

Bernard,

I still prefer the optimizer to make a decision. The advantage of letting the optimizer to do the right job is that you are fixing not only the current query but potential future problems (including these you haven’t discovered yet). Outline fixes the immediate issue without actually addressing the root cause.

By: Polarski Bernard

Polarski Bernard — Fri, 30 May 2008 07:23:04 +0000

Your serie on the bind peeking is brilliant but why not going right to the point and enforce absolutely your wish?

The facts are :

a) You want stability
b) You have identified which execution plan must always be the one

—> Then you should just set a stored outlines

By: Stabilize Oracle Bind Peeking Behaviour with Range-Based Predicates

Stabilize Oracle Bind Peeking Behaviour with Range-Based Predicates — Wed, 28 May 2008 18:40:32 +0000

[…] my previous post, I described the most common cause for unstable plans due to bind peeking — histograms. It is now time to move forward and take a look at another case, namely range-based predicates. […]

By: Alex Gorbachev

Alex Gorbachev — Sun, 27 Apr 2008 03:19:36 +0000

Eddie, you don’t disable BVP by removing histograms - it still happens. By removing histograms you just avoid most common scenario when bind variable peeking can cause different execution plans. There are other scenarios like range scan proximity to min/max value and partitioning (I wrote about the latter a while ago).

By: Eddie

Eddie — Fri, 25 Apr 2008 20:57:25 +0000

Question -
So If I remove the unnecessary histogram and bind peeking remains enabled, then during a hard parse when Oracle is peeking at my bind var, what data will the CBO use to make a plan decision since the histogram has been removed? It almost sounds like if I remove the histogram then I’m kind of disabling bind keeping for that query also. What do you think?

By: cristiancudizio

cristiancudizio — Wed, 02 Apr 2008 15:40:46 +0000

I agree for most part with Christo Kutrovsky. I think that the problem are not histograms, but CBO: CBO and bind variables are enemies. We have an OLTP application and until 9iR2 we have used RBO without problems. Majority of CBO features are good for BI/DWH related queries. What effectively you demonstrate is that RBO is enought to do a good job. Unfortunately Oracle has choosen to use only CBO and this is a pity for me (until the we don’t make analitycal queries).

regards,
Cristian

By: Asif Momen

Asif Momen — Mon, 31 Mar 2008 11:20:15 +0000

Very nice explanation