Мы запускаем Oracle на 64-разрядной версии RHEL 5.4. Недавно мы обновили 10.2.0.1 до 10.2.0.4. Во время обновления было сгенерировано много ошибок (пример приведен ниже из trace.log), но после тестирования приложения все выглядело нормально (чистый EXP, вставки, обновления, удаления и т. Д.). Ошибки выглядят так, как будто все они связаны с таблицами и представлениями Advanced Queuing. Мы вообще не используем репликацию, это простой единственный экземпляр db.
ORA-24002: QUEUE_TABLE SYS.AQ_EVENT_TABLE does not exist
ORA-24032: object AQ$_AQ_SRVNTFN_TABLE_T exists, index could not be created
ORA-24032: object AQ$_ALERT_QT_S exists, index could not be created for queue
ORA-06512: at "SYS.DBMS_AQADM_SYSCALLS", line 117
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 5116
Стоит ли об этом беспокоиться, и если да, то как мне очистить / воссоздать поврежденные и / или отсутствующие объекты?
Я предлагаю не игнорировать это.
Недавно у меня были проблемы, связанные с AQ, после перехода с интерпретируемого PL / SQL на собственный скомпилированный PL / SQL. Мои таблицы AQ были изменены, и у нас были некоторые повреждения словаря данных. Мы явно не используем какие-либо функции AQ для наших продуктов, но похоже, что Oracle действительно использует их для некоторых из своих функций.
Основная проблема для нас заключается в том, что мы не могли использовать экспорт DataPump, поскольку они разбомбили связанные с AQ ошибками. Также доступ OEM к этой базе данных был очень нестабильным. Казалось, что все пользовательские операции работают нормально.
Если вы проверите свой журнал предупреждений, вы можете получить некоторые странные ORA-600 из-за недоступности подсистемы AQ.
Я предлагаю открыть SR с Oracle и идти оттуда. У них есть неопубликованная процедура, которую они могут вам предоставить, которая отбрасывает и воссоздает таблицы AQ. Если у вас нет никакого повреждения словаря данных, это должно быть что-то простое ... но убедитесь, что у вас есть возможность выдержать некоторое время простоя, поскольку их процедура не может быть запущена, пока пользователи находятся в системе. Также убедитесь, что у вас есть хорошие резервные копии - из-за всего этого нам пришлось откатиться на 1 неделю (к счастью, только база данных Dev).