Настройки Oracle

[Paul_ST]

Подскажите, пожалуйста, может ли настройка Oracle case sensitive негативно сказываться на быстродействии системы?
Очень настораживают появляющиеся в запросах к БД выражения вида "substr(nls_lower(...)".
Какие могут быть рекоменадции по настройке Oracle под Axapta?

[Wamr]

Главная настройка - взять грамотного DBA на работу, а уж он разберется с работой транзакционной системы на Оракле

[Paul_ST]

взять грамотного специалиста это очень хорошо.
Всё же хотелось бы узнать у тех , кто настраивал использовал свзязку Oracle + Axapta - наблюдается ли в запросах к Oracle "substr(nls_lower())"? Сказывается ли это каким-либо образом на быстродействии?

[Wamr]

Да, наблюдаются. Мало того, все индексы посторены по этим комбинациям.
NLS_LOWER сделано, чтобы запросы были нечувствительны к регистру. SUBSTR - осталось загадкой зачем нужен.
Как влияет на производительность, никто, наверно, не проверял.

Советую сразу снять галку First Row Fix в настройках Аксапты

[MironovI]

С производительностью вроде как все нормально. Побочный эффект от NLS_LOWER - поля выбранные через GroupBy будут в нижнем регистре - если их потом записывать в таблицы, или выводить в отчеты - не очень-то красиво.

[Paul_ST]

Special First Row Fix снята.
Может ли всё же переход на case insensitive улучшить ситуацию? Вроде как для MS sql Server под Axapt'у вообще не рекомедуется case insensitive? А для Orcale можно, но с потерей по производительности?

[Wamr]

1. У вас уже case insensitive - нечувствительны к регистру
2. Без поддержки со стороны ядра Аскапты вы ничего не добьетесь, кроме постоянных проблем.

У вас есть какие-то конкретные проблемы или спрашиваите чисто теоретически?

[Paul_ST]

тестируется конфигурация с загруженными данными. Долго (уже 3 часа) закрывается склад при том, что складских проводок от разнесённых журналов - порядка 200 штук. Правда проводок по неразнесённым журналов порядка 500 000. Может это влияет?

[Paul_ST]

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

[Wamr]

1. смотрите загрузку сети, дисков, процов (везде - сервер БД, АОС, клиент)
2. смотрите исполняемые запросы, планы

[Paul_ST]

посмотрели конечно же. Загрузка процессора аоса - минимальная (близкая к 0), БД - 10 - 25%, клиент - минимальная. Сеть незагружена.
План у выполняемого запроса - работает по индексам.
Однако есть подозрение, что именно substr(nls_lower()) не даёт полноценно сработать оракловскому оптимизатору

[itfs]

У oracle есть functionBasedIndex-ы, которые позволяют ему выкручиваться.

С уважение, itfs.

[Wamr]

Как я уже говорил, все индексы построены по тем же функциям. Если попытаться запустить запрос без них, то получите Table Scan, то есть оптимизатор работает нормально.

[db]

Очевидным недостатком аксапты 3.0 в связке с ораклом является невозможность использования покрывающих индексов, если в нем есть хоть одно текстовое поле. Индексы строятся по функциям, запрос на выборку полей идет без функций (не критерии, а именно список полей) - соответственно вместо того чтобы взять значение поля непосредственно из индекса приходится ораклу лазить в данные таблицы - лишие действия, лишние шевеления жесткими дисками и т.д. Однако стоит отметить, что применение покрывающих индексов в аксапте явление нечастое, так что все в итоге не так уж смертельно

[Logger]

Цитата:

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

Очевидным недостатком аксапты 3.0 в связке с ораклом является невозможность использования покрывающих индексов, если в нем есть хоть одно текстовое поле. Индексы строятся по функциям, запрос на выборку полей идет без функций (не критерии, а именно список полей) - соответственно вместо того чтобы взять значение поля непосредственно из индекса приходится ораклу лазить в данные таблицы - лишие действия, лишние шевеления жесткими дисками и т.д. Однако стоит отметить, что применение покрывающих индексов в аксапте явление нечастое, так что все в итоге не так уж смертельно

Можно попробовать это обойти используя Group By
В этом случае в самом Select -е в списке полей идут функции от полей, а не сами поля
Правда это не всегда возможно.
Может получиться еще более тяжелый запрос...

[db]

Цитата:

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

Можно попробовать это обойти используя Group By
В этом случае в самом Select -е в списке полей идут функции от полей, а не сами поля
Правда это не всегда возможно.
Может получиться еще более тяжелый запрос...

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

select ItemId from inventTrans group by ItemId;

На Oracle дейсвительно уходит функции от поля в списке выборки

SELECT SUBSTR(NLS_LOWER(A.ITEMID),1,20)
FROM INVENTTRANS A
GROUP BY SUBSTR(NLS_LOWER(A.ITEMID),1,20)
ORDER BY SUBSTR(NLS_LOWER(A.ITEMID),1,20)

На InventTrans достаточно индексов, содержащих SUBSTR(NLS_LOWER(A.ITEMID),1,20)

Но план запроса такой

OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION
------------------------------ ------------------------------ ------------------------------ ---------- ---------- ----------
SELECT STATEMENT 0 8379
SORT GROUP BY 1 0 1
TABLE ACCESS FULL INVENTTRANS 2 1 1
Если отрезать GROUP BY и ORDER BY то все приходит в норму

SELECT SUBSTR(NLS_LOWER(A.ITEMID),1,20)
FROM INVENTTRANS A

OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION
------------------------------ ------------------------------ ------------------------------ ---------- ---------- ----------
SELECT STATEMENT 0 420
INDEX FAST FULL SCAN I_177OPENITEMIDX 1 0 1

Если вместо GROUP BY сделать DISTINCT, то то же все по индексу

SELECT DISTINCT SUBSTR(NLS_LOWER(A.ITEMID),1,20)
FROM INVENTTRANS A

OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION
------------------------------ ------------------------------ ------------------------------ ---------- ---------- ----------
SELECT STATEMENT 0 3253
SORT UNIQUE 1 0 1
INDEX FAST FULL SCAN I_177OPENITEMIDX 2 1 1

В общем не получается получить и рыбку и удовольствие ...
Пробовал
ORA EE 9.2.0.6.0 64 bit Production под Linux
ORA EE 9.2.0.7.0 под Windows

Если у кого есть идеи как все таки заставить использовать данные из покрывающих функциональных индексов (кроме прямых SQL запросов) поделитесь пжл

Насчет отказа от функциональных индексов в принципе. Вроде как в 10R2 появился нормальный режим Case Insensitive (NLS_SORT=BINARY_CI, NLS_COMP=LINGUISTIC) Это бы позволило и от функциональных индексов избавится и с MONOCASE не заморачиваться.

10-ку ни разу не щупал и вообще спецом по ораклу себя не считаю.
Есть ли у кого опыт работы с Case Insensitive?

[Logger]

Цитата:

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

Не, обмануть не получается

Ну так я примерно это и имел в виду когда писал что "Может получиться еще более тяжелый запрос..."

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

[KiselevSA]

У меня отдаленые воспоминая из прочтения запросов под Oracle, что оптимизатор с Group By начинает нормально работать, если в выборке есть группировочная функция (count, min, max и т.п.)
Каков будет план, если запрос сделать таким:
select ItemId, max(ItemId) from inventTrans group by ItemId?

[db]

Цитата:

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

Ну так я примерно это и имел в виду когда писал что "Может получиться еще более тяжелый запрос..."

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

так я без претензий просто в одной задаче реально помогло бы сократить время обработки с часов до секунд

Цитата:

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

У меня отдаленые воспоминая из прочтения запросов под Oracle, что оптимизатор с Group By начинает нормально работать, если в выборке есть группировочная функция (count, min, max и т.п.)
Каков будет план, если запрос сделать таким:
select ItemId, max(ItemId) from inventTrans group by ItemId?

И так то же не выходит

В аксапте

select maxof(itemId) from inventtrans group by ItemId;

или

select ItemId, maxof(itemId) from inventtrans group by ItemId;

на оракл уже уходит max без функций

SELECT MAX(A.ITEMID),SUBSTR(NLS_LOWER(A.ITEMID),1,20)
FROM INVENTTRANS A
GROUP BY SUBSTR(NLS_LOWER(A.ITEMID),1,20)
ORDER BY SUBSTR(NLS_LOWER(A.ITEMID),1,20)

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

Заставить брать данные из индекса можно только приведя
запрос к следующему виду

SELECT MAX(SUBSTR(NLS_LOWER(A.ITEMID),1,20))
FROM INVENTTRANS A
GROUP BY SUBSTR(NLS_LOWER(A.ITEMID),1,20)

т.е чтобы макс брался от функций и не было сортировки
как такое выдать аксапты не используя прямые соединения у меня идей нет. а их использовать не хочется

[db]

Так юзал кто нито NLS_SORT=BINARY_CI, NLS_COMP=LINGUISTIC в 10-ке?
Похоже придется таки поставить очередного монстра для опытов