Добрый день.

Столкнулся с проблемой неоптимальных планов.

Вводные.
Версия oracle 12.1.0.2.0. Есть большая партиционированная табличка (tab1, key1 - ключ партиционирования, key2 - ключ субпартиционирования). Данные по партициям распределены неравномерно. Статистика собрана. Есть процедура на pl/sql, в которой довольно большой запрос, использующий данную табличку(соединения, аналитика и т.д., не суть). Входными параметрами передаются значения (in_p1, in_p2), по которым определяется требуемая при выборке субпартиция. Если совсем упрощенно, то SELECT * FROM tab1, tab2 WHERE key1=in_p1 AND key2=in_p2 AND tab1.id=tab2.id;

Проблема
При построении плана оценка количества строчек при выборке из таблицы в десятки раз расходится с реальностью для конкретных значений. Как итог, неоптимальный план. Если вместо переменных подставить реальные значения, то план корректный.

Кто-нибудь сталкивался с подобным? Какие есть варианты решения, кроме перехода на динамический sql и изменения плана хинтами?

P.S. Пробовал alter session set "_disable_cursor_sharing" = true; и alter session set "_optim_peek_user_binds"=false; Изменений в части оценки количества строчек не было.

orawishзапрос перепроверьте на соответствие типов атрибутов столбцам таблицы (особенно ключевых)
Все корректно.

--Eugene--если неравномерно, и большая часть запросов работает с известной частью партиций - хинтовать надо.
Ораклятина-то не знает с какой частью перекошенных данных вы собираетесь работать.
Вот мне кажется, что где-то в этом направлении и проблема. Такое чувство, что план берется для другого набора bind переменных. Можно ли как-то заставить оптимизатор проверять значения переменных перед построением плана? С хинтами не получится, так как число запусков для каждой партиции одинаково. Добавлю, что запусков в сутки относительно немного.

Вячеслав ЛюбомудровЕсли все так уж перекошено, то, может быть, есть смысл разделить операторы в зависимости от key1-key2 -- добавить, например комментарии. Т.е. сформировать несколько планов и дергать их не через NDS, а через IF-THEN-ELIF-...
Думал над этим. Но тогда придется поддерживать в актуальности несколько версий одного и того же кода. Это не очень удобно.

Вячеслав ЛюбомудровНу и вроде как Adaptive Cursor Sharing должен со 2-3 вызова это сам разрулить
Различных значений key1 немного, а вот key2 - это дата (каждый день новая). Возможно, это и влияет.

UP.

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