DeepEdit!

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

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

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

Чтобы избежать таких ситуаций, корпорация Oracle разработала многопоточный сервер (Multi-Threaded Server, MTS), позволяющий использовать одно соединение одновременно нескольким клиентам. Это делается с помощью механизма, называемого диспетчером (dispatcher), который управляет соединениями с базой данных таким образом, чтобы поддерживать большее число пользователей при затрате меньшего количества ресурсов. Посмотрим, как работает MTS.

Независимо от того, какие соединения будут использоваться — выделенные или многопоточные, при запуске системы в очередь нужно запустить прослушивающий процесс (listener), предназначенный для приема запросов на соединения. Он прослушивает либо адрес по умолчанию (обычно это порт 1521 или 1526), либо адреса, указанные в его конфигурационном файле (listener.ora). После запуска прослушивающего процесса запускаются базы данных, которые регистрируются в прослушивающем процессе. В предыдущих версиях применялся противоположный подход — базы данных запускались до прослушивающего который затем соединялся с каждой активной базой данных.

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

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

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

Чтобы проверить, какие диспетчеры зарегистрировались в прослушивающем процессе, можно использовать команду services утилиты Listener Control (knrctl). Об этом будет подробнее рассказано в главе 3.

Итак, прослушивающий процесс, базы данных и диспетчеры запущены и зарегистрированы. Что будет происходить дальше? Взгляните на рис. 2.4, где показана процедура установления соединения с разделяемым сервером.

Клиент посылает запрос.

Прослушивающий процесс определяет адрес наименее занятого диспетчера еще един адрес  процесса и соединяется с диспетчером.

Диспетчер помещает запрос в очередь разделяемого сервера.

Разделяемый сервер извлекает запрос из очереди и соединяется с базой данных для обработки запроса.

Сначала клиент соединяется с прослушивающим процессом по его сетевому адресу. Прослушивающий процесс проверяет, разрешено ли обслуживание данного запроса. Если запрос не может быть обслужен, сетевой сеанс не открывается. Если обслуживание возможно, прослушивающий процесс выдает клиенту перенаправляющее сообщение. Оно содержит сетевой адрес наименее загруженного диспетчера разделяемого сервера. Получив это сообщение j клиент разрывает соединение с прослушивающим процессом и устанавливает соединение с диспетчером по указанному адресу. После установления соединения диспетчер передает прослушивающему процессу новое значение нагрузки, чтобы тот мог равномерно распределять входящие запросы между диспетчерами, работающими по одному протоколу. Затем диспетчер помещает клиентский запрос в очередь разделяемого сервера для последующей обработки.

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