I have SQL SELECT statement that returns:
Error: ORA-00600: internal error code, arguments: [qerpfAllocateR], [], [], [], [], [], [], []
If I narrow my results by adding one more condition in WHERE clause everything is ok.
Anyone knows what is happening?
EDIT:
select * from ( select tbl1.col1, ..., tbl1.points
from table1 tbl1, table2 tbl2
where tbl1.tbl2FK = tbl2.PK and
tbl2.col1 = someNumber and
tbl1.dateColumn = to_date('27-10-2008','dd-mm-yyyy')
order by tbl1.points desc ) s where rownum <= 3
EDIT2:
My DB admin suggested solution that works:
select * from (select rank() over (order by tbl1.points desc) rank,
tbl1.col1, ..., tbl1.points
from table1 tbl1, table2 tbl2
where tbl1.tbl2FK = tbl2.PK and
tbl2.col1 = someNumber and
tbl1.dateColumn = to_date('27-10-2008','dd-mm-yyyy')) s
where s.rank <= 3
OMG Ponies
326k82 gold badges523 silver badges502 bronze badges
asked Feb 4, 2009 at 14:19
2
The ORA-0600 error indicates an internal error in Oracle itself. You’re most likely hitting an Oracle bug.
If you go to http://metalink.oracle.com, you can look up the exact bug, if it is known, by pasting the «arguments» and full stack trace into the ORA-0600 lookup tool. See metalink note 153788.1.
If there’s a known bug with that description, it’s likely that there’s already a patch available for you to download and install. If it’s not a known bug, contact support.
answered Feb 4, 2009 at 14:29
ApocalispApocalisp
34.8k8 gold badges106 silver badges156 bronze badges
Good luck with getting support from Oracle…
Seriously though, every time I hit this problem, rearranging the query a little bit usually helps. Maybe fiddling around with the indexes a bit.
answered Feb 4, 2009 at 14:40
Tamas CzinegeTamas Czinege
119k40 gold badges151 silver badges176 bronze badges
4
ORA-00600 basically means you’ve crash the oracle server (not the instance, just the server servicing your request).
There will almost always be a trace file in your bdump location. This likely wont be a lot of help you to, but will be very helpful to oracle support.
This is generally caused by an oracle bug, and from experience, there isn’t a lot you can do about them except raise a SR via metalink (this is the recommended solution from Oracle). They will try to replicate the issue and with any luck, if its a bug it will eventually find its way into a patch.
In the immediate term though (eg, days — months) the main realistic solution is work around it.
While raising the SR doesn’t really do alot to help you and can be a frustrating experience, its worth doing, as it might save someone else time once the bug is fixed.
answered Feb 6, 2009 at 4:01
Matthew WatsonMatthew Watson
14.1k9 gold badges62 silver badges82 bronze badges
0
These bugs are usually related to the optimizer. I think even the smallest change in the query like switching the order of table1 and table2 in the FROM clause might force the optimizer to choose a different plan that will not encounter this error.
answered Feb 4, 2009 at 16:12
My solution:
Problem
THIS DIDNT WORK WAS GETTING ERROR [0600]
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> recover database
Media recovery complete.
SQL> alter database open
2
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[108], [615], [655], [], [], [], [], [], [], []`
HERE IS MY SOLUTION TO THE PROBLEM:
SQL> Startup mount
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> shutdown abort
ORACLE instance shut down.
SQL>
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> Show parameter control_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string C:\APP\USER\ORADATA\ORACLEDB\C
ONTROL01.CTL, C:\APP\USER\FAST
_RECOVERY_AREA\ORACLEDB\CONTRO
L02.CTL
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT'
2
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT';
MEMBER
--------------------------------------------------------------------------------
GROUP# STATUS
---------- ----------------
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
3 CURRENT
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 4234808 generated at 01/21/2014 18:31:05 needed for thread 1
ORA-00289: suggestion :
C:\APP\USER\FAST_RECOVERY_AREA\ORACLEDB\ARCHIVELOG\2014_01_22\O1_MF_1_108_%U_.AR
C
ORA-00280: change 4234808 for thread 1 is in sequence #108
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
FINALLY IT WORKED:
answered Jan 23, 2014 at 3:23
z atefz atef
7,1383 gold badges55 silver badges50 bronze badges
ORA-00600 generally means that there is something highly unexpected and it might be linked to the database corruption. The symptoms can be that query works or not depending on how it is formulated.
Life example:
- LOB field update went wrong for a particular row with id=<ID>
- The row is not visible with SELECT * FROM <table>
- But: SELECT * FROM <table> WHERE id=<ID> fails to execute and gives ORA-006000.
(Possible) Solution used to the above example
- export all accessible table contents
- delete table
- reimport the contents
Good Luck!
answered Jan 23, 2019 at 9:57
Witold KaczurbaWitold Kaczurba
9,8753 gold badges58 silver badges67 bronze badges
I have seen errors like this when there are XMLTYPE columns in the table, using PL/SQL Developer. It wouldn’t happen if I had PL/SQL Developer create the query skeleton for me because it would add some syntax to the XMLTYPE column request, I can’t remember exactly what.
answered Feb 4, 2009 at 14:23
Dave SwerskyDave Swersky
34.5k9 gold badges78 silver badges118 bronze badges
1
I encountered this in a situation with a record type that involved USER_TAB_COLS. I had used VARCHAR2(128) for the field in the record that was supposed to hold USER_TAB_COLS.DATA_DEFAULT. Well, that’s a LONG, for whatever reason, and while this mapping worked OK when I ran the code in a command window (PL/SQL Developer), it failed when I embedded the very same in an umbrella script that did all sorts of tasks. Once I set the data type of the record correctly to use an anchored type (USER_TAB_COLS.DATA_DEFAULT%TYPE) instead of VARCHAR2(128), the sp that does the work runs in either context. I was buffaloed by the fact that it worked ‘stand-alone’ but not when called from another script.
Here is the record type I was using:
TYPE PON_DICT_RECORD_TYPE Is RECORD(
TABLE_NAME USER_TAB_COLS.TABLE_NAME%TYPE,
PK NUMBER(1),
REQUIRED NUMBER(1),
COL_ORDER NUMBER(3),
COL_NAME USER_TAB_COLS.COLUMN_NAME%TYPE,
DATA_TYPE USER_TAB_COLS.DATA_TYPE%TYPE,
LENGTH NUMBER(4),
SCALE NUMBER(2),
DEF_VALUE USER_TAB_COLS.data_default%TYPE, -- a LONG in U T C
ID NUMBER(1),
FORCE_DEF NUMBER(1),
ACTIVE_PK NUMBER(1),
NEW_COL_OLD_TABLE NUMBER(1),
REPLACEMENT_KEY NUMBER(1)
);
TYPE PON_DICT_TABLE_TYPE IS TABLE OF PON_DICT_RECORD_TYPE;
pdtab PON_DICT_TABLE_TYPE;where you can see the definition of field DEF_VALUE is now an anchored type.
This was bizarre, I have to say. I would have expected it to fail in both contexts.
answered Jun 14 at 18:56
AllenAllen
5465 silver badges12 bronze badges
I have SQL SELECT statement that returns:
Error: ORA-00600: internal error code, arguments: [qerpfAllocateR], [], [], [], [], [], [], []
If I narrow my results by adding one more condition in WHERE clause everything is ok.
Anyone knows what is happening?
EDIT:
select * from ( select tbl1.col1, ..., tbl1.points
from table1 tbl1, table2 tbl2
where tbl1.tbl2FK = tbl2.PK and
tbl2.col1 = someNumber and
tbl1.dateColumn = to_date('27-10-2008','dd-mm-yyyy')
order by tbl1.points desc ) s where rownum <= 3
EDIT2:
My DB admin suggested solution that works:
select * from (select rank() over (order by tbl1.points desc) rank,
tbl1.col1, ..., tbl1.points
from table1 tbl1, table2 tbl2
where tbl1.tbl2FK = tbl2.PK and
tbl2.col1 = someNumber and
tbl1.dateColumn = to_date('27-10-2008','dd-mm-yyyy')) s
where s.rank <= 3
OMG Ponies
326k82 gold badges523 silver badges502 bronze badges
asked Feb 4, 2009 at 14:19
2
The ORA-0600 error indicates an internal error in Oracle itself. You’re most likely hitting an Oracle bug.
If you go to http://metalink.oracle.com, you can look up the exact bug, if it is known, by pasting the «arguments» and full stack trace into the ORA-0600 lookup tool. See metalink note 153788.1.
If there’s a known bug with that description, it’s likely that there’s already a patch available for you to download and install. If it’s not a known bug, contact support.
answered Feb 4, 2009 at 14:29
ApocalispApocalisp
34.8k8 gold badges106 silver badges156 bronze badges
Good luck with getting support from Oracle…
Seriously though, every time I hit this problem, rearranging the query a little bit usually helps. Maybe fiddling around with the indexes a bit.
answered Feb 4, 2009 at 14:40
Tamas CzinegeTamas Czinege
119k40 gold badges151 silver badges176 bronze badges
4
ORA-00600 basically means you’ve crash the oracle server (not the instance, just the server servicing your request).
There will almost always be a trace file in your bdump location. This likely wont be a lot of help you to, but will be very helpful to oracle support.
This is generally caused by an oracle bug, and from experience, there isn’t a lot you can do about them except raise a SR via metalink (this is the recommended solution from Oracle). They will try to replicate the issue and with any luck, if its a bug it will eventually find its way into a patch.
In the immediate term though (eg, days — months) the main realistic solution is work around it.
While raising the SR doesn’t really do alot to help you and can be a frustrating experience, its worth doing, as it might save someone else time once the bug is fixed.
answered Feb 6, 2009 at 4:01
Matthew WatsonMatthew Watson
14.1k9 gold badges62 silver badges82 bronze badges
0
These bugs are usually related to the optimizer. I think even the smallest change in the query like switching the order of table1 and table2 in the FROM clause might force the optimizer to choose a different plan that will not encounter this error.
answered Feb 4, 2009 at 16:12
My solution:
Problem
THIS DIDNT WORK WAS GETTING ERROR [0600]
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> recover database
Media recovery complete.
SQL> alter database open
2
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[108], [615], [655], [], [], [], [], [], [], []`
HERE IS MY SOLUTION TO THE PROBLEM:
SQL> Startup mount
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> shutdown abort
ORACLE instance shut down.
SQL>
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> Show parameter control_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string C:\APP\USER\ORADATA\ORACLEDB\C
ONTROL01.CTL, C:\APP\USER\FAST
_RECOVERY_AREA\ORACLEDB\CONTRO
L02.CTL
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT'
2
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT';
MEMBER
--------------------------------------------------------------------------------
GROUP# STATUS
---------- ----------------
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
3 CURRENT
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 4234808 generated at 01/21/2014 18:31:05 needed for thread 1
ORA-00289: suggestion :
C:\APP\USER\FAST_RECOVERY_AREA\ORACLEDB\ARCHIVELOG\2014_01_22\O1_MF_1_108_%U_.AR
C
ORA-00280: change 4234808 for thread 1 is in sequence #108
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
FINALLY IT WORKED:
answered Jan 23, 2014 at 3:23
z atefz atef
7,1383 gold badges55 silver badges50 bronze badges
ORA-00600 generally means that there is something highly unexpected and it might be linked to the database corruption. The symptoms can be that query works or not depending on how it is formulated.
Life example:
- LOB field update went wrong for a particular row with id=<ID>
- The row is not visible with SELECT * FROM <table>
- But: SELECT * FROM <table> WHERE id=<ID> fails to execute and gives ORA-006000.
(Possible) Solution used to the above example
- export all accessible table contents
- delete table
- reimport the contents
Good Luck!
answered Jan 23, 2019 at 9:57
Witold KaczurbaWitold Kaczurba
9,8753 gold badges58 silver badges67 bronze badges
I have seen errors like this when there are XMLTYPE columns in the table, using PL/SQL Developer. It wouldn’t happen if I had PL/SQL Developer create the query skeleton for me because it would add some syntax to the XMLTYPE column request, I can’t remember exactly what.
answered Feb 4, 2009 at 14:23
Dave SwerskyDave Swersky
34.5k9 gold badges78 silver badges118 bronze badges
1
I encountered this in a situation with a record type that involved USER_TAB_COLS. I had used VARCHAR2(128) for the field in the record that was supposed to hold USER_TAB_COLS.DATA_DEFAULT. Well, that’s a LONG, for whatever reason, and while this mapping worked OK when I ran the code in a command window (PL/SQL Developer), it failed when I embedded the very same in an umbrella script that did all sorts of tasks. Once I set the data type of the record correctly to use an anchored type (USER_TAB_COLS.DATA_DEFAULT%TYPE) instead of VARCHAR2(128), the sp that does the work runs in either context. I was buffaloed by the fact that it worked ‘stand-alone’ but not when called from another script.
Here is the record type I was using:
TYPE PON_DICT_RECORD_TYPE Is RECORD(
TABLE_NAME USER_TAB_COLS.TABLE_NAME%TYPE,
PK NUMBER(1),
REQUIRED NUMBER(1),
COL_ORDER NUMBER(3),
COL_NAME USER_TAB_COLS.COLUMN_NAME%TYPE,
DATA_TYPE USER_TAB_COLS.DATA_TYPE%TYPE,
LENGTH NUMBER(4),
SCALE NUMBER(2),
DEF_VALUE USER_TAB_COLS.data_default%TYPE, -- a LONG in U T C
ID NUMBER(1),
FORCE_DEF NUMBER(1),
ACTIVE_PK NUMBER(1),
NEW_COL_OLD_TABLE NUMBER(1),
REPLACEMENT_KEY NUMBER(1)
);
TYPE PON_DICT_TABLE_TYPE IS TABLE OF PON_DICT_RECORD_TYPE;
pdtab PON_DICT_TABLE_TYPE;where you can see the definition of field DEF_VALUE is now an anchored type.
This was bizarre, I have to say. I would have expected it to fail in both contexts.
answered Jun 14 at 18:56
AllenAllen
5465 silver badges12 bronze badges
ORA-00600
ORA-00600: внутренний код ошибки, аргументы: [номер],[?],[?], [?],[?],[?]
Причина:
Это заражающая внутренняя ошибка для особых программ ORACLE. Она показывает, что процесс встретил непредвиденные условия. Первый аргумент это номер внутренней ошибки, другие аргументы, это различные переменные, имена, и строки символов. (смотри «работа с внутренними ошибками» в главе 1 для полной информации.)
Действие:
Информируйте об этой ошибке как о программной вашего представителя Customer Support.
Ошибка ORA-0600 является внутренним кодом ошибки для программных исключений Oracle. Её возникновение указывает на то, что процесс столкнулся на низком уровне с неожиданным условием.
Ошибка ORA-0600 включает список аргументов в квадратных скобках:
ORA-00600 "internal error code, arguments: [%a], [%b], [%c], [%d], [%e]"
Первым аргументом является внутренний номер сообщения или символьная строка. Этот аргумент и номер версии базы данных является первостепенным в идентификации первопричины и потенциального воздействия на базу данных. Остальные аргументы используются, что бы предоставить дополнительную информацию (например, значения внутренних переменных и т.д.).
В зависимости от вида первого аргумента, в Oracle имеются два типа ошибок ORA-0600:
- первый аргумент является числом, которое отражает исходный компонент или слой, в котором происходит ошибка.
- первый аргумент является мнемоникой, которая указывает на исходный модуль, где произошла ошибка. Этот тип внутренней ошибки более предпочтителен в настоящее время.
Категории ошибок ORA-0600 ранжированные по номеру
В следующей таблице приведена информация относительно внутренних числовых кодов ошибок ORA-0600, используемых в Oracle.
Читать далее…
Категории ошибок ORA-0600 ранжированные по мнемонике
Следующая таблица детализирует возможные мнемоники ошибок ORA-0600.
Читать далее…
Справочник ошибок ORA-0600
ORA-00600: internal error code, arguments: [1113]
Последствия:
Сбой процесса, возможный сбой экземпляра.
Версия:
от 6.0 до 9.2
Причины возникновения:
Попытка освободить state object, хотя он уже находиться в свободных списках. Нарушение целостности в памяти SGA или из-за bug в плохом управлении state objects.
Действия:
Проанализировать дамп PMON, установить заплатки на bug.
ORA-00600: internal error code, arguments: [4193], [a], [b]
Аргументы:
[a] – Номер изменения (SCN) записи в серменте отката (Undo), [b] SCN записи в журнале повторного выполнения (Redo)
Последствия:
Сбой процесса, возможное повреждение сегмента отката, невозможность продолжения наката журналов на STANDBY.
Версия:
от 6.0 до 10.1
Источник:
KERNEL TRANSACTION UNDO
Причины возникновения:
Было обнаружено несоответствие между журнальной записью и записью в сегменте отката.
Действия:
Перейти на новую версию Oracle (10.2.0.5, 11.2.0.1); Восстановить экземпляр из резервной копии.
ORA-00600: internal error code, arguments: [12333], [a], [b],[c],[d]
Последствия:
Отказ процесса. Физического искажения нет.
Версия:
от 6.0 до 9.2
Источник:
USER/ORACLE INTERFACE LAYER
Причины возникновения:
В результате сетевой ошибки получены плохие данные, приложение клиента послало неправильные данные, данные в сетевом буфере были записаны поверх, всевозможные bug (столбцы LONG).
Действия:
Проверить сетевое соединение и настройки NLS, заменить версию клиента Net на более новую.
ORA-00600: internal error code, arguments: [13001]
Последствия:
Физического искажения нет.
Версия:
от 8.0 до 10.2
Причины возникновения:
Возникает при удалении строк из таблицы, в случаях когда запись уже удалена. Такое обычно происходит если в таблице есть внешний ключ на столбец в этой же таблице. По своей сути не является полноценной ошибкой.
Действия:
Переделать внешний ключ.
ORA-00600: internal error code, arguments: [15419], [a]
Последствия:
Отказ процесса. Физического искажения нет.
Версия:
от 7.0 до 10.1
Источник:
Kernel Kompilation pl/sql Compiler
Причины возникновения:
Всевозможные bug. Для большей информации смотреть дополнительные ошибки в trc файле. Bug: 2829071, 2588469, 2437995
Действия:
Установить заплатки на bug. Если не помогает, модифицируйте PL/SQL код.
ORA-00600: internal error code, arguments: [15735], [a], [b]
Аргумент:
[a] — значение parallel_execution_message_size в котором нуждается запрос, [b] — текущее значение parallel_execution_message_size
Последствия:
Ошибка с записью в trace файл. Физического искажения нет.
Версия:
от 10.1 до 10.2
Причины возникновения:
BUG:5462624.
Действия:
Открыть trc файл ошибки. Найти sql оператор. Для таблиц этого оператора выполнить запрос select table_name, degree from dba_tables where table_name = ». Выбрать таблицы у которых degree ‘1’. Выполнить для каждой таблицы команду alter table noparallel. В качестве второго способа можно порекомендовать увеличить значение параметра parallel_execution_message_size.
ORA-00600: internal error code, arguments: [16607]
Последствия:
Сбой процесса, повреждения данных нет.
Версия:
от 8.0 до 10.1
Источник:
Kernel Generic Library cache Subordinate set/cache manager
Причины возникновения:
Была произведена попытка получить подчиненный элемент, но при поиске, куча памяти для данного элемента не была закреплена.
Действия:
Установить заплатки на bug.
ORA-00600: internal error code, arguments: [17090],[a], [b],[c],[d]
Последствия:
Отказ процесса. Физического искажения нет.
Версия:
от 7.0 до 8.1
Источник:
GENERIC CODE LAYER
Причины возникновения:
Всевозможные bug.
Действия:
Уничтожьте сеанс и связанный с ним процесс.
ORA-00600: internal error code, arguments: [17271], [instantiation space leak]
Последствия:
Сбой процесса. Повреждения данных нет.
Версия:
до 10.2.0.5
Источник:
Kernel Generic Instantiation manager
Причины возникновения:
Исключение возникает при попытке Oracle деинстанцировать (уничтожить экземпляр) разделяемый объект (курсор) во время выхода из сеанса. В этот момент, Oracle проходит связанный список разделяемых объектов для деинстанцирования, и находит, что объект был помечен как не разделяемый. Этого не должно быть, поэтому возникает исключение. Может проявляться при работе с распределёнными базами данных.
Действия:
Игнорировать ошибку. Если ошибка повторяется, то идентифицировать курсор в trace файле и переделать, или поставить последний патч Oracle закрывающий баги.
ORA-00600: internal error code, arguments: [25012], [a], [b]
Аргумент:
[a] — номер табличного пространства, [b] — относительный номер файла БД
Последствия:
Возможно физическое искажение.
Версия:
от 8.0 до 10.1
Источник:
KERNEL FILE MANAGEMENT TABLESPACE COMPONENT
Причины возникновения:
Всевозможные bug ( 4305391, 3915343, 3900237, 3771508, 3751874, 3430832, 3258674, 3150268, 3070856, 2531519, 2526334, 2287815, 2214167, 2212389, 2189615, 2184731, 1968815, 1949273, 1872985).
Действия:
Установить заплатки на bug.
ORA-00600: internal error code, arguments: [ktspgsb-1]
Последствия:
Повреждение данных.
Версия:
До 10.2.0.5
Причины возникновения:
Ошибка возникает если в объекте (таблице) присутствуют логически повреждённые блоки. Выполнение команд (TRUNCATE, INSERT и т.д.) применительно к объекту приводит к этой ошибке.
Действия:
Пересоздание объекта.
ORA-00600: internal error code, arguments: [pfri.c: pfri8: plio mismatch ]
Причины возникновения:
Несоответствие создания экземпляра PL/SQL объекта. Вероятнее всего возникает из-за инвалидации PL/SQL объекта (bug 9691456, зафиксирован в 11.2.0.2). Проявлялась в триггере на версии 10.2.0.5.
Действия:
Приведение PL/SQL объекта в нормальный статус.
Oracle database is the most popular database among the database industry because of its accuracy and performance. It is a Relational database management system (RDBMS) and capable to store and manage lots of new entries in a sufficient manner and why so it is one of popular database.
The majority of getting errors related to Oracle database increases if you do not have enough knowledge of Oracle. Yes, it is a fact and due to having less knowledge of using Oracle database, users get different errors messages and one of them is the ora-00600 internal error code.
One more issue with this error is that it can normally generate along with arguments encloses in a square bracket, and here occurs the critical situation because the meaning of these enclosed arguments alters with the version of the database. It is very difficult for a database administrator to verify the reason for the database error. This error also gets more difficult when more than one ORA-00600 error occurs because due to this the generated trace files and log files become large in number.
If you are the one who got this error then do not worry, you have come to the right place. I am saying so because here you will get to know how to fix ora-00600 internal error code.
Why ORA-00600 Error Occurs?
There are several causes due to which ORA_00600 internal error code occurs. It is a generic internal error number to execute Oracle program. This error indicates that the process has some unexpected conditions. The first argument is internal message number and the other arguments are several names, character strings and numbers. However, the number may change the meaning of different Oracle versions. Here are some of the reasons of getting this error:
#1: File Corruption: When an Oracle supported file has been corrupted then you may get ora-00600 internal error code.
#2: Timeouts: While connecting with the database the timeout occurred or the query runs for a long time and timeout occurs then this internal error code takes place.
#3: Failed Data Checks In the Memory: Due to the failed data checks in the memory, ora-00600 internal error code occurs.
#4: Hardware/Memory/IO: When the hardware is incompatible or the memory is full in Oracle version and you still work on it may cause this error to take place.
#5: Incorrectly Restored Files: When the Oracle files are restored in an improper way then this error will occur.
There are several reasons for ORA-00600 error like compatibility issues to database block error. Sometimes, this kind of error remains unsolvable. However, it is quite difficult to find the root cause of this error.
Several reasons are there ways with the help of which you will be able to fix ora-00600 internal error code. Here, I have tried my best to let you know how to resolve ora-00600 internal error code. Here are some of the major solutions you should try:
Fix #1: Writes Error Message In Alert Log & Trace File
The very first option you can try to fix ora-00600 internal error code is to write error message and trace file in alert.log file. The Oracle engine will write the error in alert.log file. The trace file location will find in alert.log file.
Fix #2: Try Other Solutions Based On Error Code Examples
You may get several errors reported within the space of a few minutes that starts with the ORA-00600 error. Well, apart from fixing ora-00600 error, you can check trace files and alert logs. Another solution you can try is to find the source of the issue is important. Most of the time, you will not be able to find the source by checking the alert or trace the alert logs. Also, these errors will not give you clear information about what has happened with the server.
Here are some great examples that might help the Oracle developers or users and DBAs to restore this issue:
Example #1:
ORA-00600: internal error code, arguments: [kxtotolc_lobopt], [], [], [], [], [], [], [], [], [], [], []
00600. 00000 – “internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]”
Cause of this error: This example is the generic internal error number for Oracle program exceptions. Also, this error indicates that a process has encountered an exceptional condition.
How To Fix This Issue
If you are updating or inserting the CLOB column value as null with the use of merge statement and the merge the statement table has trigger. The same null CLOB column value if you try to update or insert CLOB value in another table with the use of trigger then you will get ora-00600 internal error code. You will also notice that the session is closed automatically, you will also get this error in both Oracle 11g as well as 12c.
Below are the steps to fix this issue:
- First of all, you have to create a table CLOB_ table(sno number, c_clob clob);
- Next, you have to create table table test_Clob_table_stg as select * from test_Clob_table;
- After this, you are required to create a trigger on Clob_table table and then you have to insert data in staging table test_Clob_table_stg using trigger:
CREATE OR REPLACE trigger test_Clob_table_trg AFTER INSERT ON Clob_table
FOR EACH ROW
DECLARE
BEGIN
INSERT INTO test_Clob_table_stg VALUES(:new.sno,:new.c_clob);
EXCEPTION
WHEN others THEN
NULL;
END;
/
- You have to then run the below query.
MERGE INTO Clob_table a USING (
select 1 AS sno, null AS C_CLOB from dual) b
ON (a.sno = b.sno)
WHEN MATCHED THEN
UPDATE SET C_CLOB = b.C_CLOB
WHEN NOT MATCHED THEN
INSERT (a.sno,a.C_CLOB) VALUES (b.sno,b.C_CLOB);
Example #2:
Error Code:
ORA-00600: internal error code, arguments: [15851], [3], [3499], [2], [1], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [15851], [3], [3499], [2], [1], [], [], [], [], [], [], []
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at “SIEBEL_ODS.MS_CCM_UTILITIES”, line 2866
ORA-04088: error during execution of trigger ‘SIEBEL_ODS.MS_CCM_TI_INVESTIGATION’
00600. 00000 – “internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]”
Cause of this example: This example is the generic internal error number for Oracle program exceptions. This error message indicates that a process has encountered an exceptional condition.
How To Fix This Issue:
The other function used in trigger has variable size issue because you got this error, this trigger has created on merge statement table that is sued in “_P” package. This error won’t track the error log tables until if you run all the statement outside of the package, you get error in si_application_error_log.
Example #3:
SQL Error: ORA-00600: internal error code, arguments: [13013], [5001], [158796], [30437895], [0], [30437895], [17], [], [], [], [], []
How To Fix This Issue:
You can create index on one table for improving the performance of query, on same table you are updating data in some stages.
This will work and improve the performance in local examples and customer testing examples, but users get ora-00600 internal error code in UAT after applying the patch, whenever users has done update statement stage flow. You will get the below update statement highlighted in trace file with the error message, it helped users to debug the issue and also you will get some more information in alert log for an internal error.
Query to trace file with error message:
UPDATE MS_ITC_AUDIT_V SET STATUS = ’38’, AUDIT_STATUS = ’38’ WHERE AUDIT_ID = :B1 AND INSTANCE_ID = (SELECT MAX(INSTANCE_ID) FROM MS_ITC_AUDIT_V WHERE AUDIT_ID = :B1 );
Ultimate Solution: Try Oracle File Repair Tool To Fix ORA-00600 Internal Error Code
Apart from all these solutions that are mentioned above, if you are unable to fix ora-00600 error then you can try Oracle File Repair Tool. This tool will allow you to fix this error and recover Oracle database easily. This tool has some great features that will let you know how to fix ora-00600 internal error code. I am sure that you will not get disappointed after trying this tool. All you have to do is to download and install this tool and follow the step by step instructions to fix and recover oracle database that shows ora-00600 internal error code.
Steps To Fix ORA-00600 Internal error Code
Step 1: Search the Initial screen of Stellar Phoenix Oracle Repair & Recovery with a pop-up window showing options to select or search corrupt Oracle databases on your computer.
Step 2: Click Scan File to initiate the scan process after selecting the oracle database. The recoverable database objects get listed in left-side pane.
Step 3: Click an object to see its preview.
Step 4: : Click Start Repair in the icon bar to start the repair process. A pop-up window is displayed which show the steps needed to perform further. Click next and continue.
Step 5: Give the user name, password and path of the blank database where you want to save the repaired database objects.
Step 6: Repairing and restoring various database objects after establishing a connection with blank oracle database.
Final Words
I hope after going through this blog and trying the ways to fix ora-00600 internal error code, you will be able to fix it and recover the Oracle database easily. I have tried my best to provide you the best solution I can. Hope these will not let you down in any manner. All the best to you.
Jacob Martin is a technology enthusiast having experience of more than 4 years with great interest in database administration. He is expertise in related subjects like SQL database, Access, Oracle & others. Jacob has Master of Science (M.S) degree from the University of Dallas. He loves to write and provide solutions to people on database repair. Apart from this, he also loves to visit different countries in free time.