RE: Rollback waiting on 'cache buffer chains' latch


If STATE is not 'WAITING', then you're not really waiting on that event.
This, combined w/ WAIT_TIME and SECONDS_IN_WAIT, can be confusing.
Rather than stating it here, I'll just point you to:

Hope that helps,


Mark J. Bobak
Senior Oracle Architect
ProQuest Information & Learning

There is nothing so useless as doing efficiently that which shouldn't be
done at all.  -Peter F. Drucker, 1909-2005

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Allen, Brandon
Sent: Tuesday, January 09, 2007 6:29 PM
To: Andrey.Kriushin@xxxxxxxx; oracle-l
Subject: RE: Rollback waiting on 'cache buffer chains' latch

Hi Andrey, yes we've checked v$session_wait and it seems kind of odd to
me that wait_time is always 1 and seconds_in_wait is constantly

15:11:12 SQL> select event, p1raw, p2, state, wait_time, seconds_in_wait
from v$session_wait where sid=664;

EVENT                          P1RAW                     P2 STATE
------------------------------ ---------------- -----------
------------------- ------ ---------------
latch free                     0700000104AA4980          98 WAITED KNOWN
TIME        1           16676

15:11:43 SQL> /

EVENT                          P1RAW                     P2 STATE
------------------------------ ---------------- -----------
------------------- ------ ---------------
latch free                     0700000104AA4980          98 WAITED KNOWN
TIME        1           16850

There haven't been any complaints from PMON in the alert log or any
trace files in bdump, but it is eating up CPU like crazy, probably
spinning trying to get the 'cache buffers chains' latch.

There don't appear to be any other transactions rolling back:

15:27:23 SQL> select s.sid, t.addr, t.status, t.used_ublk,
decode(bitand(t.flag,128),0,'NO','YES') rolling_back from v$session s,
v$transaction t where s.taddr=t.addr;

  SID ADDR             STATUS            USED_UBLK ROL
----- ---------------- ---------------- ---------- ---
  648 0700000105DFA1B0 ACTIVE                   24 NO
 1112 0700000105E57900 ACTIVE                    1 NO
 1055 0700000105E81250 ACTIVE                    1 NO
  879 0700000105E96380 ACTIVE                    1 NO
  737 0700000105ECABD8 ACTIVE                    1 NO
 1001 0700000105F52FF8 ACTIVE                    1 NO
  396 0700000105F90D80 ACTIVE                   17 NO
  664 07000001061D98D0 ACTIVE                   69 YES
  815 070000010620E7B0 ACTIVE                    1 NO
  683 0700000106267130 ACTIVE                    3 NO
  905 0700000106268B20 ACTIVE                    1 NO

11 rows selected.

We are currently looking through the hanganalyze dump.


Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do
not consent to Internet email for messages of this kind. Opinions,
conclusions and other information in this message that do not relate to
the official business of this company shall be understood as neither
given nor endorsed by it.



Other related posts: