Связываемые переменные при работе с Oracle

[fed]

Цитата:

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

Недавно начал работать с Аксаптой, так что простите, если спрашиваю общеизвестные факты.

3) Кто-нибудь пробовал на рабочей базе Axapta включать опцию CURSOR_SHARING и к чему это приводило? Теоритические плюсы и минусы такого шага я понимаю - интересует именно специфика Аксапты.

Ну я пробовал. (Точнее - разбирался с последствием того что знакомые попробовали. ) Эффект - поразительный. Меня позвали разбираться почему Аксапта тормозит очень. Выяснилось - что Oracle почему-то не использует индексы по строковым полям. Как показало вскрытие - именно из за баловства с cursor_sharing. Ситуация следующая:
1. Из за того что Axapta везде использует case-insensitive сравнение, все индексы по строковым полям в Аксапте, при использовании Oracle, строятся как функциональные. То есть индекс строится не по полю custAccount, а по NLS_LOWER(Substr(custAccount,1,10)) (10 - длина поля)
2. При формировании запросов, литералы тоже заключаются в функцию NLS_LOWER. То есть - на сервер отправляется запрос вида select * from custTable where NLS_LOWER(Substr(custAccount,1,10)=NLS_LOWER(Substr('Рога и копыта'),1,10). Оптимизатору Оракла хватает ума сопоставить выражение в левой части равенства с выражением индекса
3. Если поставить CURSOR_SHARING=EXACT, Oracle транслирует полученный запрос в select * from custTable where NLS_LOWER(Substr(custAccount,:bind1,:bind2)=NLS_LOWER(Substr(:bind3,:bind4,:bind5), после чего подставляет конкретные значения bind-переменных. Нетрудно догадаться, что левая часть сравнения перестает сопоставляться с выражением индекса и индекс перестает использоваться для исполнения запроса.

Это все было справедливо для Oracle 10g Release 1. Может в более поздних версиях это дело как-то изменили.

Кстати - даже в отрыве от проблем с ораклом, я не вижу особого смысла в замене литералов на переменные запроса. На практике - узким местом в 95% случаев является не процессор, а жесткий диск. Использование переменных запроса слегка снижает нагрузку на процессор, но при этом значительно повышает вероятность генерации неправильного плана запроса. Кроме того - Аксапта не использует (ну хорошо - почти не использует ) хранимые процедуры, триггера, и вообще средства программирования сервера БД. Так что нагружать именно процессора сервера БД - там просто нечем. Так что, на мой взгляд, любые попытки массовой параметризации запросов приносят негативный результат именно в случае Аксапты.