My contribution a small awk script, that allows direct parsing of the trace file output on unix (although, I actually used it on cygwin …., so may be not 100% compatible)

The script is working with gawk and trace file 11.1.0.7; example trace line:
ktrget2(): started for block <0×0104 : 0x09e3d4cc> objd: 0x00189fa5.

In order to change to another trace file format, you just have to change $nr references in the script.

$ more cons_get_trc.awk

BEGIN { 
   FS ="[ \t<>:]+"
    print "Details for file: " trcfile
   print "---------------------------------"
   while( getline < trcfile != EOF ){
      if ( $0 ~ /started for block/ ) {
      rdba[$6]+=1
      obj[$8]+=1
      both[$6","$8]+=1
      print $6 " " rdba[$6] ", " $8 " " obj[$8]
      }
   }
   close (trcfile)
   print ""

   print ""
   print "Summary rdba and obj for file: " trcfile
   print "---------------------------------"
   for ( var in both) {
      print var " " both[var]
   }

   print ""
   print "Summary obj for file: " trcfile
   print "---------------------------------"
   for ( var in obj ) {
      print var " " obj[var]
   }
}

One third code, two thirds output. Usage demonstration, with just a head 50 of a trace file into small.trc:

$ awk -v trcfile=small.trc -f cons_get_trc.awk

Details for file: small.trc
---------------------------------
0x09e3d4cc 1, 0x00189fa5 1
0x09fa4692 1, 0x00189fa5 2
0x0a0ac450 1, 0x00189fa5 3
0x009d94fc 1, 0x00189fa5 4
0x09fa4698 1, 0x00189fa5 5
0x009d94ff 1, 0x00189fa5 6

Summary rdba and obj for file: small.trc
---------------------------------
0x0a0ac450,0x00189fa5 1
0x09fa4698,0x00189fa5 1
0x09fa4692,0x00189fa5 1
0x009d94ff,0x00189fa5 1
0x009d94fc,0x00189fa5 1
0x09e3d4cc,0x00189fa5 1

Summary obj for file: small.trc
---------------------------------
0x00189fa5 6

Please provide the missing sections in a comment and I will edit your comment above. Thanks for taking the time to post an awk script.

On this blog the <pre> and </pre> codes seem to work well when posting code, but < and > symbols may cause code to disappear.
Before posting code, please replace:
< symbols with &lt ; (without a space before the ; )
> symbols with &gt ; (without a space before the ; )

- a small awk script, does the trick
- script working with gawk and trace file 11.1.0.7; example line: ktrget2(): started for block objd: 0x00189fa5
- to change, just change the $number references

BEGIN {
   FS ="[ \t<>:]+"
   print "Details for file: " trcfile
   print "---------------------------------"
   while( getline < trcfile != EOF ){
      if ( $0 ~ /started for block/ ) {
           rba[$6]+=1
           obj[$8]+=1
           both[$6","$8]+=1
           print $6 " " rba[$6] ", " $8 " " obj[$8]
       }
   }
   close (trcfile)
   print ""

   print "Summary rba for file: " trcfile
   print "---------------------------------"
   for ( var in rba ) {
      print var " " rba[var]
   }

   print ""
   print "Summary obj for file: " trcfile
   print "---------------------------------"
   for ( var in obj ) {
     print var " " obj[var]
   }

   print ""
   print "Summary rdba and obj for file: " trcfile
   print "---------------------------------"
   for ( var in both) {
     print var " " both[var]
   }

}

$ awk -v trcfile=small.trc -f cons_get_trc.awk

Details for file: small.trc
---------------------------------
0x09e3d4cc 1, 0x00189fa5 1
0x09fa4692 1, 0x00189fa5 2
0x0a0ac450 1, 0x00189fa5 3
0x009d94fc 1, 0x00189fa5 4
0x09fa4698 1, 0x00189fa5 5
0x009d94ff 1, 0x00189fa5 6

Summary rba for file: small.trc
---------------------------------
0x09fa4692 1
0x009d94ff 1
0x09fa4698 1
0x0a0ac450 1
0x09e3d4cc 1
0x009d94fc 1

Summary obj for file: small.trc
---------------------------------
0x00189fa5 6

Summary rdba and obj for file: small.trc
---------------------------------
0x0a0ac450,0x00189fa5 1
0x09fa4698,0x00189fa5 1
0x09fa4692,0x00189fa5 1
0x009d94ff,0x00189fa5 1
0x009d94fc,0x00189fa5 1
0x09e3d4cc,0x00189fa5 1

So, according to your results our guesses related to ‘buffer is pinned count’ might be not right. I was running the test in my desktop (Windows XP running 11.2.0.1) and i got some results:

1) even when the OPTIMIZER_FEATURES_ENABLE is set to ’10.2.0.4′, the query returned 215 BG instead of 408 BG in my tests, still don’t know why.
2) reading http://blog.tanelpoder.com/2009/11/19/finding-the-reasons-for-excessive-logical-ios/, tanel says the quote below:
“These buffer get reason counters are not maintained properly in Oracle 11g, probably due an optimization effort and some changes for faster pinning of buffer cache buffers (there’s a parameter called _fastpin_enable which is set to 1 in 11g and it enables so called fastpath buffer gets. If you see v$sesstat statistics such “consistent gets from cache (fastpath) or “db block gets from cache (fastpath)” being inremented, then fastpath buffer gets/pins are used. Note that I do have a script which works also on 11g but I’ll write about that one some time in the future ”

Said that, i changed the ‘_fastpin_enable’ to 0 and still got the same results.

So, Oracle is hiding something in version 11g

Cheers!

ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE='10.2.0.4';
 
COLUMN NAME FORMAT A38
 
SELECT
  NAME,
  VALUE
FROM
  V$MYSTAT M,
  V$STATNAME S
WHERE
  (NAME LIKE 'consistent%'
    OR NAME LIKE 'buffer%')
  AND M.STATISTIC#=S.STATISTIC#;
 
SELECT /*+ GATHER_PLAN_STATISTICS LEADING(T1) USE_NL(T2) INDEX(T1) INDEX(T2) */
  T1.ID,
  T1.N1,
  T2.ID,
  T2.N1
FROM
  T1,
  T2
WHERE
  T1.ID=T2.ID
  AND T1.ID BETWEEN 1 AND 200
  AND T2.N1 = 0;
  
SELECT
  NAME,
  VALUE
FROM
  V$MYSTAT M,
  V$STATNAME S
WHERE
  (NAME LIKE 'consistent%'
    OR NAME LIKE 'buffer%')
  AND M.STATISTIC#=S.STATISTIC#;

The results:
10.2.0.5:

NAME                                        VALUE
-------------------------------------- ----------
consistent gets                                44
consistent gets from cache                     44
consistent gets - examination                   3
consistent gets direct                          0
consistent changes                              0
buffer is pinned count                         37
buffer is not pinned count                      7
 
NAME                                        VALUE
-------------------------------------- ----------
consistent gets                               452  /* +408 */
consistent gets from cache                    452  /* +408 */
consistent gets - examination                 405  /* +402 */
consistent gets direct                          0
consistent changes                              0
buffer is pinned count                        630  /* +593 */
buffer is not pinned count                    413  /* +406 */

11.2.0.2:

NAME                                        VALUE
-------------------------------------- ----------
consistent gets                                37
consistent gets from cache                     37
consistent gets from cache (fastpath)          32
consistent gets - examination                   4
consistent gets direct                          0
consistent changes                              0
buffer is pinned count                         12
buffer is not pinned count                      8
 
NAME                                        VALUE
-------------------------------------- ----------
consistent gets                               252  /* +215 */
consistent gets from cache                    252  /* +215 */
consistent gets from cache (fastpath)          39  /* +  7 */
consistent gets - examination                 212  /* +208 */
consistent gets direct                          0
consistent changes                              0
buffer is pinned count                        410  /* +498 */
buffer is not pinned count                    416  /* +408 */

The above shows that the ‘buffer is pinned count’ increased by 593 on Oracle Database 10.2.0.5, and 498 (95 less) on Oracle Database 11.2.0.2. I would have expected that statistic would be about 190 higher on 11.2.0.2 than on 10.2.0.5.

Good that someone is actually trying the test. Sorry if it was not clear if you need to change the value of OPTIMIZER_FEATURES_ENABLE for the 11.2.0.2 execution. Yes, that setting is necessary to eliminate the second NESTED LOOPS join. So, the script to run the execution plan (somewhere near the top of this article is:

ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE='10.2.0.4';
 
SELECT /*+ GATHER_PLAN_STATISTICS LEADING(T1) USE_NL(T2) INDEX(T1) INDEX(T2) */
  T1.ID,
  T1.N1,
  T2.ID,
  T2.N1
FROM
  T1,
  T2
WHERE
  T1.ID=T2.ID
  AND T1.ID BETWEEN 1 AND 200
  AND T2.N1 = 0;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST -ROWS -PREDICATE')); 

Of course, when you perform the 10200 trace, the changed value for OPTIMIZER_FEATURES_ENABLE should still be set.

How come you did not get the new extra nested loop when you run it on 11.2.0.2 (reference_link).

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  3v5y2pjq60zzd, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS LEADING(T1) USE_NL(T2) INDEX(T1)
INDEX(T2) */ /*test_11201*/   T1.ID,   T1.N1,   T2.ID,   T2.N1 FROM
T1,   T2 WHERE   T1.ID=T2.ID   AND T1.ID BETWEEN 1 AND 200   AND T2.N1
= 0

Plan hash value: 2303960507

----------------------------------------------------------------------------------------
| Id  | Operation                     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |        |       |       |   206 (100)|          |
|   1 |  NESTED LOOPS                 |        |       |       |            |          |
|   2 |   NESTED LOOPS                |        |     1 |    20 |   206   (0)| 00:00:02 |
|   3 |    TABLE ACCESS BY INDEX ROWID| T1     |   200 |  2000 |     6   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | PAR_I1 |   200 |       |     2   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN          | CHI_I1 |     1 |       |     0   (0)|          |
|*  6 |   TABLE ACCESS BY INDEX ROWID | T2     |     1 |    10 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

My tests on 11.2.0.1 generates the new extra nested loop

Were you still under optimizer_features_enable=10.2.0.4

I think that you are right. There is a statistic with the name ‘buffer is pinned count’, and the amount by which this increased for the session on 10.2.0.5 and 11.2.0.2 was different – I ran out of time and was not able to spend much time comparing the differences, but I will check again later. Tanel Poder has an excellent write up on this statistic, part of which is quoted below:
http://blog.tanelpoder.com/2010/01/15/beyond-oracle-wait-interface-part-2/

“However, check the value for buffer is pinned count statistic! This counter is updated every time we go to a buffer to get some data from it AND it already happens to be open by my session! Oracle keeps buffers pinned and relevant buffer handles cached during a database call in some cases (like nested loop joins and index scans) to avoid reopening the buffer again (getting a buffer again if its closed would mean another logical IO).”

It appears that 11.2.0.2 is much more intelligent with how index blocks are pinned, quickly pinning the index leaf blocks of the index belonging to the inner table in the nested looks join, while 10.2.0.5 did not pin these blocks. This increased willingness to pin observation of course is based on very limited testing, and might not apply to other situations. I welcome other people to test and report their findings – maybe it only happens in small index structures?