Моя команда и я искали в Google (и Binged!) Наши кишки, пытаясь найти ответ на эту проблему, поэтому, надеюсь, гуру Oracle по SF будут знать ответ.
Неделю назад у нас отключилось электричество в здании, где размещен наш сервер. Весь сервер отключился в процессе экспорта базы данных. Когда мы вернули сервер в режим онлайн, мы заметили, что новый процесс SMON работает как сумасшедший с экземпляром базы данных. Вот снимок экрана с наиболее активными действиями в OEM.
Oracle Enterprise Manager 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
Вот шаги, которые я предпринял до сих пор (большинство из которых я пробовал из-за того, что нашел в Интернете), ни один из которых не сработал.
Имейте в виду, что я разработчик и у меня очень мало опыта работы с Oracle, не говоря уже о опыте работы в качестве администратора баз данных.
Какие-либо предложения?
Oracle 9i и выше использует специальные табличные пространства UNDO и журналы REDO для управления своими транзакциями.
REDO хранит журнал выполненных операторов, а UNDO сохраняет до и после изображений блоков базы данных, затронутых этими операторами.
Еще немного покопался ... Если у вас есть доступ к Oracle Metalink (их сайт поддержки), найдите ID ошибки 3418428 Это, похоже, ваша проблема. Я не могу воспроизвести здесь информацию, так как считаю, что это нарушает соглашение о поддержке Oracles.
Общая суть проблемы заключается в том, что автоматическое управление отменой динамически создает сегменты ROLLBACK в табличном пространстве UNDO по запросу. Количество и размер создаваемых сегментов зависит от нагрузки на базу данных.
Перед тем, как база данных аварийно завершила работу, она создала и подключила больше сегментов ROLLBACK, чем задано по умолчанию.
После сбоя база данных не подключила к сети все сегменты ROLLBACK, которые были до сбоя.
Я думаю, что 10g сможет оправиться от этого, если вы дадите ему достаточно времени; У 9i проблем было больше. Открыта ли база данных для подключений и ответов?
Кроме того, вы можете окунуться в темный мир восстановления Oracle. Я бы посоветовал получить некоторую помощь, поскольку при попытках восстановления легко полностью обмануть Oracle.
Ваша база данных зацикливается, пытаясь выполнить восстановление и вернуть сегменты отмены в оперативный режим, чтобы восстановить вашу базу данных. Поскольку вы не являетесь администратором баз данных, я бы сразу получил поддержку оракула на линии и сказал им, что вам нужна серьезная помощь и что вы не являетесь администратором баз данных. Скорее всего, они заставят вас запустить базу данных и отключить диспетчер восстановления, в котором цикл smon пытается очистить сегменты отмены. Если раньше приходилось отменить очистку сегмента, лучше всего это сделать с помощью службы поддержки Oracle. Для большинства шагов потребуются некоторые события и параметры подчеркивания, которые отключают / включают скрытый mojo 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 будет «доказывать коррупцию», но самые лучшие планы и все такое ....
Я не администратор или разработчик Oracle, но быстрый гугл по "smon oracle" рассказал мне, что это за процесс и что он делает после того, как ваша БД отключила питание для увеличения использования ЦП. Так будет продолжаться до тех пор, пока не будут устранены повреждения, вызванные потребляемой мощностью. Если сомневаетесь, откройте заявку в Oracle - вы все-таки много заплатите за поддержку.
Объяснение повтора / открытия / отката Вот
В общем, журналы повторов применяются для возврата изменений в базу данных. В конце концов, любое изменение, которое было применено, но не завершилось фиксацией, необходимо откатить. Он читает UNDO, чтобы отменить изменение.
Если происходит отмена, это означает, что произошло незафиксированное изменение, которое нужно отменить. Это не было бы экспортом (поскольку это должен быть чистый выбор). Посмотрите на USED_UREC в транзакции v $. Должна быть одна строка (может быть, больше) с ненулевым значением, которое (надеюсь) должно уменьшиться, поскольку записи отмены применяются для удаления незафиксированного изменения.