RE: Intermittent ORA 600 [kdsgrp1]

From: Kumar, Arvind <>
Date: Wed, 9 Jan 2013 09:22:54 +0000
Message-ID: <>

Many thanks Niall,
I have raised a SR and still waiting for the solution on for my environment. I have checked for chained rows but its not the case. It happens when the table is accessed using the primary key index (rebuilt as well). I see many wait event "log file sequential event" in v$active_session_history and it scans thru old archivelogs, unable to figure out why. Thanks
Arvind kumar

From: Niall Litchfield [] Sent: Wednesday, January 09, 2013 1:55 PM To: Kumar, Arvind
Subject: Re: Intermittent ORA 600 [kdsgrp1]

There are a number of bugs for this error, and a MOS note that can help narrow down to your target version. The base problem is that Oracle can't find a row continuation piece ( your trace file likely contains block dumps of the blocks that are supposed to contain the continuation) . In our case the continuation was the overflow segment of a IOT, but it looks like this might happen for chained or migrated rows as well in ordinary tables. You'll definitely need to work with support here, but feel free to get in touch offline as well and I can share some of what we found with our kdsgrp1 issue. It's relatively likely if this is a physical issue on disk that analyze and dbv won't pickup the corruption because all the blocks are correctly formatted. If the issue does turn out to be missing row pieces on disk (and there are a few alternatives) then you are likely looking at some form of object repair/recovery. On Jan 9, 2013 7:00 AM, "Kumar, Arvind" <<>> wrote: Greetings all,
Oracle Database 11g Enterprise Edition Release - 64bit Production, Windows 2008 R2 Enterprise.

There is a select query which fails intermittently with ORA 600 [kdsgrp1] and generates huge .trc

ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []

  • Dump for incident 795670 (ORA 600 [kdsgrp1]) ========
    • 2013-01-09 13:16:35.324 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
      ----- Current SQL Statement for this session (sql_id=7nkvuwm6q9rtd) -----

V$active_session_history shows the select query has waited mostly on "log file sequential read" event.

analyzing the table/index with validate structure doesn't help. I have not tried _row_crúLSE yet.

Any pointers/help will be much appreciated.

Thanks & Regards,
Arvind Kumar


-- Received on Wed Jan 09 2013 - 10:22:54 CET

Original text of this message