18.08.2008, 17:08
|
#21 |
|
Участник
|
Цитата:
Сообщение от fed
По поводу case-insensitive - мне казалось эта штука поддерживается в оракле начиная с версии 11 ? И мне казалось (хотя я и не уверен), что как раз DAX 2009 должна использовать case-insensitive collation в случае использования именно 11 версии оракла.
|
|
|
|
18.08.2008, 17:12
|
#22 |
|
Moderator
|
Цитата:
Сообщение от gl00mie
Я, по правде сказать, в Оракле не разбираюсь совсем, но в номере Oracle Magazine за июль 2004-го пишут, что регистронезависимый поиск и индексирование поддерживаются начиная с Oracle 10g. В системных требованиях к DAX 2009 тоже упоминается Oracle 10g, точнее, Oracle 10g R2 Standard/Enterprise. При этом в файлах дистрибутива DAX 2009 RTM найти подтверждение того, что используется NLS_SORT=BINARY_CI, с наскоку не удалось
|
|
|
|
18.08.2008, 17:37
|
#23 |
|
Участник
|
OPTIMIZER_INDEX_COST_ADJ всего лишь подсказывает CBO что выгодней использовать: FULL TABLE SCAN либо INDEX ACCESS, рассчитать этот параметр можно как отношение одноблочных чтений (обычно при чтении по индексу ) к многоблочным ( полная зачитка таблицы) выраженное в процентах. Естественно чем точнее собрана статистика тем более рациональное решение примет CBO, однако акспата не предоставляет столь точную статистику.При создании индексов и таблиц аксапта посылает COMPUTE STATISTICS на оракл,поэтому лучше собирать вручную с гистограммами используя granularity,estimate_percent,cascade и т.д), тогда ошибки CBO будут сведены к минимуму.
Query Rewrite преобразует SQL-предложение таким образом, что оно получает доступ к заранее подготовленным суммарным таблицам (материализованным представлениям), которые определены на детальных таблицах. Когда целью запроса является суммирование или агрегирование данных по одной или большему числу детальных таблиц (с возможным join-соединением) и существует доступное материализованное представление, которое содержит требуемые данные, то оптимизатор оракл может прозрачно (то есть, самостоятельно) переписать запрос так, чтобы получить из материализованного представления заранее вычисленные.Однако, материализованные представления не во всех ситуациях применимы для перезаписи запросов. Для этого необходимо явно QUERY_ REWRITE_ENABLED=TRUE, использовать опцию ENABLE QUERY REWRITE в SQL-командах CREATE MATERIALIZED а также гарантировать, что учетная запись (account), которой принадлежит материализованное представление, обладает системной привилегией QUERY REWRITE.На работу функциональных индексов эта опция не влияет. Последний раз редактировалось ring; 18.08.2008 в 17:55. |
|
|
|
18.08.2008, 19:19
|
#24 |
|
Moderator
|
Цитата:
Сообщение от ring
OНа работу функциональных индексов эта опция не влияет.
 Если погуглить по сочетанию FBI и Query Rewrite или Function Based Indexes и Query Rewrite - то найдется очень много рекомендаций выставлять и у схемы и у сессии Query Rewrite, если используются FBI.Так что query rewrite там не просто так поставили... |
|
|
|
19.08.2008, 10:03
|
#25 |
|
Участник
|
Цитата:
Сообщение от fed
Если верить вот этой ссылке http://asktom.oracle.com/pls/asktom/...D:667694821129 , то не влияет она только начиная с версии 9204
Если погуглить по сочетанию FBI и Query Rewrite или Function Based Indexes и Query Rewrite - то найдется очень много рекомендаций выставлять и у схемы и у сессии Query Rewrite, если используются FBI.Так что query rewrite там не просто так поставили... |
|
|
|
19.08.2008, 14:13
|
#26 |
|
Moderator
|
Цитата:
Сообщение от ring
Мы с вами говорим о версии 10.2.0.3, по крайне мере мой вопос был применительно с этой версии, возможно то о чём вы говорите было актуально в 8.1х (судя по ссылке) но с тех по прошло уже 10!! лет =)
Просто я когда-то давно когда первый раз 3ю Аксу на оракл первый раз ставил (году в 2003 кажется) поимел немало головной боли с тем что не настроил правильно query rewrite и функциональные индексы в запросах не использовались. Ну и чтобы подитожить дискуссию (собрали необходимый объем данных объединенными усилиями )1. query rewrite можно выключить при использовании любых версий Оракла начиная с 9.2.0.4 2. Коррекцию optimizer_index_cost_adj можно выключить в любом случае, но следует быть готовым к необходимости в ручную строить более сложные гистограммы именно для той комбинации полей, которая есть в индексе. Вот. По моему достаточно конструктивный вывод из дискусии
Последний раз редактировалось fed; 19.08.2008 в 15:24. |
|
|
|
| За это сообщение автора поблагодарили: mazzy (5), aidsua (1). | |
|
28.08.2008, 13:49
|
#27 |
|
MCITP
|
Цитата:
Сообщение от ring
К сожалению выставить желаемое значение optimizer_index_cost_adj под 3-tier так и не удалось ни с помощью редактирования ktd файлов ни даже с помощью LOGON триггера на оракле (странно но факт) , под 2-tier всё работает....
__________________
Zhirenkov Vitaly |
|
|
|
28.08.2008, 14:30
|
#28 |
|
Участник
|
Цитата:
Сообщение от ZVV
Ну тут нет ничего странного... ЛогонТриггер отрабатывает сразу после логина, и то что вы там делаете Аксапта сразу же после этого благополучно затирает.
|
|
|
|
28.08.2008, 16:35
|
#29 |
|
MCITP
|
Надо пробовать, я не уверен. Аксапта то (трёхзвенка) не работает с одним выделенным соединением. Т.е. дополнительные соединения которые открываются для номерных серий например, это точно не подхватят.
А вот насчёт "основных" соединений, я не уверен на 100%, но помойму АОС может создавать дополнительные сессии в пуле "на лету" для тех клиентских сеансов которые, например, долго не подавали признаков активности. И тогда тоже облом.
__________________
Zhirenkov Vitaly |
|
|
|
28.08.2008, 17:22
|
#30 |
|
Участник
|
Цитата:
Сообщение от ZVV
А вот насчёт "основных" соединений, я не уверен на 100%, но помойму АОС может создавать дополнительные сессии в пуле "на лету"
|
|
|
| Теги |
| oracle, производительность, ax2009, ax3.0 |
|
|
|
Линейный вид
