): Почему используется индекс (Oracle, DAX 2009)

[Akri]

Oracle, DAX 2009
С какого-то момента стала сильно задумываться рабочая аксапта на некоторых запросах – просто зависать минут на 5 – 20.

В качестве примера есть такой запрос, который запускается просто из джобика:

select firstonly RecId from SalesTable
where SalesTable.SalesId != "Заказ1" &&
SalesTable.CustAccount == "Клиент1" &&
SalesTable.RegionOrigSalesId == "123" ;

План запроса пишет такой:
SELECT /*+ INDEX(A I_366CUSTIDX) FIRST_ROWS */A.RECID
FROM SALESTABLE A
WHERE ((SUBSTR(NLS_LOWER(DATAAREAID),1,4)=NLS_LOWER(:IN1))
AND (((SUBSTR(NLS_LOWER(SALESID),1,20)<>NLS_LOWER(:IN2))
AND (SUBSTR(NLS_LOWER(CUSTACCOUNT),1,20)=NLS_LOWER(:IN3)))
AND (SUBSTR(NLS_LOWER(REGIONORIGSALESID),1,20)=NLS_LOWER(:IN4))))
Причем у нас есть тестовая конфигурация, на которой тот же самый запрос отрабатывает мгновенно (как и работало раньше на рабочей). На тесте план запроса такой:
SELECT /*+ FIRST_ROWS */A.RECID
FROM SALESTABLE A
WHERE ((SUBSTR(NLS_LOWER(DATAAREAID),1,4)=NLS_LOWER(:IN1))
AND (((SUBSTR(NLS_LOWER(SALESID),1,20)<>NLS_LOWER(:IN2))
AND (SUBSTR(NLS_LOWER(CUSTACCOUNT),1,20)=NLS_LOWER(:IN3)))
AND (SUBSTR(NLS_LOWER(REGIONORIGSALESID),1,20)=NLS_LOWER(:IN4))))
Много всего перерыли на эту тему. Сначала просто хочется понять в какую сторону копать – почему на рабочей базе используется индекс CustIdx (в него не входит REGIONORIGSALESID)?
Таблица SalesTable одинаковая на тесте и на рабочей (ну может быть только совсем немного отличаются данные).

[Logger]

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

Кстати, форма и джоб могут генерить разный запрос
Разница в хинтах

/*+ INDEX(A I_366CUSTIDX) FIRST_ROWS */
/*+ FIRST_ROWS */

Это влияет на то какой индекс выберет оптимизатор базы данных.

Поэтому нельзя непосредственно сравнивать запрос джоба и формы.

[Raven Melancholic]

Не могу сказать про Оракл, но в MS SQL использование индекса CustIdx вполне оправдано (ну, конечно, если он получается селективным):

• SalesId не может использоваться так как там неравенство.
• CustAccount есть в CustIdx.
• В общем случае, клиенты распределены в заказах достаточно равномерно.

В MS SQL различие можно было бы списать на статистику (возможно, что в одной из баз статистика устарела и движок некорректно определяет план запроса).
С точки зрения MS SQL смущает использование функции SUBSTR... В MS SQL такое бывает когда текстовые идентификаторы выровнены вправо (например, при переходе с Ax3.0 на следующую версию не была выполнена процедура реорганизации выравнивания). В MS SQL это приводит к очень серьезной деградации производительности, как в Оракле не знаю.

[Raven Melancholic]

Цитата:

Сообщение от Logger

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

Не, в Oracle один из вариантов представления плана как раз не дерево решения (как в MS SQL), а только указание на использование индекса (подчеркну, что это только один из вариантов представления плана).

[gl00mie]

Цитата:

Сообщение от Raven Melancholic

С точки зрения MS SQL смущает использование функции SUBSTR... В MS SQL это приводит к очень серьезной деградации производительности, как в Оракле не знаю.

В Оракле тоже, но это - by design и связано с тем, что до некоторых пор базы данных Oracle всегда были регистрозависимыми, а работать с регистронезависимым оракловыми collation'ами ядро AX 2009 специально отучили.

[Akri]

Провели эксперимент: сделали копию рабочего приложения и установили новый АОС (на другом компьютере), этим новым АОСом и копией приложения подключились к рабочей базе, запустили тот же джоб - работает мгновенно, план запроса как на тесте. Причина получается в АОСе рабочем или в компе, на котором АОС установлен - но в чем именно?

[Akri]

Обнаружилось, что на рабочих АОС-ах стояла галочка Allow INDEX hints in queries. Когда сняли эту галку, запрос из примера выше стал на рабочей конфигурации отрабатывать как на тесте – по тому же плану запроса (или как там это называется) и так же быстро.
Т.к. раньше на рабочей конфигурации все нормально работало без тормозов, то вопрос, поставил ли кто-то эту галку (что маловероятно) или какие-то другие условия привели к такому поведению индексов в совокупности с этой галкой, остался открытым – ну да ладно с ним!
Но на этом странности продолжились. Странности в непонятных тормозах в разных местах системы.
Например, стала тормозить разноска некоторых конкретных журналов – в журнале одна строка. Из дебагера стало понятно, что зависает на LedgerJournalTable.update(), когда система хочет проставить ledgerJournalTable.SystemBlocked = NoYes::Yes при разноске.
Т.е. такой джоб:
ttsbegin;
ledgerJournalTable = LedgerJournalTable::find("Журнал1", true);
ledgerJournalTable.SystemBlocked = NoYes::Yes;
ledgerJournalTable.update();
ttscommit;
всегда зависает на конкретном журнале «Журнал1», и всегда нормально отрабатывает на «Журнале2».

Куда копать? Что проверить-посмотреть-поэкспериментировать?

[gl00mie]

Поэкспериментировать с наймом Oracle DBA

[AlexeyS]

не знаю как в Oracle, но в MS SQL было пару раз, что появлялись непонятные тормоза на таблице и приходилось обновлять индекс, который "ломался", то есть при его использовании все разко замедлялось