A list member has kindly forwarded the following information to us for confirmation. The wording is not very clear at points, but it includes two cases where the second digit of the reason code is 0, indicating that the block is about to be 'new'ed. It also includes two cases where the second digit is 1, apparently indicating that a deadlock will be assumed if the wait times out. I've not seen these, so I suspect that they are relatively rare.

I don't have access to the source code, but a friendly Oracle Support analyst sent this to me some months back (edited for brevity):

P3 - id
The buffer busy wait event is called from different places in
the Oracle kernel. Each place in the kernel uses a different 'id'.
NB:   7.1 - 8.0.6 use one set of ID codes (mostly >1000)
      8.1.5       8.1.5 does not include an 'id' when waiting
      8.1.6+      use a new set of ID codes (100-300)


Buffer Busy Waits ID's
~~~~~~~~~~~~~~~~~~~~~~
     Id    Reason
     ~~    ~~~~~~
      0    A block is being read

   1003    We want to NEW the block but the block is currently
 or 100    being read by another session (most likely for undo).

   1007    We want to NEW the block but someone else has is
 or 200    using the current copy so we have to wait for them
           to finish.

   1010    Trying to get a buffer in CR/CRX mode , but a
 or 230    modification has started on the buffer that has not
           yet been completed.

   1012    A modification is happening on a SCUR or XCUR buffer,
           but has not yet completed

   1012 (dup.)
 or 231    CR/CRX scan found the CURRENT block, but a modification
           has started on the buffer that has not yet been
           completed.

   1013    Block is being read by another session and no other
 or 130    suitable block image was found, so we wait until the read
           is completed. This may also occur after a buffer cache
           assumed deadlock. The kernel can't get a buffer in a
           certain amount of time and assumes a deadlock. Therefore it
           will read the CR version of the block.

   1014    We want the CURRENT block either shared or exclusive
 or 110    but the Block is being read into cache by another session,
           so we have to wait until their read() is completed.

   1014 (duplicate)
 or 120    We want to get the block in current mode but someone else
           is currently reading it into the cache. Wait for them
           to complete the read. This occurs during buffer lookup.

   1016    The session wants the block in SCUR or XCUR mode.
 or 210    If this is a buffer exchange or the session is in discrete
           TX mode, the session waits for the first time and the second
           time escalates the block as a deadlock and so does not show
           up as waiting very long.  In this case the
           <Statistic:exchange_deadlocks> is incremented and we yield the
           CPU for the <WaitEvent:buffer_deadlock>.

   1016 (duplicate)
 or 220    During buffer lookup for a CURRENT copy of a buffer we have
           found the buffer but someone holds it in an incompatible mode
           so we have to wait.

There is a subtle distinction between reason codes 1012 and 1016, but the tuning advice for both is to avoid contention for exclusive locks on the buffers. Reason code 0 means that a process had to wait for a buffer that was busy being read into cache by another process.

Incidentally, these reason codes have changed in 8i. The new reason codes are 3-digit numbers. So far as I can tell, the first digit is 1 for consistent gets, and 2 for current mode gets. The second digit is 2 when requesting an exclusive lock, and 3 when requesting a shared lock on the buffer. The third digit is normally 0, but can be 1 if the buffer is needed for a (consistent read) rollback. If anyone reading this has source code access, I would appreciate some confirmation of this. Anyway, the two reason codes that you need to know about for 8i are 130 (block being read into cache by another process) and 220 (waiting for exclusive access to the block).

I'm analyzing parameter p3 for buffer busy waits from event 10046, level 8 traces and I've got some doubts about it. What is the difference between p3=1012 and p3=1016?

Some examples:

SOURCE P1,P2,P3                OWNER      SEGMENT_NAME                  SEGMENT_TYPE
p1=2 p2=1887 p3=1012           SYS        R10                           R
p1=2 p2=1887 p3=1016           SYS        R10                           R
p1=2 p2=19697 p3=1016          SYS        R08                           R
p1=42 p2=16853 p3=0            GL         GL_JE_LINES_N1                I
p1=42 p2=22492 p3=0            GL         GL_JE_LINES_N1                I
p1=43 p2=68119 p3=0            GL         GL_JE_LINES                   T