Работа в сети - Oracle Net

Oracle Net Service – набор сетевых компонент для сетей корпоративного масштаба распределенных, гетерогенных сред. Oracle Net Service включает в себя Oracle Net, listener, Oracle Connection Manager, Oracle Net Configuration Assistant и Oracle Net Manager.

Oracle Net – важнейшая составляющая Oracle Net Service, позволяющая пользовательским приложениями присоединяться к БД.

Listener – приложение или процесс прослушивания, часть Oracle Net (как правило, существует как отдельный процесс или служба ОС). Предназначен для первичной обработки запросов пользовательских сессий на соединение с БД. Настраивается на определенные порты определенных сетевых протоколов (по умолчанию используется протокол TCP/IP и порт 1521).

Oracle Connection Manager – «маршрутизатор» для поддержки большого (десятки тысяч) количества пользовательских сессий. Работает в режиме разделяемых серверов. Часто используется для работы через брандмауэр (firewall).

Oracle Net Configuration Assistant – графическая утилита, позволяющая осуществлять первичную (часто достаточную) настройку базовых сетевых компонент:

- Процесса прослушивания;

- Методов разрешения сетевых имен;

- Имен сетевых сервисов в tnsnames.ora.

- Сервера директорий.

Oracle Net Manager – более мощная по сравнению с Oracle Net Configuration Assistant графическая утилита, объединяющая в себе возможности управления практически всеми компонентами Oracle Net.

Архитектура Oracle Net Services

Сервер БД призван обеспечить выполнение запросов пользователей, обращающихся к нему с клиентских компьютеров. На него ложится основная вычислительная нагрузка, он должен обеспечить потребности клиентских приложений в вычислительных ресурсах (процессорное время, память, операции ввода/вывода и т.д.).

Подобным образом реализуется т.н. конфигурация «клиент-сервер» (еще ее называются двухуровневой). При этом к компьютеру клиента предъявляются также достаточно высокие аппаратные требования, ведь он должен обеспечить функционирование приложения. О таком клиенте часто говорят как о «толстом» (fat client).

Помимо двухуровневой, с развитием веб-технологий появилась и все больше и больше применяется трехуровневая конфигурация с использованием «тонкого» клиента (thin client). Третьим звеном в данной архитектуре является сервер приложений, стоящий теперь между клиентским компьютером и сервером БД. Он призван хранить и обрабатывать всю логику приложения. К клиентскому программному обеспечению требования становятся очень низки, и очень часто его роль выполняет обычный Интернет-браузер.

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

Oracle Net позволяет реализовать все эти конфигурации сетевого взаимодействия.

Основное назначение Oracle Net – установление и поддержка соединений между пользовательскими приложениями и БД. Oracle Net состоит из нескольких уровней, что позволяет клиентам и серверу БД работать с данными.

Рис. Уровни взаимодействия в сетевой архитектуре СУБД Oracle 10g

- Client Application – уровень клиентского приложения;

- Presentation - уровень представления;

- Oracle Net Foundation Layer – базовый сетевой уровень (уровень TNS);

- Oracle Protocol Support – уровень поддержки протоколов;

- Network Protocol - уровень сетевых протоколов;

- RDBMS - уровень РСУБД.

Уровень клиентского приложения

Клиенты во время работы с БД используют библиотеки Oracle Call Interface (OCI), назначение которых – обеспечить взаимодействие между приложением клиента и движком SQL БД.

Уровень представления

В случае, когда клиент и БД работают под управлением разных ОС, может возникнуть ситуация, когда у БД и у клиента отличаются наборы символов. Уровень представления разрешает подобные проблемы, в случае необходимости выполняя конвертацию. Этот уровень еще называют Two-Task Common (TTC).

Базовый сетевой уровень

Этот уровень отвечает за установление и поддержку соединения между приложением клиента и сервером БД, помимо этого обеспечивая обмен сообщениями между ними.

Это становится возможным благодаря использованию давно известной в Oracle технологии прозрачной сетевой среды – Transparent Network Substrate (TNS).Эта технология обеспечивает общий интерфейс для всех распространенных протоколов. Другими словами, два компьютера (работающие под управлением разных ОС, использующих разные протоколы) могут связаться напрямую без дополнительных промежуточных устройств.

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

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

Уровень поддержки протоколов

Передает данные о соединении с базового сетевого уровня (TNS) на уровень сетевых протоколов. Используются наиболее распространенные на сегодняшний день:

- TCP/IP;

- TCP/IP с поддержкой SSL (TCPS);

- Именованные каналы (Named Pipes).

Уровень сетевых протоколов

Отвечает за передачу данных от компьютера к компьютеру, от клиента серверу БД и в обратном направлении в сетевой интранет или интернет-среде.

TCP/IP – The Transmission Control Protocol/Internet Protocol (TCP/IP), стандартный коммуникационный протокол.

TCP/IP с поддержкой SSL – обеспечивает защищенную передачу данных между клиентом и сервером БД (более подробно это можно узнать в документации – глава Oracle Advanced Security Administrator’s Guide).

Именованные каналы (named pipes) – высокоуровневый сетевой интерфейс, обеспечивающих межпроцессное взаимодействие в распределенных приложениях между клиентами и сервером БД. На серверной стороне создается канал (pipe) и клиенты обращаются к нему по имени.

Уровень РСУБД

Данные, передаваемые от клиентского приложения через уровни сетевой структуры проходят подобную же иерархию уровней и на стороне сервера (см. рисунок «Уровни взаимодействия в сетевой архитектуре СУБД Oracle 10g»), естественно, в обратном направлении. Только вместо OCI, сервер БД использует Oracle Program Interface (OPI). OPI – часть OCI, поэтому на каждый запрос, сформированный с помощью OCI, OPI возвращает необходимые данные.

Процесс прослушивания (listener)

Как уже упоминалось, запросы клиентских приложений на соединение первым обрабатывает процесс прослушивания. Он действует между базовым сетевым уровнем и уровнем РСУБД. Если этот начальный запрос содержит корректные для текущей БД данные, процесс прослушивания «допускает» клиентское приложение на связь с БД. Один процесс прослушивания может обслуживать несколько экземпляров БД, или точнее, сервисов БД (определяемых параметром инициализации SERVICE_NAMES).

Каждый процесс прослушивания имеет одну или более точек прослушивания, которые описываются как сетевой адрес (protocol address) в терминах выбранного протокола.

Например, если процесс прослушивания работает с протоколом TCP/IP, описание подобной точки прослушивания включает имя протокола, имя (или IP-адрес) хоста и порт, который «прослушивается» листенером. Ниже пример строки из конфигурационного файла listener.ora с описанием точки прослушивания.

(ADDRESS = (PROTOCOL = TCP)(HOST = sergeysv)(PORT = 1521)

Клиент, посылающий запрос на соединение с БД, должен использовать это адрес для установления соединения.

Если он принимается процессом прослушивания, тот, обращаясь к фоновому процессу PMON соответствующего экземпляра, получает информацию для регистрации в конкретной БД:

· Имя сервиса БД, к которой осуществляется подключение (определяется параметром инициализации SERVICE_NAMES);

· Имя экземпляра(ов), связанного с соответствующим сервисом;

· Тип соединения (выделенные процессы или диспетчер + разделяемые сервера).

Основываясь на этих данных, и происходит создание пользовательской сессии для приложения клиента.

В случае подключения в режиме выделенного сервера процесс прослушивания автоматически запустит отдельный сервер для сессии. На уровне ОС происходит создание нового процеса (Unix, Linux), либо потока (Windows) для создаваемой сессии. Теперь запрос клиента «перенаправляется» на созданный процесс (или поток) и тем самым обеспечивается физическое подключение.

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

Ниже представлен пример файла настройки процесса прослушивания listener.ora. Подобный файл всегда есть на стороне сервера БД. Файлы сетевой конфигурации (не только listener.ora), как правило, располагаются по адресу: $ORACLE_HOME/network/admin. Этот путь также часто хранится в переменной окружения TNS_ADMIN, если она установлена.

# listener.ora Network Configuration File: C: \oracle\product\10.2.0\db_1\NETWORK\ADMIN\listener.ora

# Generated by Oracle configuration tools.

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = test10g)

(SID_NAME = test10g)

)

)

LISTENER =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = sergeysv)(PORT = 1521))

)

SID_LIST_LISTENER – параграф описания сервисов, с которыми работает процесс прослушивания. Здесь указываются:

- SID_NAME – имя экземпляра БД (см. параметр инициализации INSTANCE_NAME).

- GLOBAL_DBNAME – глобальное имя БД, как правило, состоящее из имени БД и домена БД (см. параметры инициализации DB_NAME, DB_DOMAIN, SERVICE_NAMES).

- ORACLE_HOME – необязательный параметр, указывающий местоположение домашней директории сервера БД.

Настройка соединения с БД

Процесс настройки сетевого соединения компьютера с БД включает выполнение предварительных следующих условий:

На стороне сервера убедиться в том, что:

- Существует БД Oracle и находится в рабочем состоянии;

- Установлена поддержка необходимых протоколов (например, TCP/IP)

- Настроен процесс прослушивания.

На компьютере клиента убедиться в том, что:

- Компьютер клиента находится в той же сети, что и сервер БД;

- Установлен Oracle Client;

- Установлена поддержка необходимых протоколов.

Для того, чтобы убедиться, что между сервером БД и компьютером клиента может быть установлено соединение, т.е. они находятся в одной и той же сети, можно использовать утилиту PING ОС. Для ее использования необходимо знать либо IP-адрес компьютера, с которым тестируется соединение, либо его имя. Например,

c: \oracle\admin\test10g\scripts> ping sergeysv

Pinging sergeysv.sun.usethelink.com [192.168.4.124] with 32 bytes of data:

Reply from 192.168.4.124: bytes=32 time< 1ms TTL=128

Reply from 192.168.4.124: bytes=32 time< 1ms TTL=128

Reply from 192.168.4.124: bytes=32 time< 1ms TTL=128

Reply from 192.168.4.124: bytes=32 time< 1ms TTL=128

Для управления процессом прослушивания существует утилита lsnrctl (Listener Control). Основные команды – START, STOP, STATUS, SERVICES. Например,

c: \oracle\admin\test10g\scripts> lsnrctl

LSNRCTL> status

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sergeysv)(PORT=1521)))

TNS-12541: TNS: no listener

TNS-12560: TNS: protocol adapter error

TNS-00511: No listener

32-bit Windows Error: 61: Unknown error

Фраза «no listener» говорит о том, что процесс прослушивания не запущен в нормальном режиме. Запуск осуществляется с помощью команды START:

LSNRCTL> start

Starting tnslsnr: please wait...

TNSLSNR for 32-bit Windows: Version 10.2.0.1.0 - Production

System parameter file is C: \oracle\product\10.2.0\db_1\network\admin\listener.ora

Log messages written to C: \oracle\product\10.2.0\db_1\network\log\listener.log

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sergeysv.sun.usethelink.com)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sergeysv)(PORT=1521)))

STATUS of the LISTENER

------------------------

Alias LISTENER

Version TNSLSNR for 32-bit Windows: Version 10.2.0.1.0 - Production

Start Date 22-NOV-2007 15: 31: 01

Uptime 0 days 0 hr. 0 min. 1 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File C: \oracle\product\10.2.0\db_1\network\admin\listener.o

ra

Listener Log File C: \oracle\product\10.2.0\db_1\network\log\listener.log

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sergeysv.sun.usethelink.com)(PORT=1521)))

Services Summary...

Service " test10g" has 2 instance(s).

Instance " test10g", status UNKNOWN, has 1 handler(s) for this service...

Instance " test10g", status READY, has 1 handler(s) for this service...

Service " test10gXDB" has 1 instance(s).

Instance " test10g", status READY, has 1 handler(s) for this service...

Service " test10g_XPT" has 1 instance(s).

Instance " test10g", status READY, has 1 handler(s) for this service...

The command completed successfully

Перечислены параметры процесса прослушивания, в т.ч. сервисы, обслуживаемые им.

Типовая настройка сетевого соединения с помощью Net Configuration Assistant

Управление соединением с БД обеспечивается в Oracle Net с помощью конфигурационных файлов на стороне клиента и сервера. Расположение этих файлов, как правило, используется по умолчанию и хранится в переменной окружения TNS_ADMIN (если она используется), и, в большинстве случаев следующее: %ORACLE_HOME%\network\admin.

Для настройки сетевых соединений с сервером СУБД Oracle 10gрекомендуется использовать утилиту Net Configuration Assistant, первый рабочий экран которой представлен на рис. «Настройка сетевого соединения, рис. 1». Запуск утилиты осуществляется через меню «Программы-> Oracle - OraDb10g_home1 -> Configuration and Migration Tools -> Net Configuration Assistant». Каждый раз, когда запускается эта утилита, происходит сохранение резервной копии предыдущего файла tnsnames.ora.

Для начала определимся с методами разрешения сетевых имен (Naming Methods configuration).

Настройка сетевого соединения, рис. 1

По умолчанию (и в большинстве интранет-систем) используется локальное (с использованием файла tnsnames.ora на стороне клиента) разрешение имен. См. «Настройка сетевого соединения, рис. 2».

Настройка сетевого соединения, рис. 2

Вернувшись на главный экран, выберем пункт настройки локальных сетевых имени (Local Net Service configuration). На следующем экране – «Настройка сетевого соединения, рис. 3», выберем необходимое действие настройки, в данном случае – создание нового подключения «Add».

Настройка сетевого соединения, рис. 3

На экране «Настройка сетевого соединения, рис. 4» указываем версию СУБД Oracle, к которой осуществляется соединение.

Настройка сетевого соединения, рис. 4

На экране «Настройка сетевого соединения, рис. 5» необходимо указать имя сервиса БД, к которой мы хотим присоединиться. Это имя должно совпадать со значением параметра БД SERVICE_NAMES.

Настройка сетевого соединения, рис. 5

Далее происходит указание протокола для сетевого взаимодействия. Как правило, в большинстве случаев используется протокол TCP/IP. Если вы хотите использовать другой, выясните, настроена ли в БД его поддержка.

Настройка сетевого соединения, рис. 6

На экране «Настройка сетевого соединения, рис. 7» необходимо указать параметры хоста, где установлена и работает БД. Если клиентский компьютер и компьютер сервера БД находятся в одной сети (и, например, домене), можно указать имя компьютера в сети. Иначе указывается IP-адрес хоста. При указании порта будьте уверены, что именно этот порт используется процессом прослушивания на стороне БД.

Настройка сетевого соединения, рис. 7

На следующем экране предлагается протестировать настроенное соединение. Оно должно осуществляться с помощью учетной записи (имени пользователя и пароля), уже существующего в БД.

Настройка сетевого соединения, рис. 8

После тестирования необходимо указать имя сетевого сервиса, которое будет указываться при соединении с БД. Оно будет заголовком параграфа в файле tnsnames.ora, который описывает это соединение.

Настройка сетевого соединения, рис. 9

На этом стандартный случай настройки сетевого соединения клиента с сервером БД с помощью утилиты Net Configuration Assistant закончен. Осталось сохранить результаты настройки.

Настройка сетевого соединения, рис. 10

Для того, чтобы настройка была записана в файл tnsnames.ora необходимо обязательно подтвердить сохранение, нажав на кнопку «Готово».

Настройка сетевого соединения, рис. 11

После окончания настройки в файле tnsnames.ora появится новый параграф примерно следующего вида (добавилось имя домена):

TEST10G =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = sergeysv)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = test10g)

)

)

Общий вид файла tnsnames.ora:

# tnsnames.ora Network Configuration File: C: \oracle\product\10.2.0\db_1\NETWORK\ADMIN\tnsnames.ora

# Generated by Oracle configuration tools.

TEST10G =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = sergeysv)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = test10g)

)

)

Параметры, следующие после названия сетевого сервиса, составляют т.н. дескриптор соединения (connection descriptor). В нем указывается используемый для соединения протокол, имя сервера (хоста), имя экземпляра БД. Имя сетевого сервиса скрывает за собой все эти параметры, и, указав при соединении лишь его, мы передаем параметры дескриптора процессу прослушивания БД. Имя сетевого сервиса может быть производльным, нет никакой необходимости, чтобы оно совпадало с именем экземпляра, как предлагает по умолчанию NETCA.

Теперь для того, чтобы присоединиться к БД с помощью настроенного соединения, пользователь может сделать это с помощью, например, SQL*Plus.

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Nov 22 15: 35: 15 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Enter password:

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

SQL>

Итак, соединение успешно установлено.

Настройка OSS (MTS)

В режиме OSS пользователи в итоге соединяются напрямую с процессом диспетчера. Фоновый процесс PMON определяет настройки процессов-диспетчеров и запускает их, связывая их с процессом прослушивания (listener) таким образом, что запрос пользователя на соединение с БД сначала поступает на процесс прослушивания, затем (зная сетевые атрибуты всех диспетчеров) процесс прослушивания передает атрибуты процесса-диспетчера пользовательской сессии.

Рис. Режимы работы сервера БД

Назначение процесса-диспетчера – получение входящих запросов от пользователей и размещение их в очереди запросов, располагаемой в SGA. Диспетчер также постоянно следит за второй очередью – очередью ответов, и передает результаты выполнения запросов пользовательским сессиям. Выполнение самих запросов осуществляют разделяемые серверные процессы.

Чтобы активизировать режим OSS, необходимо:

- Настроить и запустить процесс прослушивания пользовательских запросов (listener).

- Установить требуемые параметры инициализации для работы процессов-диспетчеров и собственно разделяемых серверных процессов.

Параметры инициализации, отвечающие за работу OSS:

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

Т.о. сокращается число одновременно работающих процессов СУБД Oracle 10g, а заодно и потоков ОС.

Число процессов-диспетчеров, запускаемых вместе со стартом экземпляра, определяется значением параметра DISPATCHERS в файле параметров инициализации. Чтобы описать n диспетчеров с разными параметрами, необходимо прописать параметр DISPATCHERS в файле параметров n раз, причем строки с описаниями диспетчеров должны следовать строго друг за другом. Описать несколько диспетчеров с одинаковыми параметрам можно одним параметром DISPATCHERS с опцией (DISPATCHERS= n).

Позже, при необходимости, можно добавлять или удалять диспетчеры без перезапуска экземпляра с помощью команды ALTER SYSTEM. Число процессов-диспетчеров не может превышать значение параметра MAX_DISPATCHERS.

Соотношение «1 диспетчер на 1000 соединений» в общем случае подходит для большинства систем. Большое число диспетчеров может привести к снижению производительности по причине увеличения ресурсо-затрат на их поддержку в системе.

Диспетчеры работают в тесной связи с процессом прослушивания (listener), поэтому в этом контексте выделяют т.н. «конечную точку прослушивания» (endpoint), которая дает точный сетевой адрес диспетчера (конкретного экземпляра), по которому можно осуществить соединение.

Параметр DISPATCHERS имеет строковый вид. Он может состоять из двух частей: описания сетевых атрибутов и опций диспетчеров.

Например, DISPATCHERS = " (PROTOCOL=TCP)(DISPATCHERS=3)".

- PROTOCOL (PRO или PROT) – сетевой протокол, по которому диспетчер работает (обычно TCP/IP).

- ADDRESS (ADD или ADDR) – сетевой адрес конечной точки прослушивания, включающий в себя описание протокола, порта протокола или хоста сервера, где работает диспетчер (Oracle Net может автоматически назначать порт для TCP/IP протокола).

- DESCRIPTION (DES или DESC) – описание сетевого местонахождения точки прослушивания, включая настройки протокола.

Опции диспетчеров:

- DISPATCHERS (DIS или DISP) – число процессов-диспетчеров, создаваемых сразу при старте экземпляра (по умолчанию 1).

- SESSIONS (SES или SESS) – максимальное число сессий, которое может поддерживать один диспетчер (зависит от ОС, как правило - 16384).

- CONNECTIONS (CON или CONN) – максимальное число сетевых соединений на каждый процесс-диспетчер (зависит от ОС, в Windows - 1024).

- TICKS (TIC или TICK) – длина такта сетевой операции (в секундах, по умолчанию 15 сек.).

- POOL (POO) – включение пула соединений. По умолчанию выключен. При количестве одновременно работающих пользователей в несколько тысяч можно включать (также необходимо в этом случае настроить атрибуты CONNECTIONS и SESSIONS).

- MULTIPLEX (MUL или MULT) – позволяет задействовать Oracle Connection Manager, также позволяющий поддерживать большое число сессий через малое число соединений.

- LISTENER (LIS, LIST) – настройки процесса(ов) прослушивания (listener’a) для работы диспетчеров. Рекомендуется использовать в системах с несколькими домашними директориями.

- SERVICE (SER, SERV) – сервисы, с которыми работают диспетчеры через процессы прослушивания.

- INDEX – используется, если описывается несколько процессов-диспетчеров. При дальнейшей модификации параметров диспетчеров с помощью команды ALTER SYSTEM SET DISPATCHERS можно указать, в какой именно из процессов-диспетчеров будут вноситься изменения. INDEX указывает порядковый номер процесса-диспетчера, начиная с 0. Например, если вы создали в системе 3 диспетчера, вы можете модифицировать третий из них с помощью команды ALTER SYSTEM SET DISPATCHERS … INDEX 2.

Примеры настройки параметра DISPATCHERS:

Типовое значение:

Создание двух процессов-диспетчеров с явное указание IP-адреса хоста, где запущен экземпляр:

Параметр SHARED_SERVERS описывает число процессов разделяемых серверов, которые создаются вместе со стартом экземпляра. Oracle динамически регулирует число разделяемых серверных процессов исходя из длины очереди запросов. Число работающих разделяемых серверных процессов лежит в диапазоне между значением параметра SHARED_SERVERS и значением параметра MAX_SHARED_SERVERS. По оценкам, один разделяемый серверный процесс создается примерно на десять соединений. Для OLTP-систем один разделяемый серверный процесс может обслуживать и большее число соединений.

Параметр MAX_SHARED_SERVERS должен иметь приемлемое значение, зависящее от прогнозируемой нагрузки и типа приложения.

Замечание:

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

Параметр MAX_SHARED_SERVERS – статический, не может быть изменен без перезапуска экземпляра. Но параметр SHARED_SERVERS – динамический, и может быть изменен с помощью команды ALTER SYSTEM.

При необходимости, в системе можно добавлять, либо удалять процессы-диспетчеры без перезапуска экземпляра. По данным из представлений словаря данных V$QUEUE, V$DISPATCHER, V$DISPATCHER_RATE можно сделать выводы о чрезмерной загрузке, либо о простое процессов диспетчеров. Тогда используется команда ALTER SYSTEM.

Например, в нижеследующем примере динамически изменяется число процессов-диспетчеров для протокола TCP/IP (число их устанавливается равным 5). Если текущее число диспетчеров менее 5, создаются новые, если же диспетчеров больше 5 – останавливаются лишние.

Ключевое слова INDEX может быть использовано в случае использования нескольких диспетчеров для указания диспетчера, над которым(и) проводится операция. Если в команде ALTER SYSTEM вы укажете индекс больший, чем текущее число диспетчеров, будет добавлен новый процесс(ы). В предыдущем примере все 5 диспетчеров будут иметь индекс 0.

Уточняющая информация по индексам диспетчеров находится в столбце CONF_INDX представления словаря данных V$DISPATCHER.

Следует отметить, что удаляемый процесс-диспетчер не останавливается сразу: на момент выдачи команды он может обслуживать пользовательские сессии. Как только пользовательские сессии, которые он обслуживает, завершат работу, он будет остановлен.

Правда, существует возможность остановить процесс диспетчера, не дожидаясь отсоединения всех использующих его сессий. Это можно сделать с помощью команды ALTER SYSTEM SHUTDOWN IMMEDIATE ‘Dnnn’, где ‘Dnnn’ – имя процесса-диспетчера, который нужно остановить. Его можно выяснить, обратившись к представлению словаря данных v$dispatcher (столбец NAME). В этом случае пользовательские сессии, связанные с останавливаемым диспетчером, будут завершены принудительно.

После старта экземпляра можно изменять минимальное число одновременно работающих серверных разделяемых процессов (ALTER SYSTEM SET SHARED_SERVERS = < число >).

Установка параметра SHARED_SERVERS в 0 – эффективный способ отключить работу OSS.

Работа с выделенными и разделяемыми серверами одновременно

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

Необходимо на стороне клиента настроить два сетевых соединения (прописать в TNSNAMES.ORA). Первое – для работы в режиме выделенного сервера, и второй – для работы в режиме разделяемых серверов. Для этого в TNSNAMES.ORA в разделе описания сервиса экземпляра необходимо указать дополнительный параметр SERVER:

(SERVER = DEDICATED) – для выделенного подключения;

(SERVER = SHARED) – для подключения в режиме OSS.

Например, как это могло бы быть:

SQL> connect sys@OSS as sysdba

Connected.

SQL> shutdown immediate

ORA-00106: cannot startup/shutdown database when connected to a dispatcher

Ошибка, потому что соединение было в режиме OSS.

SQL> connect sys@OSS_d as sysdba

Connected.

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 101785252 bytes

Fixed Size 454308 bytes

Variable Size 75497472 bytes

Database Buffers 25165824 bytes

Redo Buffers 667648 bytes

Database mounted.

Database opened.

SQL> spool off

Фрагмент tnsnames.ora:

OSS_D =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = asaev)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = OSS)

(SERVER = DEDICATED)

)

)

OSS =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = asaev)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = OSS)

(SERVER = SHARED)

)

)