Оракловые чудеса

[Uzito]

Продакшен внезапно встал колом, пытаюсь понять что за чудеса. Есть репорт который высасывает данные из вьюшки средней сложности.

Это выполняется из SQL Dev за 10 секунд:

Код: Выделить всё

SELECT *
  FROM v_report_abc
 WHERE condition1 = 'QQQQ' AND condition2 = 'ABC'

Это умирает и не возращает никакого результата даже после 3 часов:

Код: Выделить всё

SELECT field1, field2, field3, field4, field5
  FROM v_report_abc
 WHERE condition1 = 'QQQQ' AND condition2 = 'ABC'

Это опять выполняется нормально:

Код: Выделить всё

SELECT field1, field2, field3, field4, field5
  FROM (SELECT *
          FROM v_report_abc
         WHERE condition1 = 'QQQQ' AND condition2 = 'ABC')

Чо за ботва?

[mskmel]

"Доктор, у меня это..."
Описанная Вами ситуация вполне воспроизводима при определённых условиях. То что выполняется нормально - найдено, вот это и выполняйте.

[zgur]

Планы запросов нужны чтоб понять точно. Когда в select выбираются только несколько полей oracle делает оптимизацию и, возможно, выбрасывает некоторые таблицы из joinа во view. Эта оптимизация, в вашем случае, приводит к худшим ресультатам

[iDesperado]

смотри планы запросов. просто разные планы

[Uzito]

смотри планы запросов. просто разные планы

План первого и второго запроса совершено одинаковый.

[Easbayguy]

Попробуйте добавить hint /*+ OPT_PARAM('_optimizer_adaptive_plans', 'false') */ иногда Oracle на лету меняет plan.

[iDesperado]

смотри планы запросов. просто разные планы

План первого и второго запроса совершено одинаковый.

не верю. делаю ставку что ты смотришь предполагаемый план, а не в процессе исполнения
поставь toad, посмотри план в session browser, там же long operations.

[мухобой]

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

[Uzito]

не верю. делаю ставку что ты смотришь предполагаемый план, а не в процессе исполнения
поставь toad, посмотри план в session browser, там же long operations.

AUTOTRACE издох на попытке показать реальный план. Прибил его через два часа.

[Uzito]

Попробуйте добавить hint /*+ OPT_PARAM('_optimizer_adaptive_plans', 'false') */ иногда Oracle на лету меняет plan.

Это не помогло, зато помогло добавить ORDERED hint.
Припаяли этот хинт к сиквелю через SQL Patch.

[iDesperado]

не верю. делаю ставку что ты смотришь предполагаемый план, а не в процессе исполнения
поставь toad, посмотри план в session browser, там же long operations.

AUTOTRACE издох на попытке показать реальный план. Прибил его через два часа.

set autotrace on из sqlplus ? он на сколько я помню после отработки запроса показывает. если есть доступ в вебную админку, там еще реальный план можно увидеть. еще вариант врубить трейс. перед тем как запустить глючный запрос
ALTER SESSION SET sql_trace = TRUE;
или более объемный вариант
ALTER SYSTEM SET EVENTS '10046 trace name context forever, level 8';

найти куда он задампил и трейс через tkprof отформатировать в человеческий вид. ALTER SESSION SET sql_trace = TRUE; мне кажется план показывал

[StrangerR]

Поставьте OEM (или даже db console) и походите по плану, вейтинг событиям, статистике, и быстро все найдете. А так как тут написано, только самые-самые ораклиные гуру могут разобраться.

[Mark]

проше всего запустить STA в OEM (или TOAD) на этот запрос и посмотреть STA report. если написано поменять план или построить индекс - сделать и прогнать еще раз.

[Ion Tichy]

Транзакции-изоляции?

[ALV00]

Чтобы не плодить топики
Еще одна загадка от Ларри:
Почему из пустого множества получается такой результат?

Код: Выделить всё

SQL> select c1, sum(c2)
  2  from (
  3     select 123 as c1, 10 as c2
  4     from dual
  5     where 1=2
  6  )
  7  /

        C1    SUM(C2)
---------- ----------
       123