Улучшение производительности оракулов без индексации

Question

Что можно сделать, чтобы улучшить производительность запроса оракула без создания индексов?

Вот запрос, который я пытаюсь выполнить быстрее:

SELECT c.ClaimNumber, a.ItemDate, c.DTN, b.FilePath
FROM items a,
itempages b,
keygroupdata c
WHERE a.ItemType IN (112,115,189,241)
AND a.ItemNum = b.ItemNum
AND b.ItemNum = c.ItemNum
ORDER BY a.DateStored DESC

Ни один из этих столбцов не проиндексирован, и каждая из таблиц содержит миллионы записей. Излишне говорить, что выполнение запроса занимает более 3 с половиной минут. Это сторонняя база данных в производственной среде, и мне не разрешается создавать какие-либо индексы, поэтому в самом запросе необходимо будет повысить производительность.

Спасибо!

Answer 1

Если вы говорите, что индексов нет, значит ли это, что не определены первичные или внешние ключи? Очевидно, что анализ таблиц и сбор статистики важны, но если таких метаданных, как определение того, как таблицы должны объединяться, не существует, то Oracle вполне может выбрать плохой путь выполнения.

В этом случае использование подсказки, такой как / * + ORDERED * /, вполне может быть единственным вариантом, позволяющим оптимизатору надежно выбрать правильный путь выполнения. Может также стоить добавить внешние ключи и первичные ключи, но определите их как DISABLE и VALIDATE.

Полагаю, полезность этого комментария зависит от того, насколько далеко зашло отвращение к индексам. YMMV.

Answer 2

В зависимости от типа данных столбца ItemType может возникнуть более быстрое выполнение с использованием следующего, если это varchar, Oracle выполнит имплицитные преобразования.

SELECT c.ClaimNumber, a.ItemDate, c.DTN, b.FilePath
FROM items a,
itempages b,
keygroupdata c
WHERE ((a.ItemType IN ('112','115','189','241'))
AND (a.ItemNum = b.ItemNum)
AND (b.ItemNum = c.ItemNum))
ORDER BY a.DateStored DESC

Answer 3

Иногда вы можете увидеть выгоду, добавив дополнительные пути для оптимизатора, чтобы выбрать, добавив что-то вроде избыточных элементов в предложение where.

Например, у вас есть A.ItemNum = B.ItemNum AND B.ItemNum = C.ItemNum. Попробуйте также добавить A.ItemNum = C.ItemNum. Однако я вполне уверен, что оптимизатор достаточно умен, чтобы понять это самостоятельно - хотя стоит попробовать.

Answer 4

Статистика собирается по этим таблицам? Если нет, сбор статистики может изменить план выполнения, хотя это не обязательно будет к лучшему.

Кроме этого, посмотрите на план выполнения. Вы можете видеть, что это соединение таблиц в неоптимальном порядке (например, это может быть соединение b и c перед объединением с a, который имеет условие фильтра).

Вы можете использовать подсказки, чтобы попытаться повлиять на пути доступа, порядок соединения или метод соединения.

Обновление : Ответ на комментарий привел меня к этой презентации, которая может быть полезной или хотя бы интересной.

Answer 5

Без индексации этот запрос будет только ухудшаться с увеличением размера таблицы. С учетом вышесказанного попробуйте удалить заказ по предложению и выполнить его на стороне клиента.

Answer 6

Удалить заказ на

выполните сортировку после того, как вы вернете строки обратно в приложение.