Показать сообщение отдельно
Старый 18.08.2008, 16:02   #18  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от 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)?