Настройка памяти в Oracle

Ниже приведены несколько общих правил, касающихся конфигурации Системной глобальной области (SGA) Oracle и структур памяти, которые влияют на размер частной глобальной зон пользователей Oracle (PGA). SGA представляет собой блок разделяемой памяти, которую Oracle выделяет и разделяет во всех сеансах. Для более полной информации по SGA, обратитесь к документации Oracle Concepts Guide для вашего релиза Oracle.

• SGA не должны перекрываться.

  Вы не должны создавать SGA размером большим, чем две-трети размера физического объёма оперативной памяти (RAM) вашего сервера. Ваша виртуальная память должна учитывать как требования SGA, так и требования всех активных процессов на сервере.

• Избежание излишней подкачки.

  Используя инструменты вашей операционной системы (vmstat для UNIX и Task Manager для Windows), выполните проверку на излишнюю подкачку. Высокая степень подкачки может возникнуть в результате того, что SGA установлен слишком большим.

• Настройка достаточного объёма виртуальной памяти.

  Как правило, Oracle рекомендует, чтобы ваш файл подкачки как минимум в три-четыре раза превышал размер физической памяти RAM. Требуемый размер файла подкачки для UNIX (swap file) или для Windows (page file) зависит от числа активных сеансов ArcSDE. Для каждой сеанса обслуживания ArcSDE (приложение сервер), стартует процесс gsrvr и соответствующий процесс Oracle. Для определения степени использования памяти этими процессами, используйте команду ps –elf для системы UNIX или закладку Процессы (Processes) в Диспетчере задач Windows (Windows Task Manager). Вы должны вычесть размер Oracle SGA из пользовательских процессов Oracle. Общий размер ArcSDE gsrvr, ArcSDE giomgr, Oracle пользователя, Oracle фона, операционной системы, и любых других процессов, запущенных на сервере должен быть в состоянии вписаться в виртуальную память.

  Для клиентских приложений ArcSDE, которые подключаются непосредственно к экземпляру Oracle, процесс gsrvr не существует. Кроме того, если сервис ArcSDE не используется, потому что все клиентские приложения подключаются непосредственно к экземпляру Oracle, процесс giomgr также не будет запущен. По этой причине, прямые соединения оставляют меньший отпечаток памяти на сервере, так как процесс gsrvr отсутствует. Параметры, которые влияют на использование памяти включают LOG_BUFFERSHARED_POOL_SIZE, DB_CACHE_SIZE, PGA_AGGREGATE_TARGET, SGA_TARGET и WORKAREA_SIZE_POLICY.

  Пояснения и предполагаемые установки для этих параметров см. в разделе Параметры инициализации Oracle (Oracle initialization parameters).

• Используйте явные квоты на табличные пространства, чтобы избежать использования всего доступного пространства хранения.

  Пользователи с правами на создание объектов Oracle, такие как пользователь SDE, владелец базы геоданных, хранимой в пользовательской схеме, и владельцы данных, могут получить доступ к пространству хранения (в памяти) одним из двух методов: обладая системными правами UNLIMITED TABLESPACE или получив явную квоту на табличное пространство.

  Права UNLIMITED TABLESPACE позволяют пользователю выделить неограниченный объем пространства в любых или во всех табличных пространствах в базе данных, включая управляемые Oracle табличные пространства SYSTEM и SYSAUX. Этим предлагается возможность для конечных пользователей, случайно или намеренно, использовать все доступное пространство хранения вплоть до краха экземпляра Oracle. По этой причине, лучше всего, если только пользователи с правами администратора базы данных (DBA) обладали этой мощной системой привилегий.

  Для пользователей, которые не являются администраторами базы данных, вы должны назначить квоту на одно или более табличных пространств, чтобы они могли создавать объекты Oracle в управляемом режиме. Например, вы можете предоставить владельцу данных GIS_ADMIN квоту на табличные пространства GIS_DATA и GIS_INDEX, но не на табличные пространства SYSTEM и SYSAUX. Это позволяет контролировать, где владелец данных может создавать свои таблицы и индексы, и, дополнительно, сколько места эти объекты могут потреблять.

  Как правило, администратор (DBA) назначает либо неограниченную квоту, либо отсутствие квоты для каждого табличного пространства для администрации экземпляра проекта и владельцев данных. Таким образом, администратор (DBA) контролирует, где физически хранятся данные, например, в массиве зеркального диска для усиления защиты данных, и может выделить данные в логические контейнеры, отделив их от системных данных и данных других проектов и приложений. Неограниченная квота позволяет владельцу данных выделить столько места, сколько необходимо для табличного пространства, к которому он имеет доступ. Как правило это оптимально, потому что пользователи, имеющие доступ к учётной записи владельца данных, обычно имеют дополнительную подготовку или опыт, и часто знают больше о требованиях к хранению собственных ГИС-данных, чем администратор.

  В условиях, когда редакторам данных или вьюерам данных разрешено создавать свои собственные объекты базы геоданных, такие как выходные данные операций геообработки, вы можете назначить ограниченные квоты на табличные пространства, для которых эти пользователи имеют права записи. Например, для табличного пространства GIS_DATA, вьюер данных может иметь квоту 100 Мб, редакторы данных могут имеют квоту 500 Мб, а владельцы данных могут иметь неограниченную квоту. Вы должны настроить назначения квот в соответствии с вашими данными и конкретными потребностями выполняемых бизнес-процессов.