DeepEdit!

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

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

Если же вы запускаете огромные пакетные задания по загрузке информации в хранилище данных, устанавливающие только одно соединение, то более подходящими могут оказаться выделенные серверы. При этом у вас есть две возможности: либо создавать (порождать) соединения заранее, до прихода запроса, либо порождать процесс выделенного сервера после приема запроса. В первом случае соединение будет доступно немедленно, однако следует иметь в виду, что предварительно порожденные процессы остаются в памяти на протяжении всего времени жизни прослушивающего процесса.  Иными словами, если вы предварительно создали десять выделенных соединений, а используете только два, то
остальные восемь лишь отнимают ресурсы. С другой стороны, если выделенные процессы будут создаваться только после прихода запроса, то клиентам придется ждать, пока процесс запустится. При отсоединении клиента от выделенного сервера, который не был создан заранее, системные ресурсы освобождаются. А если количество запросов на соединения превысит количество предварительно созданных процессов? Тогда Oracle просто начнет создавать выделенные процессы для каждого следующего запроса, освобождая ресурсы при отсоединении пока
количество соединений не вернется к прежней величине.

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

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

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

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

Чтобы ответить на этот вопрос, нужно вспомнить принцип работы диспетчера MTS. Поддержка множества пользователей возможна за счет того, что каждый пользователь делает паузу между запросами. Это позволяет обрабатывать запросы по очереди. Теперь представьте, что загружается большой массив данных. Никаких пауз здесь нет — идет непрерывный поток вставок, обновлений или удалений. Следовательно, для этой задачи есть смысл использовать выделенный сервер.

Чтобы определить, нужно ли разрешать создание выделенных соединений параллельно с MTS, необходимо узнать, какие типы транзакций предполагается выполнять в системе. Возможно, следует запланировать загрузку данных на то время, когда пользователей меньше всего, и вручную запускать выделенные процессы для поддержки этих операций. Помните, что запуск и останов прослушивающих процессов не приводит к разрыву существующих соединений. Таким образом, в зависимости от требований, предъявляемых конкретной задачей, вы можете в какой-то момент останавливать процессы MTS и запускать выделенные процессы для резервного копирования и пакетной загрузки больших объемов данных. Но не будут ли соединения, установленные через MTS, разрываться при остановке MTS? Чтобы дать ответ на этот вопрос, попробуем разобраться, что происходит при использовании

Работа через многопоточный сервер происходит следующим образом:

•        Клиент запрашивает соединение.

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

Клиент напрямую соединяется с диспетчером.

Диспетчер помещает запрос в очередь входящих запросов, которая размещена в

•        Свободный процесс разделяемого сервера извлекает запрос

из очереди и обрабатывает его.

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

•        Диспетчер считывает результат из очереди ответов и возвращает его клиенту.

Конструкция alter system set... в сочетании с параметрами mts_ser-vers и mts_dispatchers позволяет добавлять процессы разделяемых серверов или диспетчеров. Эта же конструкция позволяет останавливать существующий процесс разделяемого сервера после обработки текущего запроса, а также останавливать процесс диспетчера для заданного протокола после отсоединения текущих пользовательских процессов от экземпляра.

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

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

соединений, можно создать дополнительные прослушивающие процессы и разрешить объединение соединений и/или балансировку нагрузки. Об

объединении соединений и балансировке нагрузки мы подробнее поговорим в следующем разделе, "Вопросы соединений", а сейчас посмотрим,

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

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