ArcGIS Help 10.1 - Параметры инициализации Oracle

ArcGIS не требует изменения вашего экземпляра Oracle по сравнению с конфигурацией по умолчанию для запуска. Однако для больших систем вам может понадобиться вносить изменения в конфигурацию экземпляра Oracle.

При каждом запуске Oracle считываются параметры инициализации либо из файла init.ora, либо из файла параметров сервера spfile.ora. Оба файла определяют характеристики Oracle, но управляются они по-разному.

Файл init.ora расположен в директории ORACLE_BASE/admin/<ORACLE_SID>/pfile. Обычно init.ora является именем, данным файлу инициализации экземпляра базы данных Oracle. Для любого экземпляра имя файла будет выглядеть так: init<oracle SID>.ora. Например, если системный идентификатор Oracle (SID) – GIS, то именем файла init.ora для этого экземпляра будет initGIS.ora.

Изменение параметров с помощью команды ALTER SYSTEM автоматически отразится на файле параметров сервера, если экземпляр был запущен этим методом. Если экземпляр запускался с помощью файла init.ora, вам придется вручную отредактировать файл в текстовом редакторе, если вы хотите, чтобы применялись в большей степени измененные вами системные параметры.

Параметры, влияющие на совместное использование памяти

В данном разделе описаны параметры, управляющие распределением совместно используемой памяти. Более подробно о параметрах инициализации Oracle см. в разделе Настройка сервера Oracle (Oracle Server Tuning) вашей версии Oracle.

OPEN_CURSORS

Параметр инициализации Oracle OPEN_CURSORS определяет, сколько курсоров может быть одновременно открыто в одной сессии. Значение по умолчанию равно 300. Если сессия пытается открыть новый курсор, но уже открыто максимальное их число, будет возвращена ошибка Oracle -1000. ArcGIS оставляет открытыми несколько запущенных курсоров для улучшения производительности. Если установлено недостаточно большое значение параметра OPEN_CURSORS, вы столкнетесь с описанной выше ошибкой. В документации Oracle говориться о том, что установление большого значения этого параметра допустимо. Поэтому вы можете установить очень большое значение параметра, например, 2000. В результате на практике устранятся все ограничения на количество открытых курсоров, что предохранит вас от мошеннических попыток потребления чрезмерного количества курсоров. Если же вы хотите вычислить потенциальное число курсоров открытой сессии, можно применить следующую, основанную на модели данных вашей организации, формулу:

Различные курсоры управления данными ArcGIS (20) +
Различные безымянные блоки PL/SQL (20) +
Пространственные запросы – потенциально 6 на слой +
Запросы файла журнала (1) +
Различные запросы, использующиеся при редактировании версионных таблиц – 12 на версионную таблицу или слой

Таким образом, приложение ArcMap, имеющее 10 редактируемых слоев в документе, может потенциально иметь 231 открытый курсор (20 + 20 + 60 + 11 + 120 = 231). Если вы обнаружите, что курсоры закончились, можно увеличивать значение параметра OPEN_CURSORS с шагом 50 или 100.

Примечание:

Oracle 10g настроен на вывод предупреждения, в случае, если число открытых курсоров превысит 1200. Так как число в 1200 открытых курсоров отнюдь не является недостижимым для базы геоданных, вы можете увеличить порог для этого предупреждения, чтобы убрать ненужные вам предупреждения.

Случаем, когда вам, возможно, придется снизить значение параметра, является ситуация нехватки памяти на сервере с запущенным Oracle для каждого доступного процесса Oracle. Для получения системных требований к памяти для процесса требуется создание прототипа приложения. Некоторые параметры Oracle и поведения приложения, например, выражение SQL, могут вызвать требования к памяти для процесса.

SESSION_CACHED_CURSORS

Oracle отслеживает выражения SQL, указанные для каждой сессии. Если он заметит, что одно и то же выражение было введено несколько раз, оно будет перемещено в кэш курсора, который будет открыт для его дальнейшего использования. Параметр SESSION_CACHED_CURSORS определяет, сколько курсоров допускается в кэше курсора. Значение по умолчанию параметра SESSION_CACHED_CURSORS зависит от версии Oracle. Если ваш экземпляр настроен на кэш с числом курсоров менее 30, увеличьте значение этого параметра до 50.

UNDO_MANAGEMENT и UNDO_TABLESPACE

Oracle хранит несколько копий данных, которые изменяются пользователем. Во время изменяющей данные транзакции используется копия исходных данных, что позволяет обеспечить согласованный с другими сессиями вид базы данных. Кроме того, изменяющие пользователи могут отменить свою правку, используя выражение ROLLBACK, либо их процесс может "вылететь" во время выполнения, что потребует от Oracle отмены их работы, чтобы вернуть базу данных в согласованное состояние.

Для решения таких проблем Oracle хранит предварительно отредактированные данные, используя специальную структуру данных: сегмент отмены (отката). Можно установить параметры UNDO_MANAGEMENT и UNDO_TABLESPACE, чтобы Oracle мог автоматически создавать сегменты отмены и управлять ими. Чтобы включить автоматическое управление отменой, установите значение auto параметра UNDO_MANAGEMENT. После этого в качестве значения параметра UNDO_TABLESPACE введите имя табличной области, хранящей управляемые системой сегменты отмены.

Помните, что вы не можете использовать любую, произвольную табличную область для хранения управляемых системой сегментов отмены. Вы должны определить табличную область как табличную область отмены во время создания. Подробнее об отслеживании и управлении автоматической отменой см. Руководство администратора баз данных Oracle (Oracle Database Administrator's Guide).

SESSIONS

База геоданных по умолчанию допускает 48 или 64 одновременных к ней подключения, в зависимости от вашей операционной системы. Если вы настроили таблицу словаря данных для разрешения большего числа подключений, вам нужно будет изменить параметр SESSIONS для активации этой настройки.

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

Примечание:

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

PROCESSES

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

Параметр, влияющий на статистику Oracle

OPTIMIZER_MODE

Оставьте значение по умолчанию параметра Oracle OPTIMIZER_MODE. Для Oracle 10g и 11g значение по умолчанию – all_rows. Эта настройка является оптимальной для большинства баз геоданных и способствует улучшению общей масштабируемости вашей базы геоданных.

Параметры, влияющие на память

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

LOG_BUFFER

Буфер журнала является компонентом Системной глобальной области (Oracle System Global Area (SGA)) Oracle, содержащей в памяти неподтвержденные изменения, внесенные в базу данных, до тех пор пока фоновые процессы Oracle не запишут эти изменения на диск. Поскольку такие записи вносятся постоянно – как минимум, каждые три секунды, – буфер журнала не требует большого количества места и может иметь размер меньше мегабайта. Размер буфера журнала повторения управляется параметром LOG_BUFFER. По умолчанию размер буфера журнала подходит для большинства баз геоданных. Однако для баз данных с высокой частотой записи данных производительность может снизиться при одновременном доступе к буферу журнала нескольких пользователей системы. Выявление и изменение этого условия требует навыков высокого уровня, таких как мониторинг защелок и событий ожидания. Подробнее см. Руководство по настройке производительности баз данных Oracle (Oracle Database Performance Tuning Guide) и базу знаний MetaLink.

Примечание:

Установка большого значения LOG_BUFFER для операций значительной загрузки может привести к уменьшению производительности. Между транзакциями может возникнуть конкуренция (latch contention) в случае, если значение буфера журнала слишком велико.

SHARED_POOL_SIZE

Разделяемый пул - другой компонент Oracle SGA, который содержит кэш данных словаря и кэш библиотеки. Кэш данных словаря (data dictionary cache) включает информацию об объектах данных, свободном месте и правах доступа. Кэш библиотеки (library cache) хранит последние используемые выражения SQL. Как правило, если размер разделяемого пула достаточно велик, чтобы соответствовать требованиям к ресурсам кэша библиотеки, то его также достаточно для хранения данных кэша словаря. Базы геоданных могут использовать больший разделяемый пул, чем другие приложения Oracle. ArcGIS держит кэш SQL выражений в памяти клиентских приложений. Большой разделяемый пул позволяет держать открытыми больше курсоров, что позволяет уменьшить число операций управления курсором и увеличить производительность. Размер разделяемого пула определяется параметром SHARED_POOL_SIZE. Esri рекомендует вам устанавливать параметр SHARED_POOL_SIZE кратным 16 MБ, чтобы от принимался любой системой, поддерживаемой Esri, а также установить его значение большим 128 Мб:

shared_pool_size = 128,000,000

Базы геоданных с высокой активностью работы, поддерживающие нестабильную утилиту или редактирование участков, могут требовать, чтобы значение параметра было установлено большим 250 МБ.

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

DB_CACHE_SIZE

Кэш буфера – компонент Oracle SGA, хранящий наиболее часто используемые блоки данных. Блоки данных являются единицей передачи данных Oracle. Oracle считывает и записывает блоки данных в базу данных, когда пользователь редактирует ее, либо выполняет к ней запросы. Размер кэша буфера управляется параметром DB_CACHE_SIZE.

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

Определите объем оперативной памяти (RAM) вашего сервера.
Умножьте это число на 0,66, чтобы определить целевой размер SGA.
Для получения объема памяти, доступного для буфера кэша необходимо вычесть значения SHARED_POOL_SIZE и LOG_BUFFER .
Уменьшите это число на 10%, чтобы учесть использование внутренней памяти Oracle.
Разделите на размер блока базы данных, чтобы определить настройку DB_BLOCK_BUFFERS.

Например:

memory available to SGA = physical RAM * 2/3

memory available to buffer cache
= (memory available to SGA - (shared_pool_size + log_buffer)) * 0.9

db_block_buffers 

= memory available to buffer cache / db_block_size

PGA_AGGREGATE_TARGET

Выделите место для частной глобальной области (PGA) процессов Oracle server. Это место обычно используется в качестве временного буфера для сортировки и слияния данных при соединении таблиц. Установите параметр WORKAREA_SIZE_POLICY равным AUTO, затем вручную укажите значение PGA_AGGREGATE_TARGET равным объему оперативной памяти, умноженному на 0,16. После использования приложения в течении некоторого времени настройте значение параметра PGA_AGGREGATE_TARGET в соответствии с процедурой, описанной в Руководстве по настройке производительности баз данных Oracle (Oracle Performance Tuning Guide and Reference).

workarea_size_policy = auto
pga_aggregate_target = <total physical RAM * 0.16)

Примечание:

Oracle использует значение параметра PGA_AGGREGATE_TARGET для выделения памяти под сортировку только в случае, когда значение WORKSPACE_POLICY равно AUTO. В противном случае Oracle будет использовать старый, ручной способ управления сортировкой, который включает определение параметров SORT_AREA_SIZE и HASH_AREA_SIZE.

Используйте автоматическое управление рабочей областью

Oracle может управлять собственной памятью для процессов сервера, автоматически обслуживая пользовательские сессии. Во многом также он управляет общей памятью, автоматически регулируя разделяемую память (ASMM). Oracle может динамически выделять рабочие области SQL из большого пула памяти, доступной для всех PGA, чтобы осуществлять сортировку, хеширование и обработку растрового индекса, а не использовать их фиксированные размеры, настроенные администратором баз данных (DBA). Чтобы включить автоматическое управление рабочей областью, установите для параметра WORKAREA_SIZE_POLICY значение AUTO. Затем настройте общий объем памяти, доступной для всех PGA, указав размер в качестве значения параметра PGA_AGGREGATE_TARGET. По умолчанию Oracle настроит общий размер PGA равным 20% от размера SGA. Это будет хорошей отправной точкой, однако, размер PGA все же должен базироваться на типе работы, выполняемой процессами сервера, а не строго вычисляться в зависимости от размера SGA. При работе вашей базы данных под нормальной загрузкой вы можете отслеживать и настраивать размер PGA, исходя из реальной нагрузки. Подробнее об этом процессе см. в Руководстве по настройке производительности баз данных Oracle (Oracle Database Performance Tuning Guide).

Используйте управление автоматически разделяемой памятью

При работе с Oracle 10g вы имеете возможность настроить общий размер SGA и разрешить Oracle автоматически управлять распределением памяти среди пулов. Это ASMM с параметром SGA_TARGET. В дополнение к упрощению работы администратору баз данных, по сравнению с ручной настройкой пулов, использование ASMM позволяет Oracle непрерывно контролировать требования к каждому пулу и динамически уточнять их размеры, когда экземпляр запущен. Было бы непрактичным непрерывное осуществление постоянного уровня контроля администратором базы данных. Вы можете дать рекомендации ASMM, настроив и параметр SGA_TARGET parameter для указания общего размера SGA, и один или несколько параметров для отдельных пулов. Если настроены и SGA_TARGET, и размер пула, Oracle считает размер пула минимальным, который ASMM может хранить в этом кэше.

Учитывая влияние разделяемого пула на производительность базы геоданных, при использовании ASMM установите минимальный размер разделяемого пула (параметр инициализации SHARED_POOL_SIZE) равным, как минимум, 128 МБ, как показано выше, помимо установки SGA_TARGET.

Примечание:

Чтобы использовать автоматическую рабочую область и управление автоматическим разделением памяти, значение параметра STATISTICS_LEVEL должно быть равно TYPICAL (используется по умолчанию) либо ALL.

Другие изменения

Не являясь параметром инициализации, директива менеджера ресурсов базы данных UNDO_POOL может быть установлена, чтобы позволить группе потребителей sde собрать значительное количество места для отмены операций сжатия.

Для этого вам нужно настроить группу потребителей для пользователя sde и изменить директиву UNDO_POOL, чтобы позволить неограниченному пулу отмены для этой группы потребителей.

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

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

9/11/2013