Неужели в AX 2009 можно отключить для Оракла функциональные индексы?

[egorych]

Собственно - в какой-то ветке обещался проверить возможность работы Ах3 без FBI .
Сейчас стоит железяка, которую можно временно потерзать. Чем собственно и зянялся ;-)
Состав - IBM x3650 M3 132Gb RAM 8*Xeon 2.5 + Win2003Server x64 Eng + Oracle 11.2.0.2 x64 + Axapta 3.0 KR2.
Согласно исследованиям gl00mie было выставлено:

Цитата:

-hint=49152

и в ktd

Цитата:

NLS_SORT = 'RUSSIAN_CI'

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

Цитата:

ALTER SESSION SET NLS_COMP = 'LINGUISTIC'

эта проблема решилась - т.е. поиск работает как положено ;-)
НО, дьявол как всегда в деталях!
Есс-но после установки новых параметров была проведена переиндексация - действительно, индексы создались нормальные - без NLS_LOWER и всяких там SUBSTRINGов !
Казалось-бы вот оно, щасте! Ан нифига - планы генерируются настолько странные, шо ни пером описать! Вроде и индекс используется, но почти везде фул скан его с каким-то странным выражением фильтра, включающим в себя преобразования NLS,,, ! Соответственно скорость ну совсем никакая.
В общем можно считать, что эта фича не была поддержана в ядре косяпты как положено и осталась как рудимент экспериментов разработчиков!
Мог, конечно, что-то упустить в установках - еще поизучаю маленько!

[Logger]

Цитата:

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

Вроде и индекс используется, но почти везде фул скан его с каким-то странным выражением фильтра, включающим в себя преобразования NLS,,, !

Странно, откуда им вылезти если у вас все отключено.

Кстати после переиндексации, не забудьте обновить статистику, причем для сессии которая обновляет статистику тоже должно быть включено

Цитата:

ALTER SESSION SET NLS_COMP = 'LINGUISTIC'
NLS_SORT = 'RUSSIAN_CI'

проверьте, может у вас оракловый джоб по сбору работает со старыми настройками и собирает статистику для
NLS_SORT = 'RUSSIAN_BI' или еще как.

Она вам бесполезна, поэтому наверно оптимизер и хватает фуллсканы.

[egorych]

Цитата:

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

Кстати после переиндексации, не забудьте обновить статистику, причем для сессии которая обновляет статистику тоже должно быть включено

Вообще-то начиная с 10 версии CREATE INDEX обновляет и статистику. Но в принципе возможно, что и нужно обновить - попробую

[Logger]

Цитата:

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

Вообще-то начиная с 10 версии CREATE INDEX обновляет и статистику. Но в принципе возможно, что и нужно обновить - попробую

Я не спец, но наш админ специально руками её обновляет.
Аксапта кстати, какой-то неоптимальный способ для сбора статистики для оракла использует. Погуглите тему.

[egorych]

Цитата:

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

Я не спец, но наш админ специально руками её обновляет.
Аксапта кстати, какой-то неоптимальный способ для сбора статистики для оракла использует. Погуглите тему.

Нормально она обновляет! По крайней мере я пользуюсь - проблем нет.
Я попробую позапускать, конечно, с разными параметрами.

[fed]

Цитата:

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

Я не спец, но наш админ специально руками её обновляет.
Аксапта кстати, какой-то неоптимальный способ для сбора статистики для оракла использует. Погуглите тему.

Там встроенный сборщик статистики (по крайней мере в версии 2.50-3.0) использовал какой-то пакет оракловский (для регулярного исполнения задач - типа cron'a), который на версии 8.0.5 работал, а на всех виденных мною версях 8.1.x и кажется даже 9.0.x наглухо разваливался. При этом он постоянно развалившееся задание рестартовал и тут же снова разваливался. В итоге - сервер был сильно нагружен.
Но судя по тому что egorych пишет, в каких-то более поздних версиях оракла это дело починили...

[gl00mie]

Цитата:

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

планы генерируются настолько странные, шо ни пером описать! Вроде и индекс используется, но почти везде фул скан его с каким-то странным выражением фильтра, включающим в себя преобразования NLS...! В общем можно считать, что эта фича не была поддержана в ядре косяпты как положено и осталась как рудимент экспериментов разработчиков!

От ядра Аксапты требуются только две вещи:

1. отсылать DML/DDL-запросы без SUBST/NLS_LOWER;
2. нормально подкручивать параметры сессии NLS_COMP/NLS_SORT.

Все остальное - уже на совести DBA. Я как бы... ни разу не DBA, но то, что у вас в планах запросов фигурируют странные выражения с преобразованием NLS, говорит скорее всего о том, что NLS-параметры сессии не совпадают с соотв. параметрами схемы и/или базы (в оракловом смысле) - по аналогии с отличием collation'а базы и экземпляра сервера в случае Ms SQL Server (в этом случае как минимум будут тормоза на работе с tempdb). Еще одна засада в случае с ораклом - это NLS-настройки при сборе статистики: если они не совпадают с настройками сессии, в которой выполняются DML-запросы, очевидно, оптимизатор не сможет использовать эту статистику для текстовых полей.
В общем, для чистоты эксперимента я бы переустановил оракл с теми NLS-настройками, которые вы пытаетесь использовать для работы с аксаптовской схемой.