DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Вопросы соединений

Существует много различных подходов к организации соединений клиентов с базой данных. При небольшом количестве клиентов можно остановиться на выделенных соединениях через один прослушивающий процесс. Однако в случае Web-сайта или другой системы с очень интенсивным трафиком стоит воспользоваться более элегантными решениями, предлагаемыми Oracle — например, объединением соединений.
Далее приводятся некоторые вопросы, относящиеся к области соединений.
Следует ли предусмотреть увеличение размера очереди прослушивающего процесса?
При планировании сети может выясниться, что ожидаемый объем трафика довольно велик. В этом случае одним из пунктов вашего плана может стать выбор размера очереди прослушивающего процесса. Если предполагается, что прослушивающий процесс будет принимать большое число запросов на соединения, можно разрешить постановку запросов в очередь. Это позволит прослушивающему процессу обрабатывать запросы, поступающие одновременно. Чтобы активизировать очередь, необходимо указать ее размер, присвоив целое значение параметру queuesize. При планировании сети вы можете выбирать, использовать или не использовать очередь, и определять, какого размера ее делать.
В настоящее время очередь прослушивающего процесса поддержива. ется только для протоколов TCP/IP и DECnet. Размер очереди, принимаемый по умолчанию, зависит от операционной системы. Для Solaris и Windows NT 4.0 Workstation это 5, тогда как для Windows NT Server - 20. Когда и как следует использовать очередь и на что влияет ее размер?
Запросы на соединения, получаемые прослушивающим процессом, почти сразу же обрабатываются. Если прослушивающий процесс одновременно получит, скажем, десять запросов, то они будут поставлены в очередь. Эта очередь организована по принципу FIFO (first-in-first-out, "первым пришел — первым ушел"). Максимальное количество записей в очереди определяется параметром queuesize. Если очередь заполнена, то при попытке установить соединение клиент получит сообщение об ошибке ORA-12451: No Listener.
В системах, где возможно одновременное поступление большого числа запросов, увеличение размера очереди позволит накапливать больше необработанных запросов и избежать сообщений ORA-12451.
Будет ли использоваться объединение соединений!
Представьте, что вы читаете увлекательную книгу, а в это время звонит телефон. Вы снимаете трубку и слышите голос своего друга, который хочет узнать, как ваши дела, и заехать в гости. Во время разговора ваш друг, у которого заказана услуга "call waiting" ("ожидание вызова"), слышит сигнал, извещающий о поступлении другого звонка, и просит вас подождать, пока он проверит, кто звонит. Вы возвращаетесь к чтению, а когда ваш собеседник освобождается, продолжаете разговор. Ваш друг мог вести два разных разговора по одной телефонной линии. Подобно этому объединение соединений позволяет процессу диспетчера одновременно обслуживать несколько клиентских соединений. Давайте выясним, что же такое объединение соединений и как оно работает.
Если вы будете использовать многопоточный сервер, то должны принять решение, разрешать или нет объединение соединений. Объединение соединений, подобно ожиданию вызова, позволяет разделять все множество соединений диспетчера между несколькими клиентскими процессами. В результате максимизируется количество физических сетевых соединений с многопоточным сервером. За счет чего это становится возможным? Oracle использует механизм тайм-аута для временного освобождения транспортных соединений, если они остаются неактивными в
течение заданного промежутка времени. Временно освобожденное физическое соединение становится доступным для другого входящего вызова. Логическое соединение с неактивным процессом не освобождается, и
когда процесс возобновляет работу, физическое соединение с диспетчером восстанавливается, подобно тому, как вы продолжаете разговор после возврата вашего друга на линию.
Будет ли использоваться балансировка нагрузки на уровне клиента?
Если у вас есть дети, то вы наверняка знаете, как важно сбалансированно распределить между ними коробку конфет. Если об этом не позаботиться, то каждый ребенок начнет жаловаться, что его обделили. Включая балансировку соединений на уровне клиента, вы обеспечиваете равномерное распределение запросов на соединения между доступными прослушивающими процессами, как если бы вы делили поровну конфеты между своими детьми.

Для объединения соединений необходимо сконфигурировать и задействовать MTS, тогда как балансировка нагрузки на уровне клиента требует наличия нескольких прослушивающих процессов. После того как вы сконфигурируете несколько прослушивающих процессов и включите балансировку нагрузки, установив значение ON для параметра се в файле tnsnames.ora, клиентские запросы будут случайным образом распределяться между прослушивающими процессами, чтобы ни один из них не был загружен больше, чем другие.
В вашем сетевом плане должно быть отмечено, предполагается ли реализовать балансировку нагрузки на уровне клиента, и если да, то сколько прослушивающих процессов будет сконфигурировано для поддержки этой возможности.
Будет ли использоваться отсоединение по таймеру, и если да, то сколько времени процесс может оставаться неактивным!
В ранних версиях сетевых продуктов Oracle соединение могло разрываться на стороне клиента, но сохраняться на стороне сервера. Иными словами, сетевой процесс Oracle не уведомлял сервер Oracle о своем отсоединении. Такая ситуация часто возникала при перезагрузке клиентского ПК. Для клиента соединение разрывалось, но сервер об этом не подозревал. В результате отсоединенные процессы продолжали использовать ресурсы, причем эти процессы порой было очень трудно удалить без останова и перезапуска базы данных или всей операционной системы.
В последующих версиях стало возможным отсоединение по таймеру, то есть обнаружение нерабочих соединений. Если клиент аварийно завершает свою работу, то спустя некоторое время Net8 идентифицирует соединение как "зависшее", после чего инициирует откат незавершенных транзакций и освобождение всех блокировок, удерживавшихся клиентом.
Посмотрим, как происходит отсоединение по таймеру. Периодически, обычно раз в несколько минут, сервер посылает клиенту небольшой пробный пакет. Если все в порядке, то пакет принимается. Если же процесс отсоединился, то операция посылки пакета завершается ошибкой, поскольку пакет некому принять. При возникновении ошибки серверный процесс закрывает соединение и выполняет необходимую очистку.
Чтобы разрешить отсоединение по таймеру, необходимо добавить в файл sqlnet.ora параметр sqlnet.expire_time, указав значение в минутах. Обнаружение нерабочих соединений невозможно при использовании протокола локального обмена.
Если вы решите использовать отсоединение по таймеру, имейте в виду:
•   Генерация пробных пакетов увеличивает сетевой трафик, что может привести к снижению производительности сети.
• В некоторых операционных системах может потребоваться дополнительная обработка, чтобы прослушивающий процесс мог отличить события, связанные с проверкой соединения, от других событий, происходящих при нормальной работе системы. Эта дополнительная обработка также может привести к снижению производительности сети.
 









jAntivirus