ORA-03113 при выполнении SQL-запроса

Question

У меня 400-строчный SQL-запрос, выдающий исключение в течение 30 секунд

ORA-03113: конец файла в канале связи

Ниже следует отметить:

1. Я установил тайм-аут как 10 минут
2. Существует одно последнее условие, когда удалено устраняет эту ошибку.
3. Эта ошибка появилась только недавно, когда я проанализировал индексы.

Тревожное состояние таково:

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')

Таким образом, я предполагаю, что запрос завершается со стороны сервера, по-видимому, потому что он идентифицирован как боров ресурса.

Мое предположение уместно? Как мне решить проблему?

РЕДАКТИРОВАТЬ: Я пытался получить план объяснения ошибочного запроса, но запрос плана объяснения также дает мне ошибку ORA-03113. Я понимаю, что мой запрос не очень эффективен, но почему это должно быть причиной ошибки ORA-03113. Я пытаюсь выполнить запрос от жабы, и нет ни журнала предупреждений, ни трассировки, моя версия базы данных Oracle9i Enterprise Edition, выпуск 9.2.0.7.0 - Производство

Answer 1

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

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

Answer 2

У меня были похожие проблемы с разрывом соединения с некоторыми вариациями в запросе. В моем случае соединения теряются при использовании rownum при определенных обстоятельствах. Это оказалось ошибкой, которая имела обходной путь путем настройки определенного параметра конфигурации Oracle Database. Мы пошли на обходной путь, пока не установился патч. Я хотел бы вспомнить больше подробностей или найти старую электронную почту по этому вопросу, но я не знаю, что эти подробности помогут решить вашу проблему. Я публикую это просто, чтобы сказать, что вы, вероятно, столкнулись с ошибкой, и если у вас есть доступ к сайту поддержки Oracle (support.oracle.com), вы, вероятно, обнаружите, что другие сообщили об этом.

Edit: Я быстро взглянул на поддержку Oracle. Есть более 1000 ошибок, связанных с ORA-03113, но я нашел одну, которая может применяться:

Ошибка 5015257: QUERY_REW С ОС ORA-3113 И COREDUMP, КОГДА QUERY_REWRITE_ENABLED = 'TRUE'

Подведем итог:

• Идентифицирован в 9.2.0.6.0 и исправлен в 10.2.0.1
• Выполнение определенного запроса (не выявлено) причины ORA-03113
• Выполнение объяснения по запросу то же самое
• Файл ядра находится в $ ORACLE_HOME / dbs
• Обходной путь должен быть установлен QUERY_REWRITE_ENABLED для false: изменить системный набор query_rewrite_enabled = FALSE;

Другая возможность:

Ошибка 3659827: ORA-3113 ОТ ДЛИТЕЛЬНОГО ЗАПУСКА

• 9.2.0.5.0–10.2.0.0
• Проблема: у клиента есть длительный запрос, который последовательно выдает ошибки ORA-3113.
  В системе клиентов они получают файлы core.log, но не получают никаких ошибок в alert.log. В тестовой системе, которую я использовал, я получил ошибки ORA-7445.
• Обходной путь: установите "_complex_view_merging" = false на уровне сеанса или уровне экземпляра.

Answer 3

Вы можете безопасно удалить «UPPER» в обеих частях, если вы используете подобно с числами (не чувствительными к регистру), это может сократить время запроса, чтобы проверить подобное предложение

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')

равно:

AND someMultiJoin.someColumn LIKE '%90936%'

UPPER не влияет на числа (и% не зависит от регистра символов).

Answer 4

По имеющейся информации, это похоже на бэк-энд крах, как предложил Дэйв Коста некоторое время назад.Удалось ли вам проверить журналы сервера?

Можете ли вы получить план с set autotrace traceonly explain?Это происходит из SQL * Plus локально или только с удаленным подключением?Конечно, звучит так, как будто ORA-600 на заднем плане может быть виновником, особенно если это время разбора.Похоже, что успешный запуск занимает больше времени, чем неудачный, исключает проблемы с сетью.Я подозреваю, что он выходит из строя довольно быстро, но клиенту требуется до 30 секунд, чтобы отказаться от разорванного соединения, или сервер занимает столько времени, чтобы записать файлы трассировки и ядра.исправление (если вы можете найти соответствующее исправление для конкретного ORA-600 на Metalink) или обновление базы данных;или переписать запрос, чтобы избежать этого.Вы можете получить некоторые идеи о том, как это сделать, от Metalink, если это известная ошибка.Если вам повезет, это может быть просто подсказка, если дополнительное условие неожиданно влияет на план.Является ли someMultiJoin.someColumn частью индекса, который используется в успешной версии?Возможно, UPPER сбивает его с толку, и вы можете убедить его вернуться к успешному плану, намекая на то, что он все равно будет использовать индекс, но это, очевидно, довольно умозрительно.

Answer 5

Это часто ошибка в оптимизаторе на основе затрат со сложными запросами.

То, что вы можете попытаться сделать, это изменить план выполнения.Например, используйте WITH , чтобы вытащить некоторые подзапросы.Или используйте подсказку SELECT / * + RULE * /, чтобы Oracle не использовал CBO.Также помогает удаление статистики, поскольку Oracle затем использует другой план выполнения.

Если вы можете обновить базу данных, выполните тестовую установку 9.2.0.8 и посмотрите, не произошла ли ошибка.

Иногда это помогает создать дамп схемы, сбросить в ней все и снова импортировать дамп.

Answer 6

Как сказал @Daniel, сетевое соединение с сервером обрывается.Вы можете взглянуть на Конец файла на канале связи , чтобы узнать, предлагает ли он какие-либо полезные предложения.

Делитесь и наслаждайтесь.

Answer 7

Это означает, что вы были отключены.Скорее всего, это не связано с тем, что это проблема с ресурсом.

Я видел, где соединение с БД работает через NAT, и из-за отсутствия трафика оно закрывает туннель и таким образом разрывает соединение.Обычно, если вы используете пул соединений, вы не получите этого.