Java-пул

Java-пул - это самый новый пул памяти в Oracle 8i. Он б1л добавлен в версии 8.1.5 для поддержки работы Java-машины в базе данных. Если поместить хранимую процедуру на языке Java или компонент EJB (Enterprise JavaBean) в базу данных, сервер Oracle будет использовать этот фрагмент памяти при обработке соответствующего кода. Одним из недостатков первоначальной реализации Java-пула в Oracle 8.1.5 б1ло то, что он не отображался командой SHOW SGA и не был представлен строками в представлении V$SGASTAT. В то время это особенно сбивало с толку, поскольку параметр инициализации JAVA POOL SIZE, определяющий размер этой структуры, имел стандартное значение 20 Мбайт. Это заставляло людей гадать, почему область SGA занимает оперативной памяти на 20 Мбайт больше, чем следует.

Начиная с версии 8.1.6, однако, Java-пул виден в представлении V$SGASTAT, а также в результатах выполнения команды SHOW SGA. Параметр инициализации JAVA POOL SIZE используется для определения фиксированного объема памяти, отводящегося для Java-кода и данных сеансов. В Oracle 8.1.5 этот параметр мог иметь зна-

при распараллеливании выполнения операторов - для буферов сообщений, которыми обмениваются процессы для координации работы серверов;

в ходе резервного копирования для буферизации дискового ввода/вывода утилиты RMAN.

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

SORT AREA RETAINED SIZE, область UGA может быть очень большой, и, конечно,

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

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

Использовать большой пул при работе в режиме MTS не обязательно, но желательно. Если сервер работает в режиме MTS в отсутствие большого пула, вся память выделяется из разделяемого пула, как это и было в версиях Oracle вплоть до 7.3. Из-за этого производительность со временем будет падать, поэтому такой конфигурации надо избегать. Большой пул стандартного размера будет создаваться при установке одного из следующих параметров инициализации: DBWn IO SLAVES или PARALLEL AUTOMATIC TUNING. Рекомендуется задавать размер большого пула явно. Однако стандартное значение не может использоваться во всех без исключения случаях.

чения от 1 Мбайт до 1 Гбайт. В Oracle 8.1.6 и последующих версиях диапазон допусти-м1х значений уже 32 Кбайт-1 Гбайт. Это противоречит документации, где по-прежнему указан устаревший минимум - 1 Мбайт.

Java-пул используется по-разному, в зависимости от режима работы сервера Oracle. В режиме выделенного сервера Java-пул включает разделяемую часть каждого Java-клас-са, использованного хоть в одном сеансе. Эти части только читаются (векторы выполнения, методы и т.д.) и имеют для типичных классов размер от 4 до 8 Кбайт.

Таким образом, в режиме выделенного сервера (который, как правило, и используется, если в приложениях применяются хранимые процедуры на языке Java) объем общей памяти для Java-пула весьма невелик; его можно определить исходя из количества используемых Java-классов. Учтите, что информация о состоянии сеансов при работе в режиме разделяемого сервера в области SGA не сохраняется, поскольку эти данные находятся в области UGA, а она, если вы помните, в режиме разделяемого сервера является частью области PGA.

При работе в режиме MTS Java-пул включает:

разделяемую часть каждого Java-класса и

часть области UGA для каждого сеанса, используемую для хранения информации о состоянии сеансов.

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

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

В режиме MTS, который обычно используется для приложений, использующих архитектуру CORBA или компоненты EJB (об этом говорилось в главе 1), может потребоваться очень большой Java-пул. Его размер будет зависеть не от количества используе-м1х классов, а от количества одновременно работающих пользователей. Как и большой пул, размеры которого становятся очень большими в режиме MTS, Java-пул тоже может разрастаться до огромных размеров.

Итак, в этом разделе была рассмотрена структура памяти сервера Oracle. Мы начали с уровня процессов и сеансов, поговорили об областях PGA (Process Global Area - глобальная область процесса) и UGA (User Global Area - глобальная область пользователя) и разобрались в их взаимосвязи. Было показано, как режим, в котором пользователь подключается к серверу Oracle, определяет организацию памяти. Подключение к выделенному серверу предполагает использование памяти серверным процессом в большем объеме, чем подключение в режиме MTS, но работа в режиме MTS требует создания намного большей области SGA. Затем мы описали компоненты самой области SGA, выделив в ней шесть основных структур. Были описаны различия между разделяемым и большим пулом, и показано, почему большой пул необходим для сохранения разделяемого пула. Мы описали Java-пул и его использование в различных условиях. Б1л рассмотрен буферный кэш и способ деления его на меньшие, более специализированные пулы.

Серверные процессы

Мы уже бегло рассматривали эти процессы ранее при обсуждении выделенных и разделяемых серверов. Здесь мы еще раз опишем два вида серверных процессов и более детально рассмотрим их архитектуру.

Выделенные и разделяемые серверы решают одну и ту же задачу: обрабатывают передаваемые им SQL-операторы. При получении запроса SELECT * FROM EMP именно выделенный/разделяемый сервер Oracle будет разбирать его и помещать в разделяемый пул (или находить соответствующий запрос в разделяемом пуле). Именно этот процесс создает план выполнения запроса. Этот процесс реализует план запроса, находя необходимые данные в буферном кэше или считывая данные в буферный кэш с диска. Такие серверные процессы можно назвать рабочими лошадками СУБД. Часто именно они потребляют основную часть процессорного времени в системе, поскольку выполняют сортировку, суммирование, соединения - в общем, почти все.

В режиме выделенного сервера имеется однозначное соответствие между клиентскими сеансами и серверными процессами (или потоками). Если имеется 100 сеансов на UNIX-машине, будет 100 процессов, работающих от их имени. Графически это можно представить так:

Теперь можно переходить к физическим процессам экземпляра Oracle.

Процессы

Осталось рассмотреть последний элемент головоломки . Мы изучили организацию базы данных и набор образующих ее физических файлов. Разбираясь с использованием памяти сервером Oracle, рассмотрели половину экземпляра. Оставшийся компонент архитектуры - набор процессов, образующий вторую половину экземпляра. Некоторые из этих процессов, например процесс записи блоков в базу данных (DBWn) и процесс записи журнала (LGWR), уже упоминались. Здесь мы более детально рассмотрим функцию каждого процесса: что и почему они делают. В этом разделе процесс будет использоваться как синоним потока в операционных системах, где сервер Oracle реализован с помощью потоков. Так, например, если описывается процесс DBWn, в среде Windows ему соответствует поток DBWn.

В экземпляре Oracle есть три класса процессов.

Серверн1е процессы. Они выполняют запросы клиентов. Мы уже затрагивали тему выделенных и разделяемых серверов. И те, и другие относятся к серверным процессам.

Фоновые процессы. Это процессы, которые начинают выполняться при запуске экземпляра и решают различные задачи поддержки базы данных, такие как запись блоков на диск, поддержка активного журнала повторного выполнения, удаление прекративших работу процессов и т.д.

Подчиненн1е процессы. Они подобны фоновым процессам, но выполняют, кор-

ме того, действия от имени фонового или серверного процесса.

Мы рассмотрим все эти процессы и постараемся выяснить, какую роль они играют в экземпляре.