Как здорово когда утро начинается с ORA-00600: internal error code, arguments: [kcratr1_lostwrt]!!!

dbstalker, 06 ноября

Пасмурное осеннее утро, зеленый чай, Jem - Finally Woken, скоро выходные. И надо же - прибежали пользователи. Не могут подключиться к серверу. А такое хорошее утро было!!!

SQL> conn / as sysdba
Connected.
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [],
[], [], []

Да! Врагу не пожелаешь!

SQL> select file#,status from v$datafile;

     FILE# STATUS
---------- -------
         1 SYSTEM
         2 ONLINE
         3 ONLINE
         4 ONLINE
         5 ONLINE
         6 ONLINE
         7 ONLINE
         8 ONLINE
         9 ONLINE
        10 ONLINE
        11 ONLINE

     FILE# STATUS
---------- -------
        12 ONLINE
        13 ONLINE
        14 ONLINE
        15 ONLINE

15 rows selected.

Ну хоть это радует.

ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET aq_tm_processes=0;
SQL> recover automatic database;
Media recovery complete.
SQL> alter database open;
Database altered.

На этот раз удалось быстро вернуться к чаю! А это вам к сведению:

ERROR:
  ORA-600 [kcratr1_lostwrt]
VERSIONS:
  versions 9.2 to 10.1
DESCRIPTION:
  This error is raised during crash/media recovery. When an instance is restarted following an instance crash, Oracle carries out some checks against the last block that was written to disk  prior to the instance crash.  If Oracle finds an old block, then this suggests a lost write and the  error is raised.
FUNCTIONALITY:
  Cache Redo Application
IMPACT:
INSTANCE FAILURE
POSSIBLE PHYSICAL CORRUPTION
SUGGESTIONS:
  Submit the trace files and alert.log Oracle Support Services for further analysis. This could suggest a hardware/OS problem. There is every chance that a recovery will be needed in order to resolve this problem.  Oracle Support Services will advise on this once suitable evidence has  been provided from the trace files and alert log.

Тэги: ORA-00600, ошибки

ОднаКнопка

1 комментарий

Прокоментировать

Alexander
21 февраля 2011 г. в 15:53

С ошибкой при открытии экземпляра БД первым делом нужно попробовать установить параметр

_two_pass = FALSE

и повторить открытие БД

Если экземпляр поднимется
shutdown immediate
убрать параметр _two_pass = FALSE
startup

Причина ошибки может быть в том, что Вы открываете БД, которая перед этим закрылась аварийно и последнее выполненное Оракл изменение блока   было потеряно. При старте экземпляра Оракл проверяет последнюю версию блока записанного на диск и в случае, когда последняя версия блока не была записана - генерится ORA-600 [kcratr1_lostwrt] .

P.S.

1. Процесс(ы) DBWR после выполнения записи грязных блоков на диски пишут в журналы
специальные журнальные записи, в которых отражается факт этой записи блоков на диск.

2. Восстановление экземпляра происходит в два этапа:
а)
- сканируются журнальные записи, которые необходимо применить к блокам данных;
- затем эти записи сортируются по номеру файла/блока/SCN изменения блока;
- если по ходу были найдены журнальные записи процесса DBWR, то все журнальные записи с SCN
меньшими, чем эта запись DBWR, для таких блоков удаляются из отсортированного списка (т.к.
их применять нет необходимости)
б) применяются оставшиеся в упорядоченном списке журнальные записи

Кроме этого частью алгоритма является чтение и проверка последнего (нескольких последних?)
блоков, записанных DBWR на диск, читается сам блок и сверяется с SCN из журнальной записи DBWR:

When an instance is restarted following an instance crash, Oracle

carries out some checks against the last block that was written to disk
prior to the instance crash.

If Oracle finds an old block, then this suggests a lost write and the
error is raised.

НАПРИМЕР:

Last BWR afn: 601 rdba: 0x407886(blk 30854) ver: 0x0581.189e065e.00 flg: 0x0c
Disk version: 0x0581.17ceb245.00 flag: 0x0c

То есть, DBWR считает, что последний раз записал блок 0x407886 на диск с SCN 0x0581.189e065e.00,
а блок на диске имеет более старую версию. То есть налицо - потеря операции записи.
Скорей всего виновато в этом "железо" - ОС ответила, что блок записан, а он еще не записался.
В Oracle 11g появился новый параметр инициализации DB_LOST_WRITE_PROTECT, позволяющий
обнаруживать такие потери записи при обычной работе базы данных.

Параметр инициализации _two_pass=FALSE
отключает описанный механизм восстановления, т.е. журналые записи будут читаться и сразу применяться
к блокам данных. Разумеется, это незначительно снизит производительность процесса восстановления.
_two_pass=FALSE - предпочтительно для применения в таких случаях, т.к. избавляет от
этой ошибки практически гарантированно и избавляет от ручного вмешательства.

 

Новый комментарий

Я не спамер: введите суму 8+1



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Кейс: Льем на Gardenin c Instagram
22 февраля, 1 ответа
Житло
20 февраля, 1 ответа
покер
19 февраля, 2 ответа