#!/bin/ksh

INFILE=$1
OUTFILE=$2

grep "Consistent read started" $INFILE | awk -F ':' '{print $2}' | sort  | uniq -c | sort -rn > $OUTFILE

Should do the same and work even on windows (powered by cygwin :) :) )

My original source (some 15 to 20 years ago) was the oraus.msg file. From time to time you find notes on Metalink or on the internet about them.

Another interesting little detail is how more and more “consistent gets” have gradually changed to “consistent gets – examinations” over the versions. Once upon a time it seemed to be only undo blocks, single table hash cluster blocks, and root blocks of indexes – in recent versions you can even see ordinary heap table blocks subject to examinations.

Since you have blevel 1 on the child index you can ignore the comments about the branch block. Given that I know what my data looks like I know that you have 57 rows per table block in the parent and child tables. So your output shows:

0206e214	   1 - get and pin parent index root
0206e215	   1 - get and pin parent index child
01c0000c	   1 - get and pin parent table block 1
01c72d94	   2 - get child index root block twice
01c72d95	 200 - get a child leaf block for 200 iterations of the loop
01c003ec	  57 - get the first child table block 57 times
01c0000d	   1 - get and pin the second parent table block
01c003ed	  57 - get the second child block 57 times
01c0000e	   1 - get and pin the third parent table block
01c003ee	  57 - get the third child block 57 times
01c0000f	   1 - get and pin the fourth parent table block
01c003ef	  29 - get the fourth child block 29 times

Note that: 57 + 57 + 57 + 29 = 200


begin dbms_output.put_line(sqlerrm(-10200));end;
/

Here’s the output from “SQL Commands” at apex.oracle.com:

ORA-10200: consistent read buffer status

Statement processed.

0.00 seconds

Great job gain. I would like to two additional questions:

1. I have never heard of 10200 event. How did you know such an event exists? But meanwhile, I have discovered $ORACLE_HOME/rdbms/mesg/oraus.msg. i didn’t know this file was providing also list of events and their names! :-)
2. Very interesting information that Oracle is pinning blocks in the outer table, too (in 10g). If we give away condition “and chi.n1 = 0″ making your query retuning 200 rows, we will obviously have slightly more consistent gets in rows 2 and 3.

The change of behaviour in 11g is very interesting, too.

I see that you have already posted the answer to the quiz – very thought provoking.

For comparison with 11.2.0.2, this is the execution plan that I see on 10.2.0.5 when the BLEVEL of both indexes is 1, as was the case on 11.2.0.2:

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST -ROWS -PREDICATE'));
 
----------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Starts | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |      1 |      0 |00:00:00.01 |     408 |
|   1 |  NESTED LOOPS                |        |      1 |      0 |00:00:00.01 |     408 |
|   2 |   TABLE ACCESS BY INDEX ROWID| T1     |      1 |    200 |00:00:00.01 |       6 |
|   3 |    INDEX RANGE SCAN          | PAR_I1 |      1 |    200 |00:00:00.01 |       2 |
|   4 |   TABLE ACCESS BY INDEX ROWID| T2     |    200 |      0 |00:00:00.01 |     402 |
|   5 |    INDEX UNIQUE SCAN         | CHI_I1 |    200 |    200 |00:00:00.01 |     202 |
----------------------------------------------------------------------------------------

As can be seen by the above, the number of consistent gets for the CHI_I1 was 202 rather than 402 as shown at the top of this blog article. Process of elimination would suggest that the BLEVEL must be 2 (of course process of elimination was not the desired path of finding the answer).

With 300,000 rows in each of the tables I used the following SQL statement that resulted in the generation of the above execution plans:

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;

Vyacheslav Rasskazov’s comment jogged my memory a bit regarding what is likely happening. While waiting for your answer to this post I performed a couple of tests. Running this SQL statement before and after executing my test query:

SELECT
  NAME,
  VALUE
FROM
  V$MYSTAT M,
  V$STATNAME S
WHERE
  (NAME LIKE 'consistent%'
    OR NAME LIKE 'buffer%')
  AND M.STATISTIC#=S.STATISTIC#;
 
NAME                                        VALUE
-------------------------------------- ----------
consistent gets                               456  /* +408 */
consistent gets from cache                    456  /* +408 */
consistent gets - examination                 405  /* +402 */
consistent gets direct                          0
consistent changes                              0
buffer is pinned count                        630  /* +593 */
buffer is not pinned count                    421  /* +406 */

The consistent gets count increase matches my execution plan, and the buffer is pinned count increased by 593.

I then created a 10200 trace:

ALTER SESSION SET TRACEFILE_IDENTIFIER='WATCH_CONSISTENT'; 
ALTER SESSION SET EVENTS '10200 TRACE NAME CONTEXT FOREVER, LEVEL 1';
 
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;

And a simple Excel macro to process the trace file:

Sub ReadTrace()
    Dim intFileNum As Integer             '10200 trace file
    Dim intFileNum2 As Integer            'Output file
    Dim strInput As String                'Line read from the 10200 trace file
    Dim strOutput As String               'Line to be written to the output file
    Dim strBlock(2000) As String          'Block read from the trace file
    Dim strBlockCounter(2000) As Integer  'Number of times read
    Dim intBlocks As Integer              'Total number of blocks
    Dim i As Integer                      'Loop counter
    Dim intFound As Integer               'Indicates whether or not the block was found
    
    intFileNum = FreeFile
    Open "c:\or10s_ora_4256_watch_consistent.trc" For Input As #intFileNum
    
    intFileNum2 = FreeFile
    Open "c:\watch_consistent.txt" For Output As #intFileNum2
    
    Do While Not EOF(intFileNum)
        Line Input #intFileNum, strInput
        If InStr(strInput, "Consistent read started for block") > 0 Then
            strOutput = Trim(Right(strInput, Len(strInput) - InStr(strInput, ":")))
            'Find the number of times the block was accessed
            intFound = 0
            For i = 1 To intBlocks
                If strOutput = strBlock(i) Then
                    intFound = i
                    strBlockCounter(i) = strBlockCounter(i) + 1
                    Exit For
                End If
            Next i
            'If the block was not found, record it
            If intFound = 0 Then
                intBlocks = intBlocks + 1
                intFound = intBlocks
                strBlockCounter(intBlocks) = 1
                strBlock(intBlocks) = strOutput
            End If
            Print #intFileNum2, strOutput; vbTab; strBlockCounter(intFound)
        End If
    Loop
    Print #intFileNum2, ""
    For i = 1 To intBlocks
        Print #intFileNum2, strBlock(i); vbTab; strBlockCounter(i)
    Next i
    Close #intFileNum
    Close #intFileNum2
End Sub

The output of the Excel macro lists every consistent block read, outputs that block number to another file, along with a running count of the number of times that block had been accessed. A summary is produced at the bottom of the output, listing the blocks accessed in order and the total number of consistent gets for that block. The summary from my test follows:

0206e214	 1 
0206e215	 1 
01c0000c	 1 
01c72d94	 2 
01c72d95	 200 
01c003ec	 57 
01c0000d	 1 
01c003ed	 57 
01c0000e	 1 
01c003ee	 57 
01c0000f	 1 
01c003ef	 29

The read of blocks 0206e214 and 0206e215 were at the very start of the trace file. How are those block numbers from the 10200 trace file translated into the following from your explanation:

1) Get the root block of parent index and pin it
2) Get the first relevant leaf block of the parent index and pin it

We have the following information on line 5 of the explain plan

Starts = 200, A-Rows = 200 and Buffers = 402

The Operation 5 has been started 200 times and has produced 200 rows; which means that A-Rows/Starts = 200/200 = 1 row for each execution

Buffers definition : The number of logical reads the operation performed during its executions = 402 almost 402/200 = 2 buffers

Hence, the operation 5 performed 2 consistent gets for each CHI_I1 Index access; so its blevel = 0

Best Regards

Oracle does not have to read index segment header in case of index unique or range scan (It think oracle is able to derive ROOT BLOCK address directly from address of segment header without inspecting segment header block).

Now I will try to explain my statment once more time. I wrote: “It will cache it (the ROOT BLOCK) somehow (I have to admitt I’m not able to describe whole process), spending one extra consistent read .” . I think the extra consistent read is spent due ROOT BLOCK CACHING, but I’m not sure, just guessing Oracle will create new consistent read version of ROOT BLOCK in BUFFER CACHE, pinned by server process during nested loops join.