Сбой обновления с ORA-20001 во время запуска обновления данных

16 июля 2019 г.

В этом случае вам следует подключиться к sys через sqlplus, правильно удалить и воссоздать задачи.

Тогда в файле alert.log не будет ошибок.

Я сталкивался с этой проблемой несколько раз в своей среде. И я искал MOS и пробовал разные вещи. Но я пока не мог решить эту проблему. Мое обновление с ORA-20001 завершается неудачно во время запуска обновления данных, и я хотел бы показать вам, как довести обновление до успешного завершения.

Все начинается с апгрейда

Что происходит?

Вы выполняете обновление до Oracle Database 12.2.0.1. И вы получаете ряд ошибок на этапе проверки компонента.

Ну, сегодня вечер пятницы – и я бы предпочел поспать или заняться чем-нибудь классным, что люди обычно делают в пятницу вечером. Но я пытаюсь проверить странную проблему с DBMS_OPTIM_BUNDLE и октябрьским обновлением 2018 года для Oracle 12.2.0.1. Я исправляю. Можете ли вы придумать что-нибудь лучше в пятницу вечером, чем установка патчей?

Моя тестовая установка

выполнить dbms_stats.gather_dictionary_stats

ORA-06502: PL/SQL: числовое или значение

Причина этой ошибки:

ORA-20001: Не удалось связаться с механизмом печати, поскольку указанный URL-адрес неверен или необходимо указать URL-адрес прокси-сервера.

Поэтому вам следует предоставить права подключения APEX_050000

после этого пробега:

Это взято из журналов автообновления.

И вот что вы увидите в журнале работника обновления:

Почему это происходит?

Поскольку ошибка 25293022 не является общедоступной, вы не можете ее прочитать. Субъекты ошибки говорят:

Насколько я знаю, была проблема с грантами на ПРОСТРАНСТВЕННЫЕ типы. В качестве исправления их пришлось отозвать и повторно предоставить. Но это может привести к тому, что таблицы приложения станут недействительными. Эта проблема возникает в рамках обновления. В результате проверка компонента завершается неудачно, и в APEX имеются недопустимые объекты.

Как это исправить?

, но упомянутый обходной путь сформулирован немного статично. Он рекомендует ПРЕДОСТАВИТЬ недостающие привилегии EXECUTE . Но в нашем вышеприведенном случае это не приведет к успеху. Недостающие GRANT необходимо предоставить APEX_180100 здесь:

разрешить выполнение на «MDSYS». «SDO_DIM_ARRAY» для APEX_180100;
разрешить выполнение на «MDSYS». «SDO_DIM_ELEMENT» для APEX_180100;
разрешить выполнение на «MDSYS». «SDO_ELEM_INFO_ARRAY» для APEX_180100;
разрешить выполнение на «MDSYS». «SDO_GEOMETRY» для APEX_180100;
разрешить выполнение на «MDSYS». «SDO_ORDINATE_ARRAY» для APEX_180100;
разрешить выполнение на «MDSYS». «SDO_POINT_TYPE» для APEX_180100;

Затем снова проверьте компонент:

включить вывод сервера
выполнить SYS. VALIDATE_APEX;

Дальнейшие ссылки

Применяется к

Oracle Database Exadata Express Cloud Service — версия N/A и более поздние Oracle Database Cloud Exadata Service — версия N/A и более поздние Oracle Database Cloud Service — версия N/A и более поздние Oracle Database — Enterprise Edition — версия 12.1.0.1 и более поздние Oracle Database — Standard Edition — Версия 12.1.0.1 и более поздние. Информация в этом документе применима к любой платформе.

Симптомы

ОШИБКА: ORA-20001: Последняя инвентаризация XML не загружена в таблицу ORA-06512: в «SYS. DBMS_QOPATCH», строка 1448ORA-06512: в «SYS. DBMS_QOPATCH», строка 122

VERIFY_QUERYABLE_INVENTORY——————————————— ———————————-ORA-20013: DBMS_QOPATCH работал в основном в неустановленной области

КУП-04118: операция «чтение трубы», локация «скудмир»

Запрашиваемый инвентарь не смог определить текущий статус обновления. Выполните «выберите dbms_sqlpatch.verify_queryable_inventory из двойного»

Из журнала оповещений:

ORA-1691: невозможно расширить сегмент SYS. SYS_LOB0000010985C00001$ на 128 в табличном пространстве SYSAUX

ORA-01691: невозможно расширить сегмент SYS. SYS_LOB0000022515C00008$ на 27309 в табличном пространстве SYSTEM

VERIFY_QUERYABLE_INVENTORY——————————————— ———————————-ORA-20001: Последняя инвентаризация XML не загружена в таблицу

Из журнала: qopatch_log.log

VERIFY_QUERYABLE_INVENTORY——————————————— ————————————————— ————————————————— ————————————————— ——ORA-20001: Последняя инвентаризация XML не загружена в таблицу

в файле qopatch_log.log

Ошибка: предварительная проверка не удалась! патч 30700212: существующий идентификатор пакета 200414 в описании исправления не соответствует максимальному идентификатору пакета 200714 в файле packagedata.xml. Проверка Prereq не удалась, выход без установки каких-либо исправлений.

Запрашиваемый инвентарь не смог определить текущий статус обновления. Выполните «select dbms_sqlpatch.verify_queryable_inventory from Dual» для полной ошибки. Предварительная проверка не удалась, завершение работы без установки каких-либо исправлений.

Обратитесь к примечанию MOS 1609718.1 для получения информации о том, как устранить вышеуказанные ошибки.

Инструмент исправления SQL завершен в четверг, 22 марта, 09:46:33 2017 г.

VERIFY_QUERYABLE_INVENTORY                                                      ——————————————— ———————————-ORA-31011: Ошибка анализа XML                                                   ORA-19202: Ошибка в XML обработка                                    LPX-00229: источник ввода пуст                                                 ORA-06512: в «SYS. XMLTYPE», строка 272                                            ORA-06512: в строке 1

VERIFY_QUERYABLE_INVENTORY——————————————— ———————————-ORA-31011: Ошибка синтаксического анализа XMLORA-19213: При обработке XML произошла ошибка в строках 1LPX-00241: ссылка на объект сформирована неправильно.ORA-06512: в «SYS. XMLTYPE», строка 272ORA-06512: в строке 1

.

ВНИМАНИЕ: JVM работает с жестким ulimit, не установленным на неограниченный

Ошибка LsInventorySession: невозможно создать patchObject

XML_INVENTORY                   CHAR (100000000)

Прекращено «UIJSVTBOEIZBEFFQBL»

Обрезать пробелы так же, как в загрузчике SQL

КУП-04017: Сообщение ОС: Ошибка 0

KUP-04017: Сообщение ОС: не удалось правильно установить локаль

выберите * из «SYS». «OPATCH_XML_INV»;

XML_INVENTORY                   CHAR (100000000)     Завершено «UIJSVTBOEIZBEFFQBL»     Обрезать пробелы так же, как в SQL LoaderKUP-04095: команда препроцессора $ORACLE_HOME/QOpatch/qopiprep.bat обнаружила ошибку «LsInventorySession error» : RawInventory получает нулевое значение OracleHomeInfo

.

verify_queryable_inventory вернул ORA-20001: Последняя инвентаризация XML не загружена в таблицу

Запрашиваемый инвентарь не смог определить текущий статус обновления. Выполните «select dbms_sqlpatch.verify_queryable_inventory from Dual» и/или проверьте журнал вызовов $ORACLE_BASE/cfgtoollogs/sqlpatch/sqlpatch_12145_2019_07_27_04_49_22/sqlpatch_infection.log на наличие полной ошибки. Предварительная проверка не удалась, завершение работы без установки каких-либо исправлений

KUP-04095: команда препроцессора $ORACLE_HOME/QOpatch/qopiprep.bat обнаружила ошибку «тайм-аут чтения канала» KUP-04017: сообщение ОС: нет такого файла или каталогаKUP-04017: сообщение ОС: тайм-аут чтения каналаKUP-04118: операция «Тайм-аут чтения канала», местоположение «skudmir:2»

XML_INVENTORY CHAR (100000000) Завершается «UIJSVTBOEIZBEFFQBL». Обрезать пробелы так же, как в SQL LoaderKUP-04095: команда препроцессора /u01/OracleDB/product/19.3.0.0/dbhome_1/QOpatch/qopiprep.bat обнаружила ошибку «Ошибка: эта Java экземпляр не поддерживает 64-битную JVM. Установите нужную версию».

ORA-29913: ошибка при выполнении вызова ODCIEXTTABLEFETCHORA-01157: невозможно идентифицировать/заблокировать файл данных 202 — см. файл трассировки DBWR

показывает журнал предупреждений

ORA-28374: набранный мастер-ключ не найден в бумажнике.

в журнале предупреждений показано:

QPI: Обнаружена ошибка при запросе opatch_xml_invQPI: в REFRESH_OPATCH_DATA, код ошибки -29913: ORA-29913: ошибка при выполнении вызова ODCIEXTTABLEFETCHORA-27102: недостаточно памяти Ошибка IBM AIX RISC System/6000: 12: Недостаточно

QPI: снятие блокировки УСПЕШНО, qp_result=0 в: 03-ЯНВАРЯ-23 28.01.47.263315000 AM -04:00

QPI: ОШИБКА снятия блокировки, qp_result=4 в: 03-ЯНВАРЯ-23 28.01.47.263495000 AM -04:00

QPI: в get_pending_activity, код ОШИБКИ -20001: ORA-20001: Последняя инвентаризация XML не загружена в таблицу

QPI: org_node и inst resore 2::

Изменения

My Oracle Support предоставляет клиентам доступ к более чем миллиону информационных статей и активному сообществу поддержки, состоящему из коллег и экспертов Oracle.

В своей лабораторной среде я часто обновляю две базы данных параллельно. База данных 11.2.0.4 и 12.2.0.1. Обновления 11.2.0.4 всегда безупречны. Но 12.2.0.1 иногда выходит из строя. Это экран, который показывает мне автообновление, но это не проблема автообновления. Это даже не «обновление», а проблема исправления.

Сначала мои исходные базы данных пропатчены до самых последних пакетов исправлений. На данный момент, когда я это пишу, речь идет о пакетах патчей за июль 2020 года.

Здесь я использую AutoUpgrade просто потому, что это проще. Почему я должен вместо этого печатать или нажимать на экраны DBUA. Тем более, что DBUA не сможет обновлять две базы данных параллельно.

Это мой файл конфигурации:

global.autoupg_log_dir=/home/oracle/upg_logs
#
#База данных номер 1
#
upg1.dbname=DB12
upg1.start_time=СЕЙЧАС
upg1.source_home=/u01/app/oracle/product/12.2.0.1
upg1.target_home=/u01/app/oracle/product/19
upg1.sid=DB12
upg1.log_dir=/home/oracle/upg_logs
upg1.upgrade_node=локальный хост
upg1.target_version=19
upg1.timezone_upg=нет
upg1.restoration=нет
#
#База данных №2
#
upg2.dbname=FTEX
upg2.start_time=СЕЙЧАС
upg2.source_home=/u01/app/oracle/product/11.2.0.4
upg2.target_home=/u01/app/oracle/product/19
upg2.sid=ФТЕКС
upg2.log_dir=/home/oracle/upg_logs
upg2.upgrade_node=локальный хост
upg2.target_version=19
upg2.timezone_upg=нет
upg2.restoration=нет

Обновление не удалось

И хотя база данных 11.2.0.4 обновляется хорошо, база данных 12.2.0.1 не работает.

Позвольте мне узнать, что произошло.

Autoupgrade_user. журнал

Это файл журнала обновления основного рабочего процесса.

Итак, само обновление завершилось успешно. Но у Datapatch возникла проблема на этапе после обновления.

ОРА-20001

И в этом, кажется, проблема:

Ошибка: предварительная проверка не удалась!
verify_queryable_inventory вернул ORA-20001: Последняя инвентаризация XML не загружена в таблицу

Самый известный ОРА-20001. В службе поддержки MyOracle вы найдете следующее примечание: Примечание MOS: 1602089.1 — Запрашиваемый реестр исправлений — Проблемы/решения для ORA-20001: Последняя инвентаризация XML не загружается в таблицу. Но мне нужно больше информации, чтобы понять, что не так в моем случае.

И снова для заметок: я обновился до домашней версии 19.8.0, но я уже видел ту же проблему и с 19.7.0.

Sqlpatch_invocacy. журнал

Хорошо, давайте перейдем к следующему лог-файлу – . Может там есть более подробная информация?

Это бесполезно.

Но в том же каталоге есть. И это имеет следующую последовательность ошибок:

К сожалению, это также не продвинуло меня вперед, поскольку моя модель ошибки не описана в примечании MOS: 1602089.1.

Тревога. бревно?

Может быть, в alert.log есть дополнительная информация?

КОМПОНЕНТ СЕРВЕРА id=DP_UPG_BGN: отметка времени=2020-07-30 12:19:27
2020-07-30T12:19:47.883482+02:00

XDB инициализирован.
2020-07-30T12:19:49.188762+02:00
QPI: файл opatch присутствует, opatch
QPI: присутствует файл qopiprep.bat
2020-07-30T12:21:32.945903+02:00
КОМПОНЕНТ СЕРВЕРА id=DP_UPG_END: ​​timestamp=2020-07-30 12:21:32

По сути, я знаю, что инвентарь нельзя было запросить в конце обновления. Но моя база данных обновлена. Следовательно, восстанавливать его не нужно. Но как мне это решить?

Запросить метаданные инвентаризации или очистки

На этом этапе я хотел сохранить свое обновление. Поэтому я запросил инвентарь самостоятельно – и это занимает совсем немного времени, как вы можете видеть здесь:

Это также может быть решением для очистки метаданных с помощью:

Завершить улучшение

Автообновление все еще ждет меня – еще одна причина, по которой я не использую DBUA, который обычно не возобновляется. Сейчас я возобновлю свое обновление:

Результат выглядит многообещающе:

И да, обновление моей базы данных завершено.

Альтернативный обходной путь

изменить системный набор «_xt_preproc_timeout» = 180, область = оба;

В данном случае я установил значение 180 секунд.

В предыдущей версии этого поста я рекомендовал установить вместо . Используйте, поскольку в противном случае обновление до Oracle Database 21c и 23c завершится неудачей из-за этого параметра в вашем sp-файле.

Краткое содержание

Основной причиной этой проблемы могли быть неправильные метаданные предыдущего запуска патча. Позвольте мне еще раз подчеркнуть, что это не ошибка обновления или автоматического обновления. Это происходит при вызове datapatch.

Я очень рад, что автоматическое обновление (и обновление из командной строки с помощью «» можно возобновлять). Иначе у меня не было бы возможности так легко это исправить. Если вы все еще используете DBUA, вы все равно можете перейти с помощью « » и завершить обновление после очистки метаданных.

Почему я пишу такой пост в блоге? На самом деле, когда я столкнусь с такой проблемой с моим ограниченным количеством обновлений, вы тоже можете столкнуться с ней в другой день. И решение простое. Но поскольку мне не удалось найти ключ в MOS, я хотел бы показать вам, как легко можно возобновить потенциально неудачное обновление базы данных, даже если само обновление завершено полностью.