Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Rollback waiting on 'cache buffer chains' latch

RE: Rollback waiting on 'cache buffer chains' latch

From: Bobak, Mark <Mark.Bobak_at_il.proquest.com>
Date: Tue, 9 Jan 2007 18:36:47 -0500
Message-ID: <AA29A27627F842409E1D18FB19CDCF270ADB685B@AABO-EXCHANGE02.bos.il.pqe>


Brandon,

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: http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14237/dynv iews_2094.htm#REFRN30229

Hope that helps,

-Mark

--

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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Allen, Brandon Sent: Tuesday, January 09, 2007 6:29 PM
To: Andrey.Kriushin_at_rdtex.ru; 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 increasing:

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
WTime SECONDS_IN_WAIT
------------------------------ ---------------- -----------
15:11:43 SQL> /
EVENT                          P1RAW                     P2 STATE
WTime SECONDS_IN_WAIT
------------------------------ ---------------- -----------
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.

Thanks!

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.

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Tue Jan 09 2007 - 17:36:47 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US