Comments for Oracle database internals by Riyaj

Comment on Is plan_hash_value a final say? by orainternals

orainternals — Fri, 06 Nov 2009 05:09:37 +0000

Hello Stellios
Thanks for visiting my blog. I corrected your comment and removed t
You are correct about “explain” command, not bind peeking (at least as of version 10g). But, point of blog is that filter predicates and access predicates can change without a change to plan_hash_value. This lead to a incorrect diagnosis and that’s exactly what I blogged about.

Cheers
Riyaj

Comment on Is plan_hash_value a final say? by Stellios

Stellios — Fri, 06 Nov 2009 04:38:34 +0000

I’ve tried posting this three times now – site keept reporting “discarded”.

I think your test case may be incorrect. Using autotrace and EXPLAIN for SQL that contains bind variables may not necessarily produce the correct execution plan. EXPLAIN does NOT perform bind variable peeking and is especially prone to being incorrect when indxes are involved.

Use

SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR(‘&SQL_ID’)) (although you can use PLAN_HASH_VALUE also – documentation does not say this).

Also see Why EXPLAIN PLAN should not be used with Bind Variables

Comment on Tuning latch contention: Cache buffers chain latches by Osama Karim

Osama Karim — Sat, 24 Oct 2009 21:01:45 +0000

Riyaz,

Thanks for the lovely blog. We are facing similar problem where CPU usage is going upto 80% +. We will try to implement your Suggestion.

Thanks

Comment on Correlation, nocorrelation and extended stats by Alberto Dell’Era’s Oracle blog » CBO: NewDensity for Frequency Histograms,11g-10.2.0.4 (densities part IV)

Fri, 23 Oct 2009 16:08:06 +0000

[...] the "Histogram change" post by Jonathan Lewis, which distills the findings of Randolf Geist and Riyaj Shamsudeen) – a surprising rule that might easily cause trouble (in fact as Jonathan reports in the comments – [...]

Comment on Exciting seminars in Dallas arena by orainternals

orainternals — Tue, 20 Oct 2009 23:38:46 +0000

Asif
Thanks for reading my blog and kind words.

Cheers
Riyaj

Comment on Exciting seminars in Dallas arena by Asif Momen

Asif Momen — Sun, 11 Oct 2009 07:31:20 +0000

Your posts are always good to read. They are very clear and concise.

In my practice, I always compare query execution plans and never plan hash value, out of habit. This post proves that some of your dirty habits are infact good habits.

Comment on Tuning latch contention: Cache buffers chain latches by orainternals

orainternals — Tue, 06 Oct 2009 15:10:28 +0000

Hello Muthu
Thanks for visiting. I am glad this blog is helpful.
Cheers
Riyaj

Comment on Tuning latch contention: Cache buffers chain latches by Muthu

Muthu — Mon, 05 Oct 2009 21:46:46 +0000

Riyaj,

Very nice article. We’re experiencing latch contention in our EBS environment off and on. I’m sure, this article will help troubleshooting the issues.

Also, have you blogged with the focus on tuning the SQLs ? We’ve a situation in whchi, the SQLs that were written over 3 yrs ago, during the implementation phase, has undergone some changes ; and with the growth of the database from 1 TB to around 4 TB, performance troubleshooting has become a big challenge now.

Thanks and regds.
Muthu

Comment on Library cache lock and library cache pin waits by library_cache_lock and library_cache_pin « Anand's Blog

library_cache_lock and library_cache_pin « Anand's Blog — Sun, 04 Oct 2009 18:56:42 +0000

[...] http://orainternals.wordpress.com/2009/06/02/library-cache-lock-and-library-cache-pin-waits/ [...]

Comment on Resolving HW enqueue contention by orainternals

orainternals — Mon, 21 Sep 2009 21:50:31 +0000

Hello Khair
I don’t think, there is an event to print when an extent is added, at least, not that aware of. My recommendation is to write a small piece of code to get timestamp and # of extents every hour or so for that tablespace/object. With that output, you can pin down the hour at which extent is added and dump the log file during that time period.

Correct approach here is to understand root cause by dumping the log files. This might also mean that you may have to dump the ASSM segments with dbms_Space_admin.segment_dump to see block status of various blocks. With these two trace files, you may be able to understand, why extents are allocated even when not needed.

There are many bugs in 10.2.0.3 in ASSM for extent management. You may be hitting one of that. So, you might want to consider upgrading to version 10.2.0.4 and see if this problem reproduces.

Cheers
Riyaj