|
Ну я бы не советовал отключать 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) механизм, который использовал обычные индексы по строковым полям, но при любой записи в поле, включенное в какой-нибудь индекс, конвертировал строку в нижний регистр.
|