Axapta 3.0 sp3+oracle 10.2.0.3 optimizer_index_cost_adj

[fed]

Ну я бы не советовал отключать Query Rewrite. Насколько я помню, этот параметр кроме включения поддержки materialized view, еще и включает использование Function Based Indexes для оптимизации запросов. То есть - если у нас есть индекс по NLS_LOWER(CustAccount) и стоит запрос вида select * from salesTable where NLS_LOWER(custAccount)=NLS_LOWER('Рога и копыта'), то с включенным Query Rewrite индекс будет использоваться, а с выключенным - не будет (пойдет fullscan). Насколько я понимаю, если Аксапта строит индекс по комбинации полей типа строка и число (скажем - ItemId+StatusIssue+StatusReceipt), то в результате строится индекс по хитрому строковому выражению, конкатенирующему NLS_LOWER(itemId) и какие-то результаты преобразования StatusIssue и StatusReceipt в строку. Я совсем не уверен (хотя и не проверял), что Оракл будет в состоянии построить разумную статистику по подобной сложной функции, а затем использовать ее в оптимизации запросов. Таким образом, используя функциональные индексы мы лишаемся довольно заметной части оракловского CBO, поскольку связать статистику по функциональному индексу, гистограммы значений полей и конкретные значения параметров запроса довольно не легко. И вполне возможно, что манипуляции с Index_cost_adjustment были придуманы не просто от нечего делать, а для того чтобы условиях фактически неработающего CBO Оракла, скорректировать работу оптимизатора таким образом, чтобы он более охотно использовал функциональные индексы.
Интересно было бы проверить, насколько часто и корректно будет использовать функциональные индексы оракл в вашем случае, после того как вы выключите корректировки index_cost_adj...

Кстати - есть сильное подозрение, что флажек 0x6a, о котором пишет gl00mie, как раз говорит Аксапте, что надо использовать Function Based Indexes, а не старый (оставшийся со времен версии 2.1) механизм, который использовал обычные индексы по строковым полям, но при любой записи в поле, включенное в какой-нибудь индекс, конвертировал строку в нижний регистр.

[gl00mie]

Цитата:

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

Насколько я понимаю, если Аксапта строит индекс по комбинации полей типа строка и число (скажем - ItemId+StatusIssue+StatusReceipt), то в результате строится индекс по хитрому строковому выражению, конкатенирующему NLS_LOWER(itemId) и какие-то результаты преобразования StatusIssue и StatusReceipt в строку.

По правде сказать, это как-то... неочевидно. Если посмотреть, как выглядит для Оракла, к примеру, \Data Dictionary\Tables\InventTrans\Indexes\StatusItemIdx, то получим следующий DDL-запрос (взято с рабочей базы):

PHP код:

CREATE INDEX "WORK"."I_177STATUSITEMIDX" 
    ON "WORK"."INVENTTRANS"  (SUBSTR(NLS_LOWER("DATAAREAID"),1,3),
    "STATUSRECEIPT", "STATUSISSUE", SUBSTR(NLS_LOWER("ITEMID"),1,20),
    "DATESTATUS") 
    TABLESPACE "WORKIDX" PCTFREE 10 INITRANS 2 MAXTRANS 255 
    STORAGE (INITIAL 64K NEXT 0K MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0) 
    NOLOGGING 


Цитата:

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

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

В общем, не подтверждаются пока эти подозрения. Кроме того, в «условиях фактически неработающего CBO Оракла» кому бы был нужен вообще этот Оракл?!

Цитата:

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

Кстати - есть сильное подозрение, что флажек 0x6a, о котором пишет gl00mie, как раз говорит Аксапте, что надо использовать Function Based Indexes, а не старый (оставшийся со времен версии 2.1) механизм, который использовал обычные индексы по строковым полям, но при любой записи в поле, включенное в какой-нибудь индекс, конвертировал строку в нижний регистр.

Возникает еще один интересный вопрос: а почему Аксапта при работе с Ораклом до сих пор продолжает использовать функциональные индексы? Разве Оракл не поддерживает уже давным давно case-insensitive collation(s)?