Связь между CURSOR_SHARING, Bind Variable Peeking и гистограммами

Я пытаюсь удостовериться, что у меня есть хорошее понимание отношения между CURSOR_SHARING, связующими переменными, привязкой переменной peeking и гистограммами, поскольку большинство источников охватывают эти темы, это разные разделы.

Хорошо, так вот, что я собрал до сих пор, не стесняйся слишком правильно, если у меня что-то не так:

CURSOR_SHARING

1. = EXACT (по умолчанию)

1.1. если оператор SQL использует литералы: оптимизатор будет генерировать новый план выполнения для каждой комбинации литералов - оптимизатор не заменит литералы связями. Для каждого литерала создается новый родительский курсор. 1.2. если оператор SQL использует переменные связывания: при первом запуске состояния оптимизатор будет заглядывать в значение переменных привязки и использовать эти конкретные значения для создания плана выполнения - все будущие операторы с этими переменными связывания будут использовать тот же план (даже если план субоптимален для других значений переменной привязки).

2. = FORCE

2,1. оптимизатор заменит все литералы связями - и в основном будет использовать тот же алгоритм, что и сценарий 1.2

3. = SIMILAR

3.1. нет гистограммы: оптимизатор заменяет все литералы связями → тот же конечный эффект, что и у 1.2 и 2.1 3,2. с гистограммой: optmizer заменяет все литералы связями, но заглядывает в переменную привязки КАЖДЫЙ раз, когда выполняется оператор (в отличие от только первого прогона), чтобы увидеть, существует ли более оптимальный план выполнения для этого конкретного значения привязки переменная (на основе статистики гистограммы). Поэтому новый дочерний курсор эффективно создается для каждого отдельного значения переменной связывания, с которой сталкивается оптимизатор.

Вопросы:

С моей точки зрения, не использует CUSOR_SHARING = EXACT + запись SQL-записей с привязкой-переменными (1.2) приводит к такому же результату, что и установка CURSOR_SHARING = FORCE (2.1)? В обоих случаях оптимизатор будет только заглядывать в переменную привязки при первом запуске, чтобы сформировать план выполнения, а затем повторно использовать этот план независимо от того, какие значения переменных привязки при последующих запусках? Если да, то почему большинство источников рекомендуют использовать переменные связывания? похоже, что это может существенно повлиять на производительность.
Является ли гистограмма используемой в первоначальной переменной переменной привязки для 1.2 и 2.1? Как и в первом случае, когда SQL-статут запущен и оптимизатор заглядывает в переменную связывания, использует ли она гистограмму (если она есть), чтобы определить, используется ли сканирование полной таблицы или сканирование по индексу? "Oracle Database 11g, Performance Tuning Recipes", по-видимому, указывает на то, что гистограммы имеют значение только тогда, когда CURSOR_SHARING = SIMILAR, но некоторые другие источники указывают, что гистограмма используется также во всех других настройках CURSOR_SHARING.
В случае 1.1, будет ли оптимизатор использовать гистограмму для определения наилучшего плана выполнения? В основном я просто хочу знать, когда используется гистограмма. Это только в том случае, если CURSOR_SHARING = SIMILAR или для других настроек CURSOR_SHARING?
Совместное использование курсора - эта функция будет выполняться только в том случае, если есть переменные связывания (либо из пользовательского запроса, либо из системного (с помощью буквальной замены)). Поэтому это происходит только в 1.2, 2.1, 3.1 и 3.2? но поскольку SIMILAR устарел, означает ли это, что ACS происходит только в 1,2 и 2,1?

Надеюсь, я не слишком далек от базы, но если бы я допустил какие-либо ошибки, пожалуйста, исправьте меня.

Спасибо!

Отредактировано: BYS2 - 20 дек 2011 12:11 PM

Ответ 1

Разница между (a) использованием FORCE и (b) с использованием EXACT и кодирующей переменной привязки заключается в том, что в последнем случае вы контролируете, когда используются переменные привязки. Поэтому, если вы видите, что в конкретном случае привязка переменных приводит к повреждению производительности или не нужна, вы можете изменить этот запрос. С FORCE вы застряли. Причина, по которой привязывать переменные рекомендуется для запросов типа OLTP, заключается в том, что синтаксический анализ представляет собой очень сериализованный процесс, который может стать большим узким местом. В OLTP-системах вы, как правило, просматриваете множество запросов, которые всегда должны использовать один и тот же план выполнения с разными значениями, поэтому повторное разбирательство их все время является ненужным. Любой хороший источник также рекомендует вам учитывать, когда не использовать переменные связывания - например, если у вас есть только несколько возможных значений, которые могут отображаться в определенной позиции в запросе, и одно или несколько из этих значений могут извлечь выгоду из другой план выполнения, лучше всего использовать литералы, так как вы можете разобрать каждый вариант один раз, а затем повторно использовать кешированный план.

(Еще одно преимущество использования переменных привязки заключается в том, что он оставляет вас менее открытым для SQL-инъекции.)

2 и 3. Гистограммы используются в общем случае при создании планов выполнения запросов и в большей степени, чем очевидны. Да, в случае стандартной проверки переменной привязки с настройкой EXACT гистограмма (или, по крайней мере, может быть) используется оптимизатором при определении плана выполнения. Это может быть хорошо или плохо, в зависимости от перекоса и того, какое значение у вас есть для привязки. Я думаю, что ваш источник делает около гистограмм, а параметр SIMILAR заключается в том, что в этом случае наличие гистограммы является одним из триггеров, которые приведут к созданию нового плана выполнения.

(Я бы очень рекомендовал Джонатана Льюиса "Основы Oracle на основе затрат" для всей информации, которую вы могли бы хотеть о том, когда и как используются гистограммы.)

4. Я считаю, что Adaptive Cursor Sharing - это, по сути, расширенная версия логики, которая ранее была реализована для CURSOR_SHARING = SIMILAR. Оптимизатор рассмотрит возможность создания новых планов на основе зависания переменных при любых обстоятельствах. Кажется, что SIMILAR по-прежнему существует как опция. Этот пост может предоставить дополнительную полезную информацию.