Настройка коллективного пула, как и других частей системы Oracle, требует

понимания взаимозависимостей всех компонентов, т. е. природы используемых
SQL. Относительные размеры пакетов, процедур и функций влияют на коллек-
тивный и другие пулы. Требуется, чтобы администратор базы данных проактив-
но управлял коллективным пулом и большим пулом, когда это применимо.
Знание того, какие опции использует система, определяет конфигурацию неко-
торых из пулов. Если как часть методологии резервного копирования использу-
ется        задействованы параллельные операции или MTS, для поддержки
этих средств должен быть конфигурирован большой пул. Если у вас установлена
Java, Oracle потребуется надежный пул Java.

Не давайте коэффициентам попадания в кэш становиться движущей силой

решений по настройке. Используйте события ожидания для того, чтобы напра­вить усилия по настройке на правильный путь. Если система испытывает высо­кое число перезагрузок библиотечного кэша, то это может привести к зависанию памяти. Рассмотрите вопрос об увеличении SHARED_POOL_SIZE.
Но прежде чем сделать это, обдумайте потенциальные выгоды от настройки
SQL, или отделения больших пакетов и процедур, или использование открытых
и сделанных постоянными курсоров. Помните, что мягкие синтаксические раз-
борки предпочтительнее жестких, а открытые курсоры        чем мягкие раз-
борки. Исследуйте вопрос об использовании SESSION_(JACHED_CURSOP^flH

применяемой версии базы данных Oracle.

Избегайте простого сбрасывания (flushing) коллективного пула для полной его очистки. Так можно обеспечить хорошую работу одного из пакетов, но это обернется высокими расходами при выполнении работ всех остальных пользо­вателей системы, запросы которых будут подвергнуты жесткой синтаксической разборке там, где можно было обойтись мягкой разборкой.

Если исследование причин плохой производительности приводит к рекур­сивному SQL, который постоянно пополняет кэш словаря данных, определенно нужно увеличивать размер коллективного пула. Однако будьте осторожны, сле­дите за тем, чтобы увеличение области SGA не привело к появлению где-либо в другом месте гораздо более сложных проблем.

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

dbms_sh.ami_poo 

и использования процедуры со­хранения. Многие АБД находят, что прикалывание основных системных паке­тов и пакетов приложений при запуске экземпляра оказывает помощь при управлении размером коллективного пула. Эти шаги часто добав­ляются в сценарии запуска.

Настройка буферного кэша базы данных

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

да/вывода. Не забудьте сравнить аналогичные моменты времени за различные календарные дни, имея в виду, что вся определенная для экземпляра статистика • является кумулятивной с момента последнего запуска системы.

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

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

Проактивно избегайте конкуренции защелок путем установки параметра DB_BLOCK_LRU_I.ATCHES равным его зависящему от платформы разрешен­ному максимуму. При этом не возникает заметных накладных расходов. Будьте внимательны при реализации любых неподдерживаемых параметров. Их пове­дение могло измениться с тех пор, как они перестали быть поддерживаемыми.

Не заблуждайтесь относительно коэффициентов попадания в кэш. Для них

просто не существует оптимальных или магических значений. Это верно даже в тех случаях, когда данное приложение поддерживает приложения в Web. Мы хо­рошо знакомы с требованиями субсекундного времени реакции для таких при­ложений. Однако само по себе это не должно побуждать нас хранить каждый

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

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

физического ввода/вывода является нормальным и приемлемым. Идеальный коэффициент попадания в кэш для одной среды может быть абсолютно бес­смысленным в другой.