[ОТВЕТИТЬ]
Опции темы
06.03.2007 15:08  
Владимир
Из всех параметров для нас являются важнейшими …

Параметров функционирования СУБД, указываемых в INIT-файле, как известно, в Oracle предостаточно. Их количество меняется от версии к версии. На версии 8.1.5 для NT, например, их 195:

SQL> select count(*) from v$parameter;
COUNT(*)
---------
195
Это те, которые (не всегда, к сожалению, ясно) документированы. Плюс к ним можно добавить еще 248 недокументированых:

SQL> select count(*) from x$ksppi where substr(ksppinm,1,1)='_';
COUNT(*)
---------
248
На неподготовленного такое обилие регулировок работы системы может подействовать угнетающе, а ведь надо добавить, что не все эти параметры независимы, и что многие действуют противоречиво друг в отношении друга.

К счастью, знание всех 195 параметров (о недокументированных - особый разговор), хотя и делает честь администратору (если только такой сыщется), но вовсе не обязательно для типичных использований системы. Большинство параметров становятся полезными только в специальных, не так уж часто возникающих случаях, требующих знания действительно тонкостей работы Oracle.

В "обычной" же "жизни", кроме того, не все параметры равнозначны. Какие-то вы можете править, и даже не замечать отдачи, а долгий процесс постижения правил выставления других может привести к выигрышу в производительности, скажем, всего на 1%.

В то же время значения, выставляемые Oracle по умолчанию (а они, кстати, могут быть разными на разных платформах) вовсе не обязательно хороши даже в обычных, непритязательных к изыскам случаях эксплуатации. Ряд из них все равно приходится править.

Ниже приводятся некоторые INIT-параметры, из числа влияющих на настройку структур в оперативной памяти экземпляра Oracle, на которые следует обратить внимание в первую очередь, так как эффект от их адекватного для ваших условий выставления способен привести к росту производительности, существенно превышающему упоминавшийся 1%.

Вот эти параметры:

DB_BLOCK_BUFFERS

Задает максимальное число блоков с данными в SGA. Если с диска нужно прочитать больше буферов, чем задано в DB_BLOCK_BUFFERS, блоки из SGA сбрасываются в табличные пространства по принципу "первый пришел - первый ушел" (LRU). Такой порядок, однако, можно индивидуально отменить для небольших таблиц (способных целиком разместиться в SGA самим, и оставить место другим).

DB_BLOCK_SIZE

Размер блока данных. Один для всей базы, устанавливается во время создания БД и не меняется в дальнейшем. Если в базе преобладают таблицы с интенсивно изменяемыми данными ("транзакционные системы"), выгоден небольшой размер блока. Если преобладает просмотр одной или нескольких малоизменчивых таблиц ("склады данных"), выгоден большой размер. Это противоречие в характеристиках - еще один довод в пользу разнесения аналитических и операционных данных по разным "базам" в случае использования Oracle.

SHARED_POOL_SIZE

Размер переменной части общей области (shared pool) данных в байтах. Воспринимается Oracle'ом как рекомендация, и практически всегда корректируется, исходя из собственных ограничений (это можно проверить, переустановив SHARED_POOL_SIZE, и посмотрев результат). Переменная часть shared pool используется как пространство для удовлетворения динамически возникающих у системы потребностей в памяти ОЗУ. Если размер shared pool больше необходимого, то из-за роста списков свободной памяти и при большой динамике возникающие накладные расходы на управление могут привести к снижению производительности системы. Плюс к этому, чересчур большой размер SGA может вызывать процесс страничного обмена памяти ОЗУ с диском, тормозящий общую работу.

SHARED_POOL_RESERVED_SIZE

Область в shared pool, зарезервированная для динамически возникающих запросов больших непрерывных участков памяти в SGA при обработке SQL. По умолчанию выставляется в 5% от SHARED_POOL_SIZE (указывается в байтах), но в зависимости от условий эксплуатации это место может либо пропадать, либо оказаться в дефиците. "Двигая" параметр SHARED_POOL_RESERVED_SIZE в меньшую или большую сторону (больше 50% Oracle выставить не позволит), вы не измените общего размера shared pool, но можете улучшить, или ухудшить эффективность использования этой области.

LARGE_POOL_SIZE

Если вы работаете в NT и не используете сервер "общего пользования" (shared), параллельный сервер или работу с монитором транзакций, этот параметр по умолчанию будет выставлен в 0.

SORT_AREA_SIZE

Определяет размер памяти, выделяемый каждому пользовательскому процессу на сортировку (UGA; может быть в расположена в SGA или PGA; используется, например, при обработке DISTINCT или ORDER BY). Если памяти не хватает, будет использоваться дисковое пространство - хороший способ «подсадить» работу системы. Увеличение параметра сократит число "дисковых" сортировок; в то же время объемных сортировок диска все равно не избежать. По окончанию сортировки память полностью возвращается в "кучу" UGA, то есть неприятными с точки зрения расходования памяти являются только одновременно выполняемые несколькими процессами сортировки.

SORT_AREA_RETAINED_SIZE

Задает максимальный размер памяти, динамически запрашиваемой у UGA на завершающую фазу процедуры сортировки, выполняемой с привлечением дисковой памяти. По завершению процедуры сортировки эта память возвращается, однако в завершающей стадии сортировки она может расходоваться в течение некоторого времени процессом в дополнение к "основной" памяти, регулируемой параметром SORT_AREA_SIZE. (В это время общая оперативная память, расходуемая процессом на сортировку, может достичь SORT_AREA_SIZE + SORT_AREA_RETAINED_SIZE)

BUFFER_POOL_KEEP

Целью выставления этого параметра является заведение в буфере блоков данных специального подбуфера, для которого не действует обычный LRU-механизм замещения блоков. Если имеется один или более очень активно используемых объектов (таблиц), и суммарный их объем относительно невелик, то закрепление их в памяти может повысить скорость реакции системы.

BUFFER_POOL_RECYCLE

Целью выставления этого параметра является заведение еще одного специального подбуфера, опять-таки нарушающего стандартный порядок замещения блоков, но уже противоположным образом. Если имеется большой нечасто используемый объект (очень большая таблица), можно приписать ее к подбуферу RECYCLE, и тогда Oracle "отпустит" его блоки сразу же после использования (что может дать выигрыш производительности, так как следующее обращение к блоку произойдет нескоро).

DB_FILE_MULTIBLOCK_READ_COUNT

Позволяет указать число одновременно читаемых блоков при выполнении СУБД чтения с диска. Увеличение DB_FILE_MULTIBLOCK_READ_COUNT дает заметный эффект при сканировании больших таблиц.

Владимир Пржиялковский, преподаватель УКЦ Interface Ltd.
 
06.03.2007 15:18  
OlegON
Подчеркну актуальность этой статьи для Oracle 8i. Для 9i все немного по другому.
 
09.03.2007 09:34  
inna
Не мог бы кто-нибудь из гуру осветить отличия по параметрам, хотя бы основные... Пожалуйста. Если не трудно, то с учетом важности для СМ.
 
09.03.2007 10:08  
OlegON
А зачем? Дело неблагодарное, заниматься их переводом. Оптимайзер о них знает, а если сама захочешь, то просто исходи из того, что перед тобой.
 
 
Опции темы



Часовой пояс GMT +3, время: 15:29.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.