Процесс SMON в бесконечном цикле в экземпляре базы данных Oracle... помогите!
Мы с моей командой нашли свой выход в Google (и Binged!), Пытаясь найти ответ на этот вопрос, поэтому, надеюсь, гуру Oracle по SF узнают ответ.
Неделю назад у нас было отключение электричества в здании, где размещался наш сервер. Весь сервер вышел из строя во время экспорта базы данных. Когда мы вернули сервер в рабочее состояние, мы заметили новый процесс, SMON, работающий как сумасшедший над экземпляром базы данных. Вот снимок экрана "Top Activity" в OEM.
http://www.myviewstate.net/images/oem.png
Мы отпустили это на некоторое время, но через день мы стали волноваться. После проверки журналов мы заметили, что он, похоже, находится в бесконечном цикле. Вот часть файла журнала:
Fri Aug 14 14:43:58 2009
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
Вот шаги, которые я предпринял до сих пор (большинство из которых я пробовал из-за того, что нашел в Интернете), но ни один из них не сработал.
- Перезапустите экземпляр базы данных.
- Переведите пользовательские табличные пространства в автономный режим, верните их в оперативный режим и перезапустите экземпляр db.
- Создано новое табличное пространство REDO, остановите экземпляр db, укажите spfile на новое табличное пространство, затем перезапустите экземпляр
Имейте в виду, что я разработчик и у меня очень мало опыта работы с Oracle, не говоря уже о том, чтобы быть администратором баз данных.
Какие-либо предложения?
5 ответов
Ваша база данных находится в цикле, так как она пытается выполнить восстановление и вернуть отмененные сегменты в оперативный режим для восстановления вашей базы данных. Поскольку вы не dba, я бы сразу же получил поддержку оракула и сказал бы им, что вам нужна серьезная помощь, и что вы не dba. Скорее всего, они заставят вас запустить базу данных и отключить менеджер восстановления, в котором есть цикл smon, пытающийся очистить отмененные сегменты. Когда в прошлом приходилось делать отмену очистки сегмента, лучше всего это сделать с помощью поддержки оракула. Большая часть шагов потребует некоторых событий и подчеркивания параметров, которые отключают / включают скрытый оракул моджо. Я бы не советовал делать что-либо, что вы найдете самостоятельно или опубликовано, не понимая смысла и, возможно, как восстановить / отменить ваши попытки. Цель состоит в том, чтобы восстановить вашу базу данных, а не сделать ее хуже. Получите поддержку оракула по телефону как можно скорее.
Oracle 9i и выше использует специальные табличные пространства UNDO и журналы REDO для управления своими транзакциями.
REDO хранит журнал выполненных операторов, а UNDO сохраняет до и после изображений блоков базы данных, на которые влияют эти операторы.
Сделал еще немного копания... Если у вас есть доступ к Oracle Metalink (их сайт поддержки), найдите идентификатор ошибки 3418428 Это, похоже, ваша проблема. Я не могу воспроизвести информацию здесь, так как считаю, что она нарушает соглашение о поддержке Oracle.
Общая суть проблемы заключается в том, что Automatic Undo Management динамически создает сегменты ROLLBACK в табличном пространстве UNDO по требованию. Количество и размер создаваемых сегментов варьируется в зависимости от нагрузки на базу данных.
До сбоя базы данных она создала и подключила к сети больше, чем число сегментов ROLLBACK по умолчанию.
После сбоя база данных не включила все сегменты ROLLBACK, которые были до сбоя.
Я думаю, что 10g сможет восстановиться после этого, если вы уделите этому достаточно времени; 9i было больше проблем. Открыта ли база данных для соединений и ответов?
Помимо этого вы можете оказаться в темном мире восстановления Oracle. Я бы посоветовал получить некоторую помощь, так как при попытках восстановления легко обойти Oracle.
Вы не упоминаете, что это за версия Oracle... есть проблема с Metalink для 10.2.0.4 с этим симптомом (821743.1). Ваша система выполняет распределенные транзакции? Может быть незафиксированная двухфазная транзакция фиксации, которая "зависла". Запрос представления dba_2pc_pending:
выберите local_tran_id, global_tran_id, состояние из dba_2pc_pending;
Если есть записи, которые не исчезают, вам нужно откатить силу на них. Будьте очень осторожны в этой области... Совет @Geoff хорош, вероятно, вам следует обратиться за поддержкой к Oracle, вот за что вы платите. Этот признак после сбоя может указывать на некоторое повреждение в базе данных. Это редко, но возможно. Предполагается, что Oracle является "доказательством коррупции", но лучшие планы и все такое....
Rollforward/open/rollbackward объясняется здесь
В целом, журналы повторов применяются, возвращая изменения в базу данных. В конце этого любое изменение, которое было применено, но не завершено с фиксацией, должно быть отменено. Он читает UNDO, чтобы отменить изменения.
Если он отменяет действие, это означает, что произошло незафиксированное изменение, которое необходимо откатить. Это не был бы экспорт (так как это должен быть чистый выбор). Посмотрите на USED_UREC в транзакции v$. Должна быть одна строка (возможно, больше) с ненулевым значением, которая (надеюсь) должна уменьшаться при применении записей отмены для удаления незафиксированного изменения.
Я не являюсь администратором Oracle или разработчиком, но быстрый гугл на "smon oracle" рассказал мне, каков процесс и что он делает после того, как у вашей БД появилась возможность увеличить нагрузку на процессор. Так будет продолжаться до тех пор, пока не будет устранен ущерб, вызванный вытягиванием энергии. Если вы сомневаетесь, откройте билет с Oracle - вы платите много за поддержку в конце концов.