Документация Oracle на русском языке





Сайт посвящен разработке информационных систем с использованием технологий Oracle. На сайте можно найти полезную литературу и документацию на русском языке по программированию и администрированию Oracle.Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации.

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Параметры инициализации, настраивающие поведение оптимизатора


Перечисленные ниже параметры 

ни в коем случае 

не следует модифицировать по сравнению с их значениями по умолчанию до тех пор, пока не будут исчерпа­ны все документированные        настройки производительности, описан-
ные в предыдущих главах книги.
Предупреждение
Мы с успехом применили все обсуждаемые в этом разделе параметры во многих промышленных системах и достигли намеченных результатов. Однако на АБД лежит вся ответственность за их проверку в условиях собственной среды перед их внедрением.
Эти параметры являются наиболее существенными для пакетированных приложений от третьих фирм с недоступными исходными текстами. Они обыч­но релевантны и для сред, которым для пакетной обработки необходимы хеши-рованные соединения, но в то же время требуются и механизмы контроля для сдерживания оптимизатора от слишком сильного увлечения методом хеширо-ванного соединения при обработке транзакций. И, кстати, хешированные сое­динения не так уж плохи, как думают о них многие.
Большинство таких параметров вошли в силу, начиная с Oracle 8.0.5, но неко­торые из них могут быть подвергнуты обратному портированию на более ран­ние версии. Мы выражаем благодарность Пробалу Шому из Oracle Corporation за то, что он на конференции Oracle Open World 1999 г. поделился с нами своим опытом проникновения в глубины Oracle, познакомил нас со своей статьей '(Probal Shome. "Using Stored Outlines in Oracle8i for Plan Stability") и за последо­вавшие далее длительные живые дискуссии. Подведем практический итог: этот раздел стоит времени и усилий, если вам приходится работать с пакетирован­ными приложениями от третьих фирм. Так что без излишних рассуждений впе­ред, сами проверьте это.
OPTIMIZ£R_MAX_PERMUTATIONS
параметр ограничивает число перестановок таблиц, рассматривае­мых оптимизатором в запросах с соединениями, гарантируя, что время синтак­сического разбора для запроса не выйдет из разумных пределов. Однако существует небольшой риск, что оптимизатор проглядит хороший план, кото­рый в другом случае (без ограничения числа перестановок) был бы им найден.
Параметр также позволяет ограничить количество работы, затрачиваемой оп­тимизатором на оптимизацию запросов с большими соединениями. Значение целой переменной означает число перестановок таблиц, разрешенное оптими­затору при больших соединениях.
Значение по умолчанию параметра        рав-
но 80000. Если установить его на меньшее значение (например,        это за-
ставит оптимизатор в принудительном порядке проверять для запросов, в которых используются соединения, в качестве ведущей таблицы соединения не
более восьми таблиц. Обычно это приводит к тому, что оптимизатор отбирает наименее дорогостоящие из 79000 генерируемых им планов выполнения. Ины­ми словами, данный параметр предоставляет больше возможностей при выбо­ре порядка соединения таблиц для данного запроса. Поведение оптимизатора по умолчанию (соответствует значению по умолчанию) заключается в построе­нии плана, а в нем в качестве ведущей обычно используется наименьшая из таб­лиц. Это поведение по умолчанию не всегда позволяет генерировать наиболее
подходящий план и добиться ожидаемой заказчиком производительности, осо­бенно в случае пакетированных приложений от третьих фирм.
Установка OPTIMIZER_MAX_PERMUTATIONS обычно приводит к но­минальному увеличению времени синтаксического разбора операторов SQL. Ноэто увеличение окупается экономией времени, полученной в результате зна­чительного сокращения времени выполнения операторов SQL.
OPTIMIZER_INDEX_COST_ADJ
Параметр напрямую корректирует стоимость использования индекса. Зна­чение по умолчанию, равное 100, заставляет оптимизатор оценивать стоимость индекса как нормальную, а значение, равное 50, означает, что оптимизатор оценит стоимость в размере половины нормальной.
способствует использованию всех индексов независимо от их избирательности. Он вообще побуждает к использованию индексов. Диапазон значений для этого
параметра составляет от 1 до 10000. При установке малых значений (скажем,
от 1 до 10) оптимизатор способствует выполнению сканирования индекса, а не полному сканированию таблицы.
OPTIMIZER.SEARCHJJMIT
Значение по умолчанию для этого параметра равно 5. Если присвоить ему значение оптимизатор полностью откажется от применения в качестве мето­да выполнения декартова произведения. Когда используется значение по умол­чанию (5), оптимизатор имеет возможность и обычно пользуется ею для вычисления 

декартова произведения 

(если возможно) для запросов, имеющих пять или больше таблиц во фразе FROM. Такое поведение с выполнением декар­товых произведений может быть вполне приемлемым для малых таблиц, но по очевидным причинам они абсолютно ни под каким предлогом не пригодны для больших таблиц. В зависимости от природы приложения этот параметр требует коррекции. Если вы видите планы выполнения с декартовым произведением, то, может быть, захотите установить этот параметр равным
а
Замечание Декартово произведениедвухтаблиц по ЮОстрокв каждой сгенерирует результат, содержащий 10000 строк. Следовательно, если размер таблицы увеличивается, то пропорционально возрастает и стоимость выполнения декартова произведения. Не забывайте об этом!

OPTIMIZER_INDEX_CACHING
Параметр имеет значение по умолчанию, равное 0. Диапазон составляет от О до 100. Если установить высокое значение (например, 99) оптимизатор будет способствовать применению метода соединения с использованием вложенных циклов, предпочитая его другим способам. OPTIMIZER_INDEX_C'ACHING осо­бенно полезен, если параметр инициализации HASH_JOIN_ENABLED установ­лен на TRUE,  a HASH MULTIBLOCKIO COUNT имеет любое другое
кроме значения по умолчанию (например, READ_COUNT). Задание этого параметра, равным, скажем, 99, обеспечивает возможность и держать пирожок, и есть его. Это связано с тем, что значение по умолчанию оказывает беспрецедентное влияние на оптимизатор, заставляя его предпочитать хешированные соединения всем другим (если HASHJOINJENABLED установлен на TRUE).
Хешированные соединения подходят для приложений, в которых малая(ые) таблица(ы) соединяются с очень болыпой(ими) таблицей(ами), и где предика­ты фразы 

where 

вызывают обработку подавляющей части большой(их) таб­лицы). Хешированные соединения также подходят для приложений, где соединяются две или более большие таблицы. Оба сценария относятся к облас­ти пакетной обработки, в которой приложения обычно работают со значитель­ными количествами данных. Конфигурирование этого параметра на значение 99 не обязательно отключает хешированные соединения, но удерживает опти­мизатор от того, чтобы выбирать хешированные соединения методом соедине­ния по умолчанию.

Замечание
После установки значений этого параметра проявите

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


с днем рождения поздравления брату
jAntivirus