Ручное и автоматическое управление памятью Oracle. Выбор

Так какой же метод управления памятью базы данных Oracle следует применять: ручной или автоматический? Лично я предпочитаю по умолчанию использовать автоматическое управление памятью PGA. Внимание! Не вносите никаких изменений в производственную - реально действующую систему, не выполнив тестирование на предмет наличия побочных эффектов.

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

  • производительность системы останется полностью неизменной;
  • производительность повысится.
  • производительность значительно снизится.

Внимательно отнеситесь к этому предупреждению и тщательно все проверьте, прежде чем вносил» предложенное изменение.

Одной из наиболее трудных задач администратора базы данных может быть установка индивидуальных параметров, особенно таких, как SORT | HASH_AREA_SIZE и т.д. Мне многократно приходилось сталкиваться с системами, работающими с невероятно низкими значениями этих параметров — настолько низкими, что это приводило к очень серьезному снижению производительности системы. Возможно, это объясняется тем. что значения таких параметров, устанавливаемые по умолчанию, очень малы: 64 Кбайт для сортировки и 128 Кбайт для хеширования Существует множество противоречивых мнений по поводу их оптимальных значений. Кроме того, оптимальные значения могут изменяться в течение рабочего дня. В 8 часов утра при наличии двух пользователей размер области сортировки, равный 50 Мбайт, выделенный для одного зарегистрированного пользователя, может быть вполне допустимым. Ио в полдень, при наличии 500 пользователей, значение 50 Мбайт может оказаться совершенно неприемлемым. Именно в этой ситуации целесообразно применять параметры WORKAREA_SIZE_POLICY=AUTO и PGA_AGGREGATE_TARGET. Концептуально установка значения PGA_AGGREGATE_TARGET - объема памяти, который СУБД Oracle должна быть вправе использовать для выполнения операций сортировки и хеширования - проще, чем попытки подбора идеальных значений параметров SORT | HASH_AREA_SIZE. тем более что таких идеальных значений просто не существует. Оптимальные значения зависят от конкретной рабочей нагрузки.

По исторически сложившейся традиции администраторы баз данных конфигурировали объем памяти, используемый Oracle, устанавливая размер области SGA (кэш буферов; журнальный буфер: разделяемый и большой пулы, а также пул Java) Память, оставшаяся свободной, должна была использоваться выделенным и разделяемым серверами в области PGA Администратор базы данных обладал очень незначительными возможностями по управлению использованием объема этой

Памяти Он мог определить параметр SORT_AREA_SIZE, но в этом случае при одновременном выполнении операций сортировки СУБД Oracle могла бы использовать до 10 * SORT_AREA_SIZE байт ОЗУ. При параллельном выполнении 100 операций сортировки Oracle использовала бы 100 * SORT_AREA_SIZE байт, при 1000 операциях - 1OOO * SORT_AREA_SIZE И Т.Д.

Учитывая, что в PGA помещаются и другие объекты, администратор лишен реальной возможности управлять максимальным использованием памяти PGA системы.

Желательно, чтобы использование этой памяти регулировалось реальными потребностями. Чем больше пользователей, тем меньший объем ОЗУ каждый из них должен занимать, а чем их меньше, тем больший объем памяти должен быть доступен для применения каждым из них. Установка параметра WORKAREA_SIZE_POLICY = AUTO как раз и является способом достижения этой цели. Теперь администратор базы данных может указать единственный размер — PGA_AGGREGATE_TARGET. представляющий собой максимальный объем памяти PGA, который база данных должна стремиться использовать. СУБД Oracle будет распределять эту память между активными сеансами так. как сочтет нужным. Более того, Oracle Release 2 и последующие версии предоставляют консультативную справку по размеру PGA (часть пакета Stalspack и AWR, доступная через динамическое представление информации производительности V$ и отображаемая в окне enterprise Manager), подобную консультативной справке по настройке каша буферов. Со временем эта справка подскажет, какое значение PGA_AGGREGATE_TARGET оптимально для минимизации количества физических операций ввода-вывода во временных табличных пространствах данной системы Эту информацию можно применять либо для динамического интерактивного изменения размера PGA (при наличии достаточного объема ОЗУ), либо для принятия решения о том. нуждается ли сервер в дополнительном объеме ОЗУ для достижения оптимальной производительности.

Однако бывают ситуации, в которых использовать автоматическое управление памятью нежелательно. Этот метод был разработай для многопользовательской среды. В ситуациях, когда предполагается присоединение новых пользователей к системе, автоматическое управление памятью будет ограничивать объем выделенной памяти лишь определенной частью объема, заданного параметром PGA_AGGREGATE_TARGEТ. Но как быть, если требуется задействовать весь доступный объем памяти? Что же, в таком случае самое время воспользоваться командой ALTER SESSION для отключения автоматического управления памятью в конкретном сеансе (оставляя его активированным для всех остальных) и установки вручную нужных значений параметров SORT HASH_AREA_SIZE. Например, как поступить в случае масштабного процесса пакетной обработки, запускаемого в 2 часа ночи и выполняющего большие хеш-соединения, построения ряда индексов и т.п.? Этому процессу не нужно "скромничать" в плане использования памяти — ему требуется вся доступная память, поскольку в данный момент он является единственным, выполняющимся в базе данных. Совершенно очевидно. что это пакетное задание может выдавать команду ALTER SESSION и использовать все доступные ресурсы системы.

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

Вас заинтересует / Intresting for you:

Видеокурс по администрированию...
Видеокурс по администрированию... 3194 просмотров Илья Дергунов Mon, 14 May 2018, 05:08:47
Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 6195 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
Обновление до Oracle Database ...
Обновление до Oracle Database ... 3376 просмотров Илья Дергунов Tue, 21 Nov 2017, 13:18:05
Работа с запросами Approximate...
Работа с запросами Approximate... 606 просмотров Андрей Васенин Mon, 29 Oct 2018, 06:40:46
Aaltonen
Author: Aaltonen


AlexV аватар
AlexV ответил в теме #8764 18 окт 2017 14:07
Я всегда использую автоматическое управлению памятью Oracle. А Вы? Кто-то пользует ручное управление?