Posted by Luke Davies on Sep 30, 2009
Recently I was looking into a long-running statement and noticed a curious thing. One moment, I had just over 4 billion buffer gets, and the next I had around 2 million.
The statement was still processing and the number of physical reads was still rising.
I think the reason for this is that the internal place holder for this value is simply a 32-bit unsigned integer that has the largest number of 4294967295. But my version of Oracle is 64-bit; I thought that maybe it would use 64-bit integers.
So, beware that if you have had a statement running for some time, you cannot necessarily rely on the buffer_gets column in v$sql—it may be that it has run over the limit, been recycled, and is counting from zero again.
The evidence. Read the rest of this entry . . .
Posted by Alex Fatkulin on Mar 18, 2008
I wrote this post because I feel there is a great need for it. The number of people struggling with unstable query plans due to bind peeking in Oracle 10G is enormous, to say the least. More than that, solutions like disabling bind variable peeking are driving us away from understanding the root cause of the problem and applying the right fix to it.
What are the causes of unstable plans due to bind variable peeking?
There are three things that might put you at risk of unstable plans due to bind variable peeking. Those are histograms, partitions, and range-based predicates. I’ll cover last two in upcoming blog posts.
Histograms
Let me share with you my déja vu. When I see this:
SQL> select value
2 from v$parameter
3 where name='_optim_peek_user_binds';
VALUE
--------------------
FALSE
I immediately expect this:
SQL> select sum(case when max_cnt > 2 then 1 else 0 end) histograms,
2 sum(case when max_cnt <= 2 then 1 else 0 end) no_histograms
3 from (
4 select table_name, max(cnt) max_cnt
5 from (
6 select table_name, column_name, count(*) cnt
7 from dba_tab_histograms
8 group by table_name, column_name
9 ) group by table_name
10 );
HISTOGRAMS NO_HISTOGRAMS
---------- -------------
1169 2494
The above is an example from a real-world OLTP system running with bind peeking disabled. It is no surprise to me. An exception, you say? Here’s another one . . . Read the rest of this entry . . .