Oracle ORA-00600

Question

У меня есть оператор SQL SELECT, который возвращает:

    Error: ORA-00600: internal error code, arguments: [qerpfAllocateR], [], [], [], [], [], [], []

Если я сузу свои результаты, добавив еще одно условие в предложении WHERE, все будет в порядке.

Кто-нибудь знает, что происходит?

РЕДАКТИРОВАТЬ:

    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:

Мой администратор БД предложил решение, которое работает:

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

Answer 1

Удачи в получении поддержки от Oracle...

Если серьезно, то каждый раз, когда я сталкиваюсь с этой проблемой, перестановка запроса немного помогает. Может быть, немного повозиться с индексами.

Answer 2

Ошибка ORA-0600 указывает на внутреннюю ошибку в самом Oracle. Скорее всего, вы попали в ошибку Oracle.

Наконец, вы выяснили, где находится узкое место? Простое объединение в три таблицы по несколько миллионов строк не займет много времени (я мог бы ожидать секунды или около того, просто просматривая таблицы и запросы), при условии правильной индексации таблиц. Но если вы перемещаете эти строки по медленной или уже привязанной сетевой карте, на сервер приложений с нехваткой памяти и т. Д., Медлительность может вообще не иметь никакого отношения к вашему запросу, а вместо этого к тому, что происходит после запроса. Семь миллионов строк - это довольно много данных для сборки и перемещения, независимо от того, сколько времени займет поиск этих строк. Попробуйте выбрать только одну строку, а не все семь миллионов, и посмотрите, как это выглядит в отличие. Если это быстро, то проблема не в запросе, а в наборе результатов.

Answer 3

Что такое полный запрос?

http://www.orafaq.com/wiki/ORA-00600 предлагает вам сообщить об ошибке оракулу.

Answer 4

ORA-00600 в основном означает, что вы сломали сервер оракула (не экземпляр, а сервер, обслуживающий ваш запрос).

Почти всегда в вашем bdump-файле будет находиться файл трассировки. Это, вероятно, не очень поможет вам, но будет очень полезно для поддержки оракула.

Обычно это вызвано ошибкой оракула, и из опыта вы ничего не можете с этим поделать, кроме как поднять SR через metalink (это рекомендуемое решение от Oracle). Они попытаются повторить проблему и, если повезет, в случае ошибки она в конечном итоге найдет свое место в патче.

Хотя в ближайшей перспективе (например, дни - месяцы) главное реальное решение - обойти это.

Хотя повышение СР на самом деле не очень помогает вам и может быть разочаровывающим опытом, его стоит сделать, так как это может сэкономить кому-то еще время после исправления ошибки.

Answer 5

Мое решение:

(просто верните SO-сообществу) У меня была проблема сегодня, и я не смог решить "запуск моего экземпляра", выполнив шаги, описанные выше, после нескольких часов осмотра я смог решить ее следующим образом.

проблема

В ЭТОЙ РАБОТЕ НЕ ОШИБАЛАСЬ [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], [], [], [], [], [], [], []`

ЗДЕСЬ МОЕ РЕШЕНИЕ ПРОБЛЕМЫ:

    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.

НАКОНЕЦ РАБОТАЛ:

Answer 6

Эти ошибки обычно связаны с оптимизатором. Я думаю, что даже самое маленькое изменение в запросе, такое как переключение порядка таблиц1 и таблиц2 в предложении FROM, может заставить оптимизатор выбрать другой план, в котором эта ошибка не возникнет.

Answer 7

ORA-00600 обычно означает, что есть что-то очень неожиданное, и это может быть связано с повреждением базы данных. Симптомы могут заключаться в том, что запрос работает или нет в зависимости от того, как он сформулирован.

Пример из жизни:

• Не удалось обновить поле большого объекта для конкретной строки с id=
• Строка не отображается с помощью SELECT * FROM
  Но: SELECT * FROM
  WHERE id= не выполняется и выдает ORA-006000.

  (Возможно) решение, использованное в приведенном выше примере

  • экспортировать все доступное содержимое таблицы
  • удалить таблицу
  • повторно импортировать содержимое

  Удачи!

  1

  Источник Поделиться

  user6931119 23 янв '19 в 09:57 2019-01-23 09:57
  2019-01-23 09:57

  Я видел подобные ошибки, когда в таблице есть столбцы XMLTYPE, используя PL/SQL Developer. Этого бы не произошло, если бы PL / SQL Developer создал для меня скелет запроса, потому что это добавило бы некоторый синтаксис в запрос столбца XMLTYPE, я не могу точно вспомнить, что именно.

  0

  Источник Поделиться

  user34796 04 фев '09 в 14:23 2009-02-04 14:23

  2009-02-04 14:23

  Я столкнулся с этим в ситуации с типом записи, включающим USER_TAB_COLS. Я использовал VARCHAR2(128) для поля записи, которое должно было содержать USER_TAB_COLS.DATA_DEFAULT. Ну, по какой-то причине это ДОЛГО, и хотя это сопоставление работало нормально, когда я запускал код в командном окне (PL/SQL Developer), оно не удавалось, когда я встраивал то же самое в зонтичный скрипт, который выполнял всевозможные задачи. . Как только я правильно установил тип данных записи для использования привязанного типа (USER_TAB_COLS.DATA_DEFAULT%TYPE) вместо VARCHAR2(128), sp, выполняющий эту работу, запускается в любом контексте. Меня поразил тот факт, что он работал «автономно», но не при вызове из другого сценария.
  Вот тип записи, который я использовал:

  где вы можете видеть, что определение поля DEF_VALUE теперь является привязанным типом.

  Должен сказать, это было странно. Я ожидал, что это потерпит неудачу в обоих контекстах.

  0

  Источник Поделиться

  user703048 14 июн '23 в 18:56 2023-06-14 18:56

  2023-06-14 18:56

  Что-то здесь по поводу аналогичной проблемы - ваш выбор использует объединения?

  -1

  Источник Поделиться

  user42829 04 фев '09 в 14:28 2009-02-04 14:28

  2009-02-04 14:28
  Другие вопросы по тегам sql oracle plsql ora-00600
  

  [e-mail]
  licensed under cc by-sa 3.0 with attribution

Answer 8

Я видел подобные ошибки, когда в таблице есть столбцы XMLTYPE, используя PL/SQL Developer. Этого бы не произошло, если бы PL / SQL Developer создал для меня скелет запроса, потому что это добавило бы некоторый синтаксис в запрос столбца XMLTYPE, я не могу точно вспомнить, что именно.

Answer 9

Я столкнулся с этим в ситуации с типом записи, включающим USER_TAB_COLS. Я использовал VARCHAR2(128) для поля записи, которое должно было содержать USER_TAB_COLS.DATA_DEFAULT. Ну, по какой-то причине это ДОЛГО, и хотя это сопоставление работало нормально, когда я запускал код в командном окне (PL/SQL Developer), оно не удавалось, когда я встраивал то же самое в зонтичный скрипт, который выполнял всевозможные задачи. . Как только я правильно установил тип данных записи для использования привязанного типа (USER_TAB_COLS.DATA_DEFAULT%TYPE) вместо VARCHAR2(128), sp, выполняющий эту работу, запускается в любом контексте. Меня поразил тот факт, что он работал «автономно», но не при вызове из другого сценария.
Вот тип записи, который я использовал:

где вы можете видеть, что определение поля DEF_VALUE теперь является привязанным типом.

Должен сказать, это было странно. Я ожидал, что это потерпит неудачу в обоих контекстах.

Answer 10

Что-то здесь по поводу аналогичной проблемы - ваш выбор использует объединения?