Достаточно часто администраторы БД Oracle недооценивают возможности Shared server при большом количестве соединений. Ниже будет на примере базы Супермага рассмотрена настройка Shared сервера, но суть подойдет и для других баз Oracle. Итак, Супермаг, собака такая, даже на простое подключение к БД тратит минимум 3 сессии, что в сумме дает целый ворох простаивающих, но выделенных процессов на сервере, пожирающих достаточное количество оперативки. Маленький ликбез, хоть он и описан уже на миллионе сайтов: Oracle позволяет организовать два типа подключений. Первый: выделенный, когда при подключении клиента на сервере образуется отдельный процесс со всеми связанными потерями ресурсов. Второй: разделяемый, когда пул подключений клиентов обрабатывается заранее определенным количеством менеджеров. Во втором случае выгода очевидна, чем раздавать ресурсы понемногу на каждого клиента, можно дать побольше, но менеджерам. Часто бывает, что в первом случае тонущий от наплыва клиентов сервер выкидывает их процессы в своп, да и время на обслуживание тонны процессов... Но и у второго типа есть нюансы, например, если вы запустите слишком мало менеджеров, то ожидающие менеджера клиенты будут выглядеть зависшими (это Супермаг так написан). По опыту использования предложу следующее. Там,
где нет специалиста или количество сессий не поднимается выше 50 - не трогайте, пусть будет "дедик". От 100 сессий и при наличии соображающего человека на подхвате лучше все же перейти на Shared, особенно, если памяти немного, например, 4Гб. Произведем оценку.
Код:
SQL> select count(*) from v$session;
COUNT(*)
----------
160 видно, что явный претендент на shared
в течение дня неплохо бы понаблюдать за
Код:
SQL> select count(*) from v$session where status='ACTIVE' and type='USER';
COUNT(*)
----------
4 т.е. видно, что 5 юзеров лопатят себе что-то в базу. Интересует максимальное число сессий, НО, не включая какие-то разовые операции с сервера, вроде той же загрузки расчетов ТД. Это число потребуется для того, чтобы определить количество выделяемых менеджеров. Если число превышает количество процессорных ядер (не НТ) вдвое и более раз
выбрасывайте помойку, ваш сервер не готов к таким нагрузкам, добавьте CPU. Будем считать, что на той машине, где я снял данные, 6 ядер. В таком случае в общем приближении надо выдать базе 4 менеджера и 12 (двойное количество ядер) - их максимальное число. Так и поступим (можно менять на ходу):
Код:
alter system set shared_servers=4;
alter system set max_shared_servers=12;
собственно, на этом настройка сервера закончена. Обратите внимание, что на клиентах в tnsnames.ora не должно быть записи "(SERVER = DEDICATED)", если она есть, то удалите ее. Но с другой стороны, там, где вы работаете RMANом, считаете товародвижение или работает Сервер лицензий, "(SERVER = DEDICATED)" наоборот, должен быть обязательно. Иначе может произойти логическое замыкание, когда менеджера не хватит на обработку запроса ключа, который запрашивает занимающая в данный момент менеджера сессия. А RMAN или ТД просто не запустятся. Пример tnsnames.ora для сервера:
Код:
БАЗА =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = БАЗА)
)
) в качестве проверки того, что вы все сделали правильно, можно задать запрос:
Код:
SQL> select server,count(server) from v$session group by server;
SERVER COUNT(SERVER)
--------------------------- -------------
DEDICATED 31
NONE 132
SHARED 2
из этого запроса видно, что 31 сессия идет в выделенном режиме, как и раньше, 2 сессии обрабатываются менеджерами, а 132 сессии провисли в бездействии, не обрабатываемые менеджером.
Встречаются случаи повисания диспетчеров при достаточном количестве сессий... Приходится обходить это выделением нескольких диспетчеров
Код:
ALTER SYSTEM
SET DISPATCHERS =
'(INDEX=0)(PROTOCOL=TCP)(DISPATCHERS=5)',
'(INDEX=1)(PROTOCOL=ipc)(DISPATCHERS=10)';