Re: Intermittent ORA 600 [kdsgrp1]
- From: Tanel Poder <tanel@xxxxxxxxxxxxxx>
- To: arvind.kumar2@xxxxxxxx
- Date: Thu, 10 Jan 2013 14:43:36 +0700
Arvind,
The kdsgrp1 function stands for "kernel data scan get row piece" - in other
words the function which can extract a row from a buffer. When an ORA-600
happens in this function, then Oracle thinks it must be some sort of a data
corruption in buffer cache and dumps the latest redo *that modified this
buffer* into a tracefile. That's why the "log file sequential read" wait
events show up in a foreground session ... Note that you might not
necessarily have a (memory) corruption happening as the ORA-600 error might
be raised because of some software bug (I've seen such issues with spatial
datatypes ...)
--
Tanel Poder
New Online Training! - http://blog.tanelpoder.com/seminar
The Voicee App - http://voic.ee
On Wed, Jan 9, 2013 at 4:22 PM, Kumar, Arvind <arvind.kumar2@xxxxxxxx>wrote:
> Many thanks Niall,
> I have raised a SR and still waiting for the solution on 11.2.0.2 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 [mailto:niall.litchfield@xxxxxxxxx]
> Sent: Wednesday, January 09, 2013 1:55 PM
> To: Kumar, Arvind
> Cc: ORACLE-L
> 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" <arvind.kumar2@xxxxxxxx<mailto:
> arvind.kumar2@xxxxxxxx>> wrote:
> Greetings all,
> Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 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
>
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts: