Ora 00600 internal error code arguments kdsgrp1

При select приложение падает с ошибкой ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [].

Чтение нужно начать с ORA-600 [kdsgrp1] (Doc ID 285586.1) здесь собраны все известные баги. Так же есть статья Causes and Solutions for ora-600 [kdsgrp1] (Doc ID 1332252.1) где рассматриваются основные причины ORA-00600 kdsgrp1.

В моем случае, причина ошибки — поврежденный индекс (index corruption) — это сразу видно по файлу трассировки.

Для разрешения ситуации нужно удалить и заново пересоздать поврежденный индекс.

В alert логе для этой ошибки есть запись, которая указывает на файл трассировки

Mon Feb 20 16:57:17 2012
Errors in file d:\oracle\product\10.2.0\admin\udump\dump_ora_6984.trc:
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []

В файле трассировки есть что-то типа (можно искать по «SESSION ID»)

*** 2012-02-20 16:57:17.079
*** ACTION NAME:() 2012-02-20 16:57:17.016
*** MODULE NAME:(TOAD 9.0.1.8) 2012-02-20 16:57:17.016
*** SERVICE NAME:(ud) 2012-02-20 16:57:17.016
*** SESSION ID:(131.893) 2012-02-20 16:57:17.016
row 0141c319.1e continuation at
file# 5 block# 115481 slot 31 not found
**************************************************
KDSTABN_GET: 0 . ntab: 1
curSlot: 31 . nrows: 32
**************************************************
*** 2012-02-20 16:57:17.094
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []
Current SQL statement for this session:
SELECT
ROWID, ID, RE_ID, TYPE_CODE,
DEPT_ID, DIF_PURPOSE
FROM REG_RT.RE_PURPOSES Tbl
Where
re_id = 81653029
check trace file d:oracleproduct10.2.0db_1rdbmstraceud_ora_0.trc for preloading .sym file messages
—— Call Stack Trace ——
calling call entry argument values in hex
location type point (? means dubious value)
——————— ——— ——————— —————————-
_ksedst+38 CALLrel _ksedst1+0 0 1
_ksedmp+898 CALLrel _ksedst+0 0
_ksfdmp+14 CALLrel _ksedmp+0 3
_kgerinv+140 CALLreg 00000000 E66A3E0 3
_kgeasnmierr+19 CALLrel _kgerinv+0 E66A3E0 DA80020 3A29FF0 0
EEECD08
_kdsgrp+733 CALLrel _kgeasnmierr+0 E66A3E0 DA80020 3A29FF0 0
_kdsfbr+174 CALLrel _kdsgrp+0 8977480 0 8977480
_qertbFetchByRowID+ CALLrel _kdsfbr+0 8977480 4CC7610 0 1 0 0
840 8977428 0
_kpofrws+235 CALL. 00000000 271BD4CC 127F4B4 EEED1A4 1F4
_opifch2+7757 CALLrel _kpofrws+0 5355CD4 271BEAD8 127F4B4
EEED1A4 1F4
_opifch+51 CALLrel _opifch2+0 89 5 EEED2C8
_opiodr+1286 CALLreg 00000000 5 2 EEEF68C
_ttcpip+853 CALLreg 00000000 5 2 EEEF68C 2
_opitsk+1107 CALL. 00000000
_opiino+1087 CALLrel _opitsk+0 0 0
_opiodr+1286 CALLreg 00000000 3C 4 EEEFC28
_opidrv+819 CALLrel _opiodr+0 3C 4 EEEFC28 0
_sou2o+45 CALLrel _opidrv+0 3C 4 EEEFC28
_opimai_real+112 CALLrel _sou2o+0 EEEFC1C 3C 4 EEEFC28
_opimai+92 CALLrel _opimai_real+0 2 EEEFC54
_OracleThreadStart@ CALLrel _opimai+0
4+726
7C824826 CALLreg 00000000

В выделеном тексте видно что поврежден блок 115481 файла 5. С помощью запроса выявляем поврежденный индекс и пересоздаем его.

Источник

Detailed Steps for Troubleshooting ORA-00600 [kdsgrp1] (Doc ID 1492150.1)

Last updated on JANUARY 30, 2022

Applies to:

Purpose

This document provides detailed steps for troubleshooting the ORA-00600 [kdsgrp1] internal error.It contains information from other documents including the documents shown in the references section.

Instructions for the Reader

First, please review Document 1332252.1 — Causes and Solutions for ora-00600 [kdsgrp1]. It is an excellent document which explains the error and possible causes/solutions for this particular error.

Troubleshooting Steps

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

In this Document

Purpose

Troubleshooting Steps

References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Источник

Database Startup Fails with ORA-00600: internal error code, arguments: [kdsgrp1] (Doc ID 2237293.1)

Last updated on JANUARY 04, 2021

Applies to:

Symptoms

Database startup Fails with ORA-00600: internal error code, arguments: [kdsgrp1] and ORA-1092

Total System Global Area 1068937216 bytes
Fixed Size 2235208 bytes
Variable Size 784336056 bytes
Database Buffers 276824064 bytes
Redo Buffers 5541888 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [],
[], [], [], [], []
Process ID: 1747472
Session ID: 265 Serial number: 3

Alert log shows the below information

Call stack :-ktgRunStmt1В ktsmg_summary_turВ ktsmg_summary_undoinfoВ ktusmout_online_ut В ktusmiut_init_ut

Читайте также: Чего не хватает error

Changes

Cause

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

In this Document

Symptoms

Changes

Cause

Solution

References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Источник

Spatial Query Fails With ORA-00600 [kdsgrp1] (Doc ID 2057125.1)

Last updated on FEBRUARY 12, 2019

Applies to:

Symptoms

Database reporting the following error(s) in the alert.log:

The internal error is raised for a Spatial query:

and the call stack trace is rather generic for this ORA-600:

Checking for TABLE/INDEX inconsistency :-
В
analyze table validate structure cascade;
В
table is analyzed successfully.

Changes

Cause

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

In this Document

Symptoms

Changes

Cause

Solution

References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Источник

ORA-00600 [kdsgrp1] In Database Alert Log

ORA-00600 [kdsgrp1]

One of my clients has a database job that runs weekly in the early hours of the morning. I have a cron job configured on their server to check the database alert log for errors on a regular basis and email me with any that it finds.

This morning when I checked my emails there was one from that job reporting the following:

Errors in file /u01/app/oracle/10.2/rdbms/log/ _ora_194248.trc:

ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [] Wed May 27 03:17:28 2015

ORA-00600 errors are internal Oracle errors and on the Oracle support site they have a tool where you can enter the arguments for the error (in this case kdsgrp1) and see if there is anything on the Oracle support site about it.

I duly did this and it returned a whole range of known bugs and issues. The one that looked likely to be most relevant for my situation was one that said the “error is thrown when a fetch operation fails to find the expected row.”

It also said this could be caused by any of the following:

Lost writes
Parallel DML issues
Index corruption
Data block corruption
Consistent read [CR] issues
Buffer cache corruption

As the client had recently had a disk failure which resulted in us having to recreate some indexes, I immediately suspected index corruption to be the cause.

The first thing to do in this situation is to examine the trace file named in the alert log and determine the SQL that caused the ORA-00600 [kdsgrp1] error.

A good way to do this is to open the trace file and search for the text “Plan Table”. This will show you the Explain Plan for the SQL that was being executed when the error occurred.

In this case, it was a select statement that was doing a “table access by index rowid”. Armed with the index name from this Explain Plan, I could then check the index for corruption.

The way to check for index corruption is to use the

analyze index validate structure;

command which I ran using sqlplus and I immediately received the ORA-00600 [kdsgrp1] error, confirming a problem with the index.

I used PL/SQL Developer to generate the SQL statement to create the offending index. Then I dropped the index and recreated it using this SQL statement I’d just generated. I then re-analyzed the index, this time with no problems.

Источник