Почитай пожалуйста указанную мной ссылку на одну из нитей обсуждения этой ситуации -- фраза "[
но в целом , "without an order_by_clause, no guarantee exists that the same query executed more than once will retrieve rows in the same order".] Я думаю этого достаточно, чтобы понять, что тех. поддержка тебя вышлет, если ты будешь им рассказывать о своей жизненной позиции по поводу использования индекса." -- это один из примеров когда запрос может возвращать вовсе не то что ожидается (там другой план выполнения, но по рукам будут бить не потому что у Oracle план поменялся, а потому что приложение что-то посчитало неправильно). Вообщем и целом такой подход менее foolproof, чем подход с явным использованием ORDER BY или другой функциональности, где бы всё было сделано с учётом изменений схемы, сообственно, об этом и говорилось. Также, опыт показывает что число проблем (bugs) связанных с использованием подсказки INDEX_DESC было несколько больше чем с использованием ORDER BY. И если вдруг такая проблема возникнет, то в тех местах где ты используешь INDEX_DESC тебе придётся менять функциональность или ждать исправлений. Вот тут и скажут тебе о заветном "workaround": USE ORDER BY! Поэтому здесь замечание "Тебя научит жизнь." справедливо. Несколько выше ты пытался доказать что появление проблемы подобного плана при использовании ORDER BY равновероятна появлению проблемы при использовании INDEX_DESC, должен отметить что это несколько не так. Их появление неравновероятно.
<OFFTOPIC>Да, и не нужно неумело вырывать фразы из контекста.</OFFTOPIC>
КваснойВопрос: будет ли считаться багом ситуация, когда хинт указывает метод доступа INDEX RANGE SCAN DESCENDING по существующему индексу, конструкция запроса позволяет использовать этот метод, а CBO, вопреки тому, что написано в документации, этот метод не использует?CBO обязан подчиниться подсказке, если нет синтаксических и семантических проблем с её применением. Основная проблема -- понимание семантики выполнения.
КваснойВ данном случае мы будем предполагать, что индекс с заданным названием существует.В каком "данном"? Если ты говоришь только о том примере, который ты привёл в своём самом первом сообщении, то да, индекс будет использоваться. Здесь нет никаких противоречий и возражений. Более того как говорил Станислав, здесь перефразировано, "как же так? примерчик-то был" :-)
Квасной
2. Если используется метод доступа INDEX RANGE SCAN DESCENDING , то значения возвращаются отсортированными по убыванию величины индексированных полей.
Грубо: при INDEX RANGE SCAN DESCENDING значения будут "появлятся" в rowsource, по мере чтения блоков индекса. Поскольку они хранятся отсортированными, то да, они будут попадать в rowsource отсортированными. Как они будут возвращаться из запроса, зависит от того что происходит дальше, используется ли, скажем, PQO, joins и т.д.
Квасной
Вопрос: будет ли считаться багом ситуация, в которой Oracle при использовании данного метода доступа возвращает строки не в порядке убывания величины индексированных полей, а в каком-то ином порядке, не соответствующем тому, что написано в документации?Я уже писал об этом, если поведение Oracle RDBMS не соответствует тому о чём написано в документации -- нужно открывать TAR и разговаривать с тех. поддержкой.
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:9843506698920#9896083461138
Я не могу сказать что здесь я на 100% согласен с Томасом Кайтом (я оставляю 1%, именно потому что пару раз мне пришлось решать проблему, котороая вынуждала использовать такой подход. Дело было на 7.3 и 8.0.x да и то только потому что были какие-то старнные баги, разбираться было некогда), но за всеми теми красноречивыми высказываниями есть рациональное зерно... Даже твой код выше, в котором ты обругал абстрактного администратора БД абсолютно не foolproof -- ошибки ищи сам. :-)
Ради любопытства, я хотел бы увидеть raw tracefiles твоего запроса и того что ниже. Пожалуйста, если нужно, сделай соответсвующий корректировки для своей системы. Проверь три варианта:
1. Твой оригинальный запрос.
2. Тот что ниже.
3. Тот что ниже с подсказкой /*+ INDEX_DESC (r ux_rate_currency_date) */
и выложи сюда zipped raw trace files.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
DEFINE numb_mask = 'FM9999999999.99999'
DEFINE date_mask = 'YYYYMMDD'
DEFINE date_mast_l1 = 9
SELECT TO_NUMBER(
SUBSTR(
(
SELECT MAX(TO_CHAR(r.rdate, '&&date_mask') || TO_CHAR(r.rrate, '&&numb_mask', 'NLS_NUMERIC_CHARACTERS=".,"')) l
FROM rates r
WHERE r.rdate <= x.xdate
AND r.rcurrency = x.xcurrency
GROUP BY
r.rcurrency
)
, &&date_mast_l1
)
, '&&numb_mask'
, 'NLS_NUMERIC_CHARACTERS=".,"'
) rate
FROM transactions x
/
