СУБД Oracle XE или Oracle Express Edition в первую очередь предназначена для использования в качестве небольшой базы данных для разработчиков, локальной базы данных для администраторов, студентов или в качестве бесплатной платформы для демонстраций ПО. Ее основные преимущества – абсолютно бесплатное использование и простота в установке и обслуживании. С другой стороны версия начального уровня имеет достаточно серьезные ограничения – в работе БД может быть задействовано максимум 1Гб оперативной памяти, 1 процессор и 4 Гб дискового пространства для хранения данных. И эти ограничения нужно учитывать при распределении ресурсов.
Самая распространенная ошибка, обсуждаемая на форумах, увеличение SGA памяти:
ORA-47500: XE edition memory parameter invalid or not specified
ORA-01078: failure in processing system parameters
Эта ошибка напрямую связана с ограничением оперативной памяти в 1Гб. Решение проблемы здесь достаточно очевидное, но на форумах почему-то самый распространенный ответ “задайте размер SGA памяти меньше 1Гб”. А вот насколько меньше и почему? При распределении отведенного лимита памяти следует помнить, что необходимо выделить пространство не только на SGA, но и на PGA таким образом, чтобы в сумме они не превышали 1Гб. Поэтому, если к примеру PGA_AGGREGATE_TARGET = 201326592, то значение SGA_TARGET не может превышать 872415232.
Изменение параметров распределения памяти можно изменить следующим образом:
alter system set PGA_AGGREGATE_TARGET=150m scope=spfile; alter system set SGA_TARGET= 850m scope=spfile; shutdown immediate startup
Второй вариант – изменить параметры вручную в PFILE. Для этого из текущего SPFILE предварительно создается PFILE, в него вносятся изменения, далее БД останавливается и запускается с использованием измененного PFILE, из него пересоздается SPFILE и сервер снова перезапускается в обычном режиме. Подробные шаги этого метода описаны здесь.
Дальнейшее распределение памяти внутри SGA зависит от конкретного случая с учетом задач, для которых предназначена БД, количества пользователей, используемых сервисов и т.д.
Кроме распределения памяти необходимо обратить внимание на максимальное количество одновременно запущенных сессий. По-умолчанию для Oracle XE установлено 20 сессий. Это достаточно для персонального использования. Если же планируется многопользовательская работа, то количество сессий рассчитывается как максимальное количество одновременных подключений пользователей, увеличенное на 10% (для рекурсивных сессий) и количество фоновых процессов.
Например, для 20 пользовательских подключений и 10 служебных сессий параметр sessions = 32.
Выбор режима сервера. Что лучше – DEDICATED или SHARED? В режиме DEDICATED каждая сессия получает свой управляющий процесс, с которым связано отдельное пространство в программной области памяти (PGA). В этом режиме требуется большое количество системных процессов (по одному для каждого подключения). В режиме SHARED SERVER один системный процесс обслуживает несколько пользовательских подключений, и все они используют одно общее пространство PGA, что позволяет использовать полученные результаты повторно для аналогичных запросов других пользователей. Т.к. несколько сессий обслуживаются одним процессом, необходимы дополнительные средства управления ресурсами и обслуживания сессий. За управление сессиями отвечает специальный диспетчер (DISPATCHER).
Север БД может работать и в смешанном режиме, когда возможны и DEDICATED И SHARED подключения. Режим SHARED SERVER активируется обязательной установкой параметра shared_servers, определяющего начальное и минимальное количество shared серверов (по-умолчанию 4).
shared_servers=4
Диспетчеру для работы требуется как минимум 1 системный процесс. При активном подключении пользователей возможно понадобиться увеличить вручную количество процессов, обслуживающих работу диспетчера. За это отвечает параметр dispatchers. Например, чтобы выделить 5 процессов для диспетчера, следует задать следующее значение этого параметра.
dispatchers='(PROTOCOL=TCP) (DISPATCHERS=5) (SERVICE=XEXDB)'
Какому из двух режимов отдать предпочтение – зависит опять же от целей и способов использования БД. На эту тему существует много дискуссий. Сейчас на практике, при прямом подключении, работа в DEDICATED режиме происходит быстрее и стабильнее. Большое количество системных процессов для большинства современных ОС не является проблемой, а расходов на работу диспетчера не требуется. О предпочтении DEDICATED режима говорит и Том Кайт, настоятельно рекомендуя не использовать SHARED SERVER без особой необходимости. Режим SHARED SERVER может потребоваться для работы сервера приложений, например, этот режим использует Application Express. Административные задачи, например остановка/запуск БД, восстановление данных и пр., наоборот, могут выполняться только при подключении в DEDICATED режиме.