Взаимосвязь между CURSOR_SHARING, просмотром переменной Bind и гистограммами

Question

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

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

CURSOR_SHARING

1. = ТОЧНО (по умолчанию)

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

2. = СИЛА

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

3. = ПОХОЖИЕ

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

Вопросы:

1. Насколько я понимаю, использование CUSOR_SHARING = EXACT + запись SQL-операторов с переменными связывания (1.2) приводит к тому же результату, что и установка CURSOR_SHARING = FORCE (2.1)? В обоих случаях оптимизатор будет только смотреть на переменную связывания при первом запуске, чтобы сгенерировать план выполнения, а затем повторно использовать этот план, независимо от значений переменных связывания при последующих запусках? Если так, то почему большинство источников рекомендует использовать переменные связывания? похоже, что это может оказать существенное влияние на производительность.

2. Используется ли гистограмма в начальной переменной bind для 1.2 и 2.1? Например, в первый раз, когда выполняется проверка SQL и оптимизатор просматривает переменную bind, использует ли он гистограмму (если она есть), чтобы определить, используется ли сканирование полной таблицы или сканирование индекса? «Oracle Database 11g, рецепты настройки производительности», по-видимому, указывают на то, что гистограммы актуальны только тогда, когда CURSOR_SHARING = SIMILAR, но некоторые другие источники указывают, что гистограмма также используется во всех других настройках CURSOR_SHARING.

3. В случае 1.1 будет ли оптимизатор использовать гистограмму для определения наилучшего плана выполнения? В основном я просто хочу знать, когда используется гистограмма. Только когда CURSOR_SHARING = SIMILAR или для других настроек CURSOR_SHARING все в порядке?

4. Adpative Cursor Sharing - эта функция будет иметь место, только если есть переменные связывания (либо из пользовательского запроса, либо сгенерированные системой (путем замены букв)). Поэтому это имеет место только в 1.2, 2.1, 3.1 и 3.2? но поскольку SIMILAR устарела, значит ли это, что ACS встречается только в 1.2 и 2.1?

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

Спасибо!

Под редакцией: BYS2 20 декабря 2011 г. 12:11

Answer 1

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

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

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

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

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