Разделяемый пул

Разделяемый пул - один из наиболее важных фрагментов памяти в области SGA, особенно для обеспечения производительности и масштабируемости. Слишком маленький разделяемый пул может снизить производительность настолько, что система будет казаться зависшей. Слишком большой разделяемый пул может привести к такому же результату. Неправильное использование разделяемого пула грозит катастрофой.

Итак, что же такое разделяемый пул? В разделяемом пуле сервер Oracle кэширует различные программные данные. Здесь кэшируются результаты разбора запроса. Перед повторным разбором запроса сервер Oracle просматривает разделяемый пул в поисках готового результата. Выполняемый сеансом PL/SQL-код тоже кэшируется здесь, так что при следующем выполнении не придется снова читать его с диска. PL/SQL-код в разделяемом пуле не просто кэшируется, - появляется возможность его совместного использования сеансами. Если 1000 сеансов выполняют тот же код, загружается и совместно используется всеми сеансами лишь одна копия этого кода. Сервер Oracle хранит в разделяемом пуле параметры системы. Здесь же хранится кэш словаря данных, содержащий информацию об объектах базы данных. Короче, в разделяемом пуле хранится все, кроме продуктов питания.

Разделяемый пул состоит из множества маленьких (около 4 Кбайт) фрагментов памяти. Память в разделяемом пуле управляется по принципу давности использования (LRU). В этом отношении она похожа на буферный кэш: если фрагмент не используется, он теряется. Стандартный пакет DBMS SHARED POOL позволяет изменить это и принудительно закрепить объекты в разделяемом пуле. Это позволяет загрузить часто используемые процедуры и пакеты при запуске сервера и сделать так, чтобы они не выбрасывались из пула как устаревшие. Обычно, если в течение определенного периода времени фрагмент памяти в разделяемом пуле не использовался, он выбрасывается как устаревший. Даже PL/SQL-код, который может иметь весьма большой размер, управляется механизмом постраничного устаревания, так что при выполнении кода очень большого пакета необходимый код загружается в разделяемый пул небольшими фрагментами. Если в течение продолжительного времени он не используется, то в случае переполнения выбрасывается из разделяемого пула, а пространство выделяется для других объектов.

Самый простой способ поломать механизм разделяемого пула Oracle - не использовать связываемые переменные. Как б1ло показано в главе 1, отказавшись от использования связываемых переменных, можно поставить на колени любую систему, поскольку:

система будет тратить много процессорного времени на разбор запросов;

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

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

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

Единственным решением этой проблемы является применение разделяемых операторов SQL, которые используются повторно. В главе 10 мы опишем параметр инициализации CURSOR SHARING, который можно использовать для частичного решения подобных проблем, но наиболее эффективное решение - применять повторно используемые SQL-операторы. Даже самые большие из крупных систем требуют от 10000 до 20000 уникальных SQL-операторов. В большинстве систем используется лишь несколько сотен уникальных запросов.

Следующий практический пример показывает, насколько все осложняется при неправильном использовании разделяемого пула. Меня пригласили поработать над системой, стандартной процедурой обслуживания которой была остановка экземпляра каждую ночь для очистки области SGA и последующий перезапуск. Это приходилось делать, поскольку в течение дня в системе возникали проблемы, связанные с избыточной загрузкой процессора, и, если сервер работал больше одного дня, производительность начинала падать. Единственная причина этого была в том, что за период с 9 утра до 5 вечера они полностью заполняли разделяемый пул размером 1 Гбайт в области SGA общим размером 1,1 Гбайт. Да, именно так: 0,1 Гбайта б1ло выделено под буферный кэш и другие компоненты, а 1 Гбайт - для кэширования запросов, которые никогда не выполнялись повторно. Систему приходилось перезапускать, потому что свободная память в разделяемом пуле исчерпывалась в течение одного дня. На поиск и удаление устаревших структур (особенно из такого большого разделяемого пула) расходовалось столько ресурсов, что производительность резко падала (хотя она и до этого была далека от оптимальной, ведь приходилось управлять разделяемым пулом в 1 Гбайт). Кроме того, пользователи этой системы постоянно требовали добавления новых процессоров, поскольку жесткий разбор SQL-операторов требовал больших вычислительных ресурсов. Когда, после внесения исправлений, в приложении стали использоваться связываемые переменные, удалось не только снизить требования к ресурсам машины (у них и так вычислительные мощности намного превышали необходимые), но и появилась возможность пересмотреть распределение памяти. Вместо разделяемого пула размером в 1 Гбайт оказалось достаточно выделить 100 Мбайт, причем за много недель непрерывной работы он не заполнился.

И последнее, что хотелось бы сказать о разделяемом пуле и параметре инициализации SHARED POOL SIZE. Нет никакой связи между результатами выполнения запроса:

sys@TKYTE816> select sum (bytes) from v$sgastat where pool = shared pool; SUM (BYTES)

18322028 1 row selected.

и значением параметра инициализации SHARED POOL SIZE:

sys@TKYTE816> show parameter shared pool size NAME TYPE VALUE

shared pool size string 15360000

SVRMGR>

кроме того, что значение SUM(BYTES) FROM V$SGASTAT всегда больше, чем значение параметра SHARED POOL SIZE. В разделяемом пуле хранится много других структур, не охватываемых соответствующим параметром инициализации. Значение SHARED POOL SIZE обычно является основным, но не единственным фактором, определяющим размер разделяемого пула SUM(BYTES). Например, параметр инициализации CONTROLFILES задает управляющие файлы, а для каждого управляющего файла в разделе прочее разделяемого пула требуется 264 байта. Жаль, что показатель shared pool в представлении V$SGASTAT и параметр инициализации SHARED POOL SIZE получили похожие названия, поскольку параметр инициализации влияет на размер разделяемого пула, но не задает его полностью.

Большой пул

Большой пул назван так не потому, что это большая структура (хотя его размер вполне может быть большим), а потому, что используется для выделения больших фрагментов памяти - больших, чем те, для управления которыми создавался разделяемый пул. До его появления в Oracle 8.0, выделение памяти выполнялось в рамках разделяемого пула. Это б1ло неэффективно при использовании средств, выделяющих большие объемы памяти, например, при работе в режиме MTS. Проблема осложнялась еще и тем, что при обработке, требующей больших объемов памяти, эта память используется не так, как предполагает управление памятью в разделяемом пуле. Память в разделяемом пуле управляется на основе давности использования, что отлично подходит для кэширования и повторного использования данных. При выделении же больших объемов памяти фрагмент выделяется, используется и после этого он не нужен, т.е. нет смысла его кэ-шировать.

Серверу Oracle требовался аналог буферных пулов RECYCLE и KEEP в буферном кэше. Именно в таком качестве сейчас и выступают большой пул и разделяемый пул. Большой пул - это область памяти, управляемая по принципу пула RECYCLE, а разделяемый пул скорее похож на буферный пул KEEP: если фрагмент в нем используется часто, он кэшируется надолго.

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

Большой пул, в частности, используется:

сервером в режиме MTS для размещения области UGA в SGA;