DeepEdit!

Приходилось ли вам вводить информацию в компьютер непрерывно в течение многих часов? Про меня этого не скажешь. Я часто останавливаюсь, чтобы подумать над следующим действием. Заполняя форму для отправки заказа через Интернет, я прерываюсь, чтобы достать кредитную карту и посмотреть ее номер. Более того, я знаю людей, которые оставляют свои компьютеры соединенными с базой данных в течение всего рабочего дня. Иногда они даже забывают выйти из системы, уходя домой, и соединения сохраняются всю ночь — если, конечно, их процессы не уничтожаются при запуске ночного пакетного задания.

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

Теперь предположим, что вы отвечаете за работу Интернет-сайта. Через ваш сайт ежедневно делаются тысячи заказов. Каждый заказ сохраняется в базе данных Oracle. Если полагаться на индивидуальные, выделенные соединения Net8, то велика вероятность, что рано или поздно машина исчерпает свои ресурсы и перестанет принимать заказы покупателей. Я подозреваю, что руководство компании не слишком обрадуется,

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

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

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

За счет что процессы разделяемых серверов запускаются только один раз, исключаются дополнительные накладные расходы на создание клиентских соединений. Каждый клиент использует меньше памяти, поэтому требования к ее объему снижаются. Управление процессами также требует меньших затрат. В результате появляется возможность одновременно поддерживать большее число пользователей. 

Добавление MTS систему с небольшим числом соединений (менее 200) или низкой активностью может ухудшить производительность. MTS разрабатывался для более эффективного использования ресурсов в системах с большой нагрузкой.

При использовании MTS пользовательская глобальная область (User Global Area, UGA), входящая в состав глобальной области процесса (Process Global Area, PGA), перемещается в разделяемый пул. UGA содержит информацию о пользовательских сеансах, области сортировки и частные области SQL. Самым большим компонентом UGA обычно является область сортировки, размер которой задается параметром файла init.ora. Без MTS каждый клиентский процесс резервирует память под область сортировки независимо от того, будет ли он впоследствии выполнять сортировку. В режиме MTS область сортировки создается как часть разделяемого или большого пула и может использоваться всеми процессами. Клиентам не нужно резервировать память собственные области сортировки.

С другой стороны, при перемещении UGA в разделяемый пул необходимо увеличивать размер, чтобы обеспечить выполнение всех операций сортировки. Но не беспокойтесь. Вам придется увеличивать разделяемый пул не на ту величину, о которой вы могли подумать (количество клиентов, умноженное на размер области сортировки). Перемещение сортировок в SGA сервера повышает общую эффективность использования памяти. Можно увеличить разделяемую область SQL на величину, равную половине общего размера SGA. Это хорошее начальное значение, если вы первый раз переходите на MTS. Однако корпорация Oracle, введя в параметр large_pool_size, рекомендовала использовать для UGA большой пул вместо разделяемого. Приведенные ниже запросы помогут определить правильный размер пула или подскажут, нужно ли его увеличить, если вы уже установили значение large_ pool_size.

417381 Bytes

Результат первого запроса показывает, что текущий размер памяти, выделенной всем сеансам, равен 157 125 байтам. Согласно результату второго запроса, сумма максимальных размеров памяти для всех сеансов равна 417 381 байту.

Чтобы определить, насколько нужно увеличить большой или разделяемый пул, можно использовать результат любого из этих запросов. Первая величина обычно служит лучшей оценкой. Исключение составляют ситуации, в которых высока вероятность того, что почти всем сеансам одновременно потребуется максимум выделенной памяти. Однако вы должны иметь в виду, что если все сеансы соединены с процессами выделенных серверов, то эта память является частью UGA; если же сеансы соединены с процессами        то эта память входит в состав разделяемого пула.