Встретился тут заказчик не совсем обычный и приятный, в смысле данных.
Таблицы большие, и, что еще хуже, очень много уникальных значений.
Например, 100 млн. таблица и в ней 3 млн. уникальных значений и похожая картина по всем
полям поиска.
Гистограммы тут не работают, ну никак не впихнуть 3 млн. в 254 значения сбалансированной по высоте гистограммы.
Данные, кстати, сильно перекошены.
Запросы все плавающие, т.е. может быть от 15 до 100 переменных в запросе, от 5-100 таблиц.
По сути, текст запроса формируется пользователем в интерфейсе.
Поэтому и технологии, вроде BACS и ее пособника cardinality feedback не работают, там ограничение в количестве binds.
Максимум что задействуется, так это bind sensitive.
По итогу и хинты толком не засунешь, никоим образом.
Почти всегда оптимизатор выбирает NL соединение и запросы начинают тормозить на процессоре,
выполняя кучу логических gets.
Если уловить отдельный запрос и прикрутить к нему хинт USE_HASH, то он начинает работать лучше.
Но как уже сказано, хинт применить сложно, тексты плавают.
Остается статистика.
Сбор ее нормальным образом (100%) также ничего не дает, удаление гистограмм также, поскольку тогда
получается железный NL, ибо оптимизатор считает данные равномерными и порции получаются небольшими,
100 млн./3 млн. = 33. Самое то для NL.
Остается статистику подгонять самому?
Но как? Опыта такого нет, да и тестировать негде, поднять у себя БД таких объемов не предвидится.
Да. Oracle 11.2.0.4, заплатки свежие, есть и SE (много) и парочка EE.


И еще, заканчиваю собственный перевод "Oracle Core Essential Internals for DBAs and Developers" от Jonathan Lewis.
Знаю, что перевод такой есть уже, даже нашел с Сети, но фрагмент.
Загорелся потому перевести сам, тренировка в языке неплохая, да и в технологии разберешься лучше.
Выложил бы окончательный перевод в pdf беЗплатно в Сеть, но нарушу авторские права, думаю?
А жаль, оппоненты бы не помешали. Ошибки в переводе, вестимо, есть.

Всем добра.

dbms_photoshop... Запросы все плавающие... текст запроса формируется пользователем в интерфейсе... тексты плавают...Зачем там бинды?


Вопрос интересный. Пользователей много, запросов много, каждый запрос раз по 2-5-10 раз да используется повторно.
Запросы и так из кэша быстро уходят, если сделать литералы, то будет еще хуже. Сплошной hard parse.
И - главное - не поможет.

dbms_photoshopСобери гистограммы по скошенным колонкам и используй литералы для них.

Гистограммы бесполезны. Слишком много уникальных значений. Миллионы.
Да, кстати, они и собраны.

dbms_photoshopЕсли хочется конкретных советов - лучше показать конкретный пример когда Оракл сильно ошибается.


Логично, но по причинам, от меня не зависящим, не могу.
Потому и вопрос выглядит не совсем комильфо.

Тут вот что интересно, в таком положении очень бы помог cardinality feedback.
Т.е. первый раз кривой план - выполнение по нему - сравнение оценки с действительностью, и изменение плана.

Но, как я уже сказал, cardinality feedback - это часть технологии BACS, а она не работает при количестве bind переменных
больше 8-14. А у нас свыше 15 для начала.
Если же перейти на литералы, то BASC там вообще не нужен, поэтому и cardinality feedback обратно не действует.

Замкнутый круг.

avduЕсли же перейти на литералы, то BASC там вообще не нужен, поэтому и cardinality feedback обратно не действует.


Хотя нет. У меня есть переводная статья по поводу cardinality feedback.
И там описано, что она, вроде бы, должна действовать и при литералах.

Однако, не действует. Может быть, потому, что опять же, слишком много переменных.

AlexFF__|avdu,

Ну сделай себе собственную таблицу гистограмм и по ней через union all строй планы.

Не, не прокатит, слишком много значений для гистограммы.
В 12 версии вроде бы количество групп в гистограмме увеличено до 1000.

Вот условие для начала применения cardinality feedback в Оракуловой доке на сайте поддержки:
Doc ID 1344937.1
During the plan optimization, certain types of estimates are noted and the cursor that is produced is monitored.
Во время оптимизации отмечаются определенные типы оценки, и курсор, ими порождаемый, ставится на наблюдение.

Эк, как красиво сказано, определенные типы, а вот какие именно?

AlexFF__|,

Понял, спасибо.