Подключения Oracle

Антон Меринов

Антон Меринов

Автор статьи. Интересы, навыки: Профессиональное администрирование СУБД Oracle Database, веб-разработка, IT-World. Подробнее.

 
 
 

Подключения к базе данных OracleВ ранее приведенных примерах дескрипторов и идентификаторов подключений идентификатор подключения sales служил для подключения к службе sales. Идентификатор подключения может быть самим дескриптором подключения или более простым именем (наподобие sales), вместо которого затем подставляется дескриптор подключения. Обычно используемый простой идентификатор подключения называют именем сетевой службы. Таким образом, идентификатор подключения sales в ранее приведенных примерах является именем сетевой службы.

Поскольку указание полного дескриптора подключения при каждой установке подключения является довольно утомительной задачей, применение имен сетевых служб более целесообразно. Однако для этого потребуется поддерживать центральное хранилище всех соответствий между именами сетевых служб и информацией дескрипторов подключений, чтобы Oracle мог проверять актуальность имен сетевых служб. Таким образом, когда пользователь запускает процесс подключения, указывая имя сетевой службы sales, центральное хранилище ищет дескриптор подключения, соответствующий имени sales. Как только дескриптор подключения найден, Oracle Net инициирует подключение к базе данных на указанном сервере.

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

  • Метод локального именования. Этот метод для подключения к серверу базы данных использует файл tnsnames.ora, хранящийся на каждом клиенте.
  • Метод именования простым подключением. Этот метод допускает подключения без какой-либо конфигурации имени службы.
  • Метод внешнего именования. Этот метод использует независимую службу именования для преобразования имен служб.
  • Метод каталожного именования. Этот метод использует LDAP-совместимый сервер для преобразования имен служб.

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

  1. Выберите метод именования — локальный, простое подключение, внешнее именование или именование с помощью службы каталогов.
  2. Отобразите дескрипторы подключений на имена служб.
  3. Сконфигурируйте клиенты, чтобы они использовали метод именования, выбранный на первом шаге.

 

Метод локального именования

Локальное именование — простейший и наиболее легкий способ установки подключения Oracle. При использовании этого метода имена служб и их дескрипторы подключения сохраняются в локальном файле конфигурации tnsnames.ora. По умолчанию этот файл всегда находится в каталоге $ORACLE_HOME/network/admin. Oracle предоставляет для использования образец файла tnsnames.ora, который можно найти в каталоге по умолчанию. ( Файл tnsnames.ora можно считать аналогичным файлу /etc/hosts, который содержит информацию по организации сети в системах UNIX/Linux.) Файл tnsnames.ora всегда присутствует на компьютере клиента. Если сервер базы данных применяется также для установки подключений клиентского типа, он будет содержать файл tnsnames.ora для других баз данных, к которым необходимо подключаться с этого сервера.

При инициализации подключения посредством интерфейса SQL*Plus либо других средств необходимо указать имя пользователя и пароль для той базы данных, к которой осуществляется подключение. Как только это будет сделано, службе Oracle Net придется выяснить, на каком сервере действует база данных, поэтому она обращается к файлу tnsnames.ora для определения сетевого адреса, протокола и порта сервера базы данных. Успешно справившись с этой задачей, она инициализирует соединение со слушателем на том компьютере, где расположен сервер базы данных. После того как слушатель передает подключение серверу базы данных, база данных выполняет аутентификацию имени пользователя и пароля.

После того как подключения сконфигурированы для применения метода локального именования, все подключения к базе данных, выполняются они непосредственно через интерфейс SQL*Plus или через страницу регистрации приложения, будут применять файл tnsnames.ora для преобразования имен служб.

При использовании метода локального именования клиентские компьютеры кроме файла tnsnames.ora используют еще один файл — sqlnet.ora. Этот файл хранится на каждом клиенте и содержит важные параметры сетевой конфигурации. (Естественно, если сервер служит и в качестве клиента, он также будет содержать файл sqlnet.ora.) Использование параметра SQLNET.AUTHENTICATION_SERVICES для конфигурирования аутентификации операционной системы будет описано мною в следующих заметках блога. Типичный файл sqlnet.ora имеет следующий вид: 

# SQLNET.ORA Network Configuration File:
/u01/app/oracle/product/10.1.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DEFAULT_DOMAIN = wowcompany.com
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES)

Обычно файлы конфигурации tnsnames.ora и sqlnet.ora располагаются в каталоге $ORACLE_HOME/network/admin в системах UNIX/Linux и в каталоге $ORACLE_HOME\network\admin в системах Windows. Однако эти файлы можно размещать в любом удобном месте. Если они помещены в каталоге, отличном от заданного по умолчанию, потребуется в переменной среды TNS_ADMIN указать их местоположение. Oracle будет искать эти два файла в следующих местах и воспользуется первым из найденных экземпляров.

  1. В каталоге, указанном в переменной среды TNS_ADMIN.
  2. Поиск файла tnsnames.ora будет выполняться в глобальном каталоге конфигурации. Для систем UNIX/Linux это обычно каталог /var/opt/oracle.
  3. В стандартных сетевых каталогах: $ORACLE_HOME\network\admin в системах UNIX/Linux и в каталоге $ORACLE_HOME\network\admin в системах Windows.

 

Изменение файла tnsnames.ora вручную

Чтобы сконфигурировать метод локального именования, нужно внести изменения в файл tnsnames.ora, предоставленный Oracle при создании базы данных. Для этого достаточно перейти в заданный по умолчанию каталог хранения файла tnsnames.ora, $ORACLE_HOME/network/admin, и отредактировать этот файл, чтобы отразить информацию об именах данной сети и базы данных. При добавлении новой базы данных в систему необходимо также физически добавить отображение имени службы новой базы данных в файл tnsnames.ora каждого пользователя или отправить всем пользователям новый обновленный файл tnsnames.ora, чтобы они заменили им старый файл. В листинге ниже показан типичный файл tnsnames.ora.


 

# TNSNAMES.ORA Network Configuration File:
/u01/app/oracle/product/10.1.0/db_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
finance =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = finance.world)
)
)
salesprod =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.11.150.1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = salesprod.world)
)
)
custprod =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = custprod)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = custprod.world)
)
)

В файле tnsnames.ora, приведенном в листинге выше, перечислены три базы данных, и каждая из них отличается собственными характеристиками. Первая запись — база данных finance, предназначенная для настольного компьютера NTL-ALAPATISAM. База данных salesprod расположена на сервере UNIX с IP-адресом 172.11.150.1, к которому служба Oracle Net может подключаться, используя порт 1521 и протокол TCP. Последняя база данных для обозначения сервера хоста вместо IP-адреса использует символьное имя custprod.

Если бы в этот файл tnsnames.ora нужно было добавить четвертую базу данных orderprod, расположенную на хосте с IP-адресом 172.16.11.151, в файл tnsnames.ora потребовалось бы добавить соответствующий идентификатор подключения, как показано в следующем примере: 

orderprod =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.11.151)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME =orderprod.world)
)

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

  1. Распространите новую конфигурацию имени службы своим клиентам. Это можно выполнить, копируя файлы tnsnames.ora и sqlnet.ora на компьютеры клиентов, на которых должен присутствовать установленный Oracle Client. В качестве альтернативы, для конфигурирования имен сетевых служб на самом клиенте можно воспользоваться помощником Oracle Net8 Assistant или Net8 Configuration Assistant.
  2. Удостоверьтесь, что слушатель запущен на том сервере, где действует база данных. Проверьте, что слушатель использует тот же протокол и адрес, которые были сконфигурированы для имени сетевой службы в файле tnsnames.ora. Убедитесь также, что слушатель использует протокол TCP/IP и прослушивает заданный по умолчанию порт 1521.
  3. Удостоверьтесь, что целевая база данных, к которой вы пытаетесь подключиться, действует.
  4. Протестируйте новое подключение с помощью следующей команды: 
CONNECT имя_пользователя/пароль@имя_сетевой_службы

Хотя локальное именование достаточно просто в реализации, применение этого метода оказывается обременительным при наличии большого количестве клиентских компьютеров, которым требуется непосредственный доступ к серверу баз данных, поскольку в этом случае приходится поддерживать локальные копии файла tnsnames.ora на всех локальных клиентах. Более того, при изменении хостов или добавлении баз данных в систему приходится обеспечивать внесение изменений во все клиентские файлы tnsnames.ora. Естественно, если база клиентов невелика, поддержание файлов tnsnames.ora не должно составлять проблему.

 

Изменение tnsnames.ora с помощью Net Configuration Assistant

Для добавления новой службы в свой файл tnsnames.ora можно отдать предпочтение помощнику Net Configuration Assistant (NCA) Oracle, а не делать все вручную. Подобно файлу listener.ora, файл tnsnames.ora является несколько сложным, учитывая все используемые в нем скобки, и при редактировании его вручную легко допустить ошибку. Создавать новые службы с помощью графического интерфейса пользователя очень просто. Помощник NCA запрашивает имя сервера, имя базы данных, сетевой адрес и тип протокола. По завершении конфигурирования подключения в заданном по умолчанию каталоге появится новый или обновленный файл tnsnames.ora, включающий в себя добавленные службы баз данных.

Чтобы можно было применять NCA, вначале на клиентском компьютере потребуется установить программное обеспечение Oracle Client c компакт-диска Oracle Client CD. NCA поставляется как с серверной, так и с клиентской версией ПО. Создание и тестирование подключения займет пару минут.

Чтобы использовать NCA для конфигурирования нового имени службы в файле tnsnames.ora, нужно выполнить следующие действия.

  1. Запустите на сервере UNIX/Linux помощник Net Configuration Assistant с помощью команды netca, как показано в следующем примере: 
$ export DISPLAY=172.16.14.15:0.0
$ netca

На заметку! В системе Windows помощник NCA запускается выбором команды меню StartProgramsOracle-HOME_NAMEConfiguration and Migration Tools (ПускПрограммыИмя домашнего каталога OracleСредства конфигурирования и переноса).


  1. Откроется страница Welcome (Приветствие). Выберите опцию Local Net Service Name Configuration (Локальная конфигурация имен сетевых служб) и щелкните на кнопке Next (Далее).
  2. На странице Net Service Name Configuration (Конфигурация имен сетевых служб) выберите опцию Add (Добавить) и щелкните на кнопке Next.
  3. На странице Service Name Configuration (Конфигурация имен служб) введите имя службы, которую необходимо сконфигурировать. В данном примере это база данных emrep.netbsa.org. Обратите внимание, что в общем случае имя службы совпадает с глобальным именем базы данных. Щелкните на кнопке Next.
  4. На странице Select Protocol (Выберите протокол) выберите протокол TCP и щелкните на кнопке Next.
  5. На странице TCP/IP Protocol (Протокол TCP/IP) введите имя хоста, на котором действует база данных. Выберите стандартный номер порта, 1521, и щелкните на кнопке Next.
  6. На странице Test (Тестирование) щелкните на кнопке Yes, Perform a Test (Да, выполнить тестирование), а затем щелкните на кнопке Next.
  7. NCA предпримет попытку подключения к базе данных с применением новой конфигурации и отобразит результаты. В случае неудачи подключения удостоверьтесь, что слушатель целевой базы данных запущен, а сочетание имени пользователя и пароля, по умолчанию используемое процессом тестирования (system/manager), изменено на действующее сочетание. Убедитесь также, что имена базы данных и домена указаны правильно.
  8. Затем на странице Net Service Name (Имя сетевой службы) NCA попросит подтвердить имя сетевой службы. Щелкните на кнопке Next.
  9. На странице Another Service Name (Имя другой службы) можно сконфигурировать дополнительные имена служб.
  10. На странице Net Service Name Configuration Done (Конфигурация имени сетевой службы завершена) щелкните на кнопке Next. Когда снова откроется страница Welcome, щелкните на кнопке Finish (Готово).

На заметку! Имена сетевых служб можно конфигурировать и на странице Net Services Administration (Администрирование сетевых служб) в Oracle Enterprise Manager или в графическом интерфейсе пользователя Oracle Net Manager.


 

Метод именования простым подключением

Администраторы БД Oracle могут упростить конфигурирование клиентов, используя метод именования простым подключением. С помощью этого метода клиенты базы данных могут подключаться к ней без применения файла tnsnames.ora в средах TCP/IP. Все что им потребуется — это имя хоста, необязательный номер порта и имя службы базы данных. Таким образом, мы располагаем не требующей конфигурирования и доступной изначально возможностью подключения к любой базе данных в системе по протоколу TCP/IP.

Единственным условием для применения метода именования простого подключения является наличие поддержки протокола TCP/IP как на стороне клиента, так и на стороне сервера. Однако при этом отпадает необходимость в настройке файла tnsnames.ora. Этот новый метод подключения можно рассматривать в качестве расширения метода именования хоста, предложенного в Oracle9i.

Синтаксис применения этого нового метода подключения выглядит следующим образом: 

$ CONNECT имя_пользователя/пароль@[//]хост[:порт][/имя_службы]

В этой синтаксической конструкции следует обратить внимание на четыре описанных ниже элемента.

  • //. Этот элемент не обязателен.
  • хост. Этот параметр обязателен. Можно указать либо символическое имя хоста, либо IP-адрес сервера, на котором расположена целевая база данных.
  • порт. Этот параметр не обязателен. Если порт не указан, по умолчанию используется порт 1521.
  • имя_службы. Этот параметр указывает имя службы базы данных (по умолчанию оно совпадает с именем хоста) и является необязательным. Если имя хоста и имя сервера базы данных идентичны, этот параметр можно опустить. Если же они не совпадают, понадобится указать допустимое имя службы для идентификации базы данных.

Следующий пример демонстрирует результат подключения к базе данных dev1, расположенной на сервере hp50. Подключение осуществляется непосредственно из приглашения операционной системы, поэтому вместо ключевого слова CONNECT используется SQLPLUS:

$ sqlplus system/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.:1521/emrep.netbsa.org
–
SQL*Plus: Release 11.1.0.6.0 - Production on Thu Mar 20 09:38:15 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>

Обратите внимание, что подключение также можно выполнить, не используя необязательный номер порта, как показано в следующем примере:

$ sqlplus system/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript./emrep.netbsa.org

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

(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=ntl_alapatisam.netbsa.org)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=emrep.netbsa.org)))

При подключении из интерфейса SQL*Plus можно применять следующий синтаксис:

$ sqlplus /nolog
SQL*Plus: Release 11.1.0.6.0 - Production on Thu Mar 20 09:38:15 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL> connect system/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.:1521/emrep.netbsa.
org
Connected.
SQL> 

На заметку! Из четырех элементов, которые должны быть указаны при использовании в качестве метода именования простого подключения, обязательным является только имя хоста


 

Конфигурирование именования простым подключением

Как видно из его названия, метод именования простым подключением требует очень мало в плане конфигурирования. Для указания метода простого подключения в качестве значения переменной NAMES.DIRECTORY_PATH в файле sqlnet.ora применяется ключевое слово EZCONNECT. Рассмотрим следующий файл sqlnet.ora

# sqlnet.ora Network Configuration File:
/u01/app/oracle/10.1.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DEFAULT_DOMAIN = netbsa.org
SQLNET.AUTHENTICATION_SERVICES = (NTS)
NAMES.DIRECTORY_PATH = (TNSNAMES,EZCONNECT)

Последняя строка показывает методы подключения, которые служба Oracle Net будет использовать для преобразования идентификаторов подключений в дескрипторы подключений. Параметр NAMES.DIRECTORY_PATH задает порядок, в котором служба Oracle Net будет применять методы именования для преобразования идентификаторов подключений в дескрипторы подключений. В этом примере TNSNAMES является первой настройкой, поэтому Oracle Net будет использовать файл tnsnames.ora по умолчанию. Если ей не удастся подключиться с применением файла tnsnames.ora, она попытается подключиться методом EZCONNECT.

Если требуется, чтобы метод EZCONNECT применялся по умолчанию, можно вручную отредактировать файл sqlnet.ora, переместив значение EZCONNECT на первое место в параметре NAMES.DIRECTORY_PATH

NAMES.DIRECTORY_PATH = (EZCONNECT, TNSNAMES)

 

Ограничения метода именования простым подключением

Ниже перечислены ограничения в применении метода именования простым подключением.

  • На стороне клиента должно быть установлено программное обеспечение Oracle Database 11g Net Services.
  • Поддержка протокола TCP/IP должна быть обеспечена как на стороне клиента, так и на стороне сервера баз данных.
  • Нельзя использовать какие-либо расширенные сетевые функциональные возможности Oracle, вроде поддержки пула соединений, вызовов внешних процедур или гетерогенных служб (Heterogeneous Services).

 

Резидентный пул соединений базы данных Oracle

Вплоть до появления версии Oracle Database 11g для подключения сеансов пользователя к базе данных можно было применять два способа: процесс выделенного сервера, который в каждый момент времени обрабатывает один процесс пользователя, и процесс разделяемого сервера, который обслуживает несколько процессов пользователей. В Oracle Database 11g появился третий способ подключения сеансов к базе данных, который является разновидностью подхода с использованием выделенного сервера и действует на основе концепции использования пула серверов при обслуживании запросов на подключение.

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

Совершенно новый метод подключения с помощью резидентного пула соединений базы данных ( database resident connection pooling — DRCP) использует пулы серверов для обслуживания большого количества сеансов пользователей. Применение DRCP снижает требования к памяти по сравнению с конфигурациями, использующими выделенные и разделяемые серверы.

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

 

Принцип работы DRCP

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

До тех пор пока количество серверов в пуле базы данных не достигло максимального значения, брокер соединений будет создавать сервер в пуле для назначения его новому клиентскому соединению, если не сможет найти свободный сервер в пуле. По достижении максимального количества серверов пула брокер не сможет создавать новые серверы. В этом случае он будет отправлять клиентские подключения в очередь ожидания на освобождение серверов пула. В отличие от подхода с применением выделенного сервера, где используемый объем памяти (PGA) пропорционален количеству сеансов пользователей, при использовании DRCP объем памяти пропорционален числу активных серверов из пула. Следующий пример демонстрирует, как значительно сэкономить память, перейдя от конфигурации с применением выделенного сервера к конфигурации с DRCP.

В этом примере предполагается, что существует 5000 клиентских соединений, и что каждый клиентский сеанс требует 200 Кбайт, а каждый процесс сервера — 5 Мбайт памяти. Кроме того, будем считать, то максимальное количество необходимых серверных соединений равно 200. Общий объем памяти, требуемый для конфигураций с применением выделенного сервера и с применением DRCP можно вычислить следующим образом:

Выделенный сервер
Общий необходимый объем памяти = 5000 × (200 Кбайт + 5 Мбайт) = 260 Гбайт
Резидентный пул соединений базы данных
Общий необходимый объем = 200 (200 Кбайт + 5 Мбайт) = 502 Мбайт
Разделяемый сервер
500 × 200 Кбайт + 200 × 5 Мбайт = 11 Гбайт

Как видите, в то время как конфигурация с выделенным сервером требует 260 Гбайт, для конфигурации с применением DRCP необходимо лишь не многим больше 0,5 Гбайт

 

Активизация и отключение DRCP

По умолчанию база данных изначально конфигурируется с используемым по умолчанию пулом соединений SYS_DEFAULT_CONNECTION_POOL. Однако чтобы воспользоваться преимуществами, предоставляемыми DRCP, потребуется запустить заданный по умолчанию пул соединений. Его запускают с помощью процедуры START_POOL из пакета DBMS_CONNECTION_POOL, как показано в следующем примере: 

SQL> connect sys/sammyy1 as sysdba
SQL> exec dbms_connection_pool.start_pool();
PL/SQL procedure successfully completed.
SQL>

Состояние пула соединений можно проверить с помощью следующего запроса:

SQL> select connection_pool, status, maxsize from dba_cpool_info;
CONNECTION_POOL              STATUS  MAXSIZE
---------------------------  ------  --------
SYS_DEFAULT_CONNECTION_POOL  ACTIVE  80
SQL> 

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

SQL> exec dbms_connection_pool.stop_pool();
PL/SQL procedure successfully completed.
SQL>

Пулом соединений управляет фоновый процесс CMON (Connection Monitor — Монитор соединений). Приложения передают процессы выделенного сервера процессу CMON, который возвращает процесс пулу соединений. DRCP-подключение можно указать следующим образом.

При использовании строки EZ Connect укажите в ней ключевое слово POOLED

myhost.comany.com:1521/mydb.company.com:POOLED

При использовании файла tnsnames.ora укажите параметр SERVER=POOLED в строке подключения TNS:

mydb = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=myhost.company.com)
(SERVER=POOLED)))

 

Конфигурирование DRCP

Для конфигурирования DRCP в базе данных используют следующие параметры. Пул соединений можно конфигурировать в зависимости от требований к применению БД.

Основные параметры конфигурации DRCP перечислены ниже.

  • INACTIVITY TIMEOUT. Максимальное время бездействия, разрешенного помещенного в пул серверу, прежде чем он будет остановлен.
  • MAX_LIFETIME_PER_SESSION. Длительность времени жизни (time to live — TTL) для сеанса, помещенного в пул.
  • MAX_USES_PER_SESSION. Максимальное число раз предоставления помещенного в пул сервера пулу соединений.
  • MAX_SIZE и MIN_SIZE. Максимальное и минимальное количество помещенных в пул серверов в пуле соединений.
  • MAX_THINK_TIME. Максимальное время, в течение которого клиент может оставаться неактивным после получения сервера из пула соединений.

Для одновременной настройки нескольких параметров конфигурации пула соединений можно выполнить процедуру CONFIGURE_POOL из пакета DBMS_CONNECTION_POOL. Чтобы определить значение одного параметра конфигурации пула соединений, можно запустить процедуру ALTER_PARAM из пакета DBMS_CONNECTION_POOL, как показано в следующем примере: 

SQL> exec dbms_connection_pool.alter_param(' ','INACTIVITY_TIMEOUT','2400')

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

Значения параметров конфигурации пула соединений, заданные по умолчанию, можно восстановить, выполняя процедуру RESTORE_DEFAULTS, как показано в следующем примере: 

SQL> exec dbms_connection_pool.restore_defaults()

Процедура RESTORE_DEFAULTS помогает восстановить заданные по умолчанию значения для всех параметров конфигурации пула соединений.

 

Мониторинг DRCP

Для отслеживания работы DRCP используются следующие представления.

  • DB_CPOOL_INFO. Отображает имя пула соединений, его состояние, максимальное и минимальное количества соединений и тайм-аут для бездействующих сеансов
  • V$CPOOL_STAT. Отображает статистические сведения, такие как количество запросов сеансов и время ожидания запросов сеансов.
  • V$CPOOL_CC_STATS. Отображает подробные статистические сведения о соединении на уровне класса.

 

Метод внешнего именования

Для преобразования имен сетевых служб внешний метод именования использует внешние службы именования наподобие Network Information Service (Сетевая информационная служба) (NIS), которая первоначально была разработана компанией Sun Microsystems. Системы NIS содержат центральную базу данных имен хостов и используют двумерное пространство имен, основанное на главном сервере.

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

1. Попросите своего системного администратора сконфигурировать NIS, если это еще не было сделано.

2. Создайте файл tnsnames.ora, как это было бы сделано при использовании метода локального именования.

3. Преобразуйте файл tnsnames.ora в карту tnsnames, которая впоследствии понадобится для сервера NIS. Для извлечения карты tnsnames из файла tnsnames.ora системный администратор должен использовать команду tns2nis, как показано в этом примере: 

# tns2nis tnsnames.ora

4. Скопируйте файл карты связей tnsnames на сервер, на котором действует служба NIS.

5. Установите файл карты tnsnames на сервер NIS, используя NIS-программу makedbm:

# makedbm tnsnames /var/yp/'domainname'/tnsnames 

6. Протестируйте установку карты связей tnsnames в службе NIS с помощью следующей команды:

# ypmatch net_service_name tnsnames 

Вы должны получить подтверждение в следующей форме:

description=(address=(protocol=tcp)
(host=имя_хоста)(port=номер_порта)))
(connect_data=(service_name=имя_службы))) 

7. Отредактируйте файл sqlnet.ora, как показано ниже:

NAMES_DIRECTORY_PATH=(nis, hostname, tnsnames) 

Метод nis должен быть указан первым в скобках, т.к. служба Oracle Net будет пытаться преобразовать имя службы, вначале используя службу NIS. Порядок следования остальных элементов в скобках значения не имеет.

 

Именование с помощью службы каталогов

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

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

Вот несколько примеров видов данных, которыми такие каталоги могут эффективно управлять:

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

Существует много видов доступных коммерческих служб каталогов, в том числе Active Directory от Microsoft и Oracle Internet Directory (OID), и их можно арендовать для выполнения функций хоста для организации.

Метод именования с помощью службы каталогов хранит информацию о соединениях базы данных на сервере каталогов, совместимом с протоколом LDAP (Lightweight Directory Access Protocol — Облегченный протокол доступа к каталогам). Идентификаторы соединений сохраняются в контексте Oracle, который содержит записи, предназначенные для использования с OID.

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

 

Oracle Internet Directory

OID — это LDAP-совместимая служба каталогов, которая, помимо прочего, хранит также идентификаторы соединений. LDAP — популярный протокол доступа к сетевым службам, и он является Интернет-стандартом хранения данных и доступа к каталогам. Служба OID чрезвычайно масштабируема, поскольку она реализована на основе в высшей степени масштабируемой базы данных Oracle. Это позволяет хранить огромный объем информации о каталогах и легко получать к ней доступ. Данные защищены, поскольку они хранятся в базе, а OID является в высшей степени доступной службой, как и база данных Oracle. Спецификация LDAP привлекательна также минимально необходимым объемом клиентского программного обеспечения.

OID можно использовать для многих приложений, таких как адресные книги, хранилища сертификатов безопасности и корпоративные службы каталогов. Компания Oracle настоятельно рекомендует переходить к применению OID в качестве способа конфигурирования соединений баз данных. Путем отхода от Oracle Names (Имена Oracle) — метода подключения, предоставляемого в прошлом — компания Oracle позиционирует OID в качестве основной альтернативы традиционного метода локального именования, который требует использования файла конфигурации сети tnsnames.ora. База данных Oracle может применять OID для хранения имен пользователей и паролей и для хранения верификатора пароля вместе с записью каждого пользователя. Другие компоненты Oracle используют OID в различных целях.

  • Oracle Application Server Single Sign-On (Единый интерфейс входа в сервер приложений Oracle). Применяет OID для хранения записей пользователей.
  • Oracle Collaboration Suite (Пакет для обеспечения сотрудничества Oracle). Использует OID для осуществления централизованного управления информацией о пользователях и группах.
  • Oracle Net Services (Сетевые службы Oracle). Пользуется OID для хранения и преобразования имен служб базы данных и сетевых служб.
  • Oracle Advanced Security (Расширенная служба безопасности Oracle). Использует OID для централизованного управления аутентификационными мандатами пользователей, авторизацией, преобразованиями в схему совместного использования, аутентификацией посредством единственного пароля, безопасностью пользователей предприятия и центральным хранилищем мандатов инфраструктуры PKI (Public Key Infrastructure — инфраструктура открытых ключей).

OID включает в себя следующие элементы.

  • Oracle directory server (Сервер каталогов Oracle). Предоставляет имена служб и другую информацию, используя при этом многоуровневую архитектуру поверх стека протоколов TCP/IP.
  • Oracle directory replication server (Сервер репликации каталогов Oracle). Реплицирует данные LDAP между серверами каталогов Oracle.
  • Средства администрирования каталогов, в том числе:
  • Oracle Directory Manager (Диспетчер каталогов Oracle), графический интерфейс пользователя, который облегчает администрирование OID, и другие утилиты администрирования на основе командной строки;
  • средства управления сервером каталогов, входящие в состав консоли Application Server Control (Управление сервером приложений) Oracle Enterprise Manager 10g, которые позволяют отслеживать события реального времени из веб-браузера.

Основная идея применения OID проста. Пользователи подключаются к OID, который является приложением, действующим в базе данных Oracle. Пользователи предоставляют OID идентификатор службы Oracle (имя базы данных). Каталог возвращает полную информацию о соединении — имя хоста, протокол подключения, номер порта и имя экземпляра базы данных — клиенту, который затем подключается к серверу базы данных. Идентификаторы соединений хранятся в контексте Oracle, который содержит такие записи, как имена баз данных и служб, предназначенные для использования с программным обеспечением Oracle, подобным OID.

Функция Advanced Security Oracle использует OID для централизованного управления информацией, связанной с пользователями. При использовании технологии реплицированной базы данных каталог Oracle OID будет весьма полезным в плане преодоления сложностей, связанных с использованием нескольких серверов и сетевых протоколов.

Хотя компания Oracle предпочла бы, чтобы все сетевые конфигурации были преобразованы в OID, это совершенно не означает, что предоставляемые этой службой преимущества окупают дополнительные накладные расходы для большинства небольших или средних предприятий. Помните, что OID не является продуктом, предназначенным исключительно для конфигурирования сети. Сетевые соединения базы данных — лишь небольшая часть возможностей OID. Подход локального именования (или новый метод именования простым подключением) благодаря своей простоте по-прежнему остается удобным для большинства организаций.

 

Как OID осуществляет подключения к базам данных

При использовании OID для преобразования имен следует помнить, что клиент не располагает файлом, таким как tnsnames.ora, содержащим информацию о преобразовании. При использовании именования с помощью службы каталогов клиенты Net Services подключаются к базе данных следующим образом.

  1. Лицо, которое желает выполнить подключение, вводит на клиентском компьютере свое обычное сочетание имени пользователя/пароля и идентификатор соединения.
  2. Файл sqlnet.ora на компьютере клиента указывает, что он использует OID для преобразования имен, поэтому клиент Net Services передает свой запрос процессу слушателя/диспетчера OID.
  3. Слушатель/диспетчер OID передает запрос LDAP серверу каталогов Oracle.
  4. Сервер каталогов подключается к базе данных OID и преобразует идентификатор соединения в соответствующий дескриптор соединения, который содержит информацию о сети, сервере и протоколе. Затем он отправляет эту подробную информацию дескриптора соединения клиенту Net Services.
  5. Клиент отправляет полученный дескриптор соединения службе слушателя Oracle Net Listener (или диспетчеру, если используются разделяемые серверы).
  6. Служба слушателя принимает запрос на подключение и, после его проверки, пересылает базе данных.

 

Организация OID

Каталог содержит набор сведений о различных объектах, таких как имена и адреса сотрудников или информацию об именах служб баз данных . Информация в каталоге организована в виде иерархической структуры, получившей название DIT (Directory Information Tree — Дерево информации каталога). Каждая запись каталога образуется из различных объектных классов и атрибутов следующим образом:

  • каталоги образуются из объектных классов;
  • объектные классы — это группы атрибутов;
  • атрибуты представляют собой контейнеры, содержащие данные.

Каталог состоит из записей, которые представляют собой коллекции информации об объекте. Для однозначной идентификации записи требуется какое-либо средство для указания ее местоположения в структуре каталога. Этим однозначным локатором адреса является отличительное имя (distinguished name — DN) записи. DN подобно адресу, который точно указывает местоположение записи в каталоге — оно предоставляет полный путь от вершины иерархии до местоположения записи.

Ниже приведен пример DN: 

cn=nina
ou=finance
c=us
o=wowcompany 

Это DN записи nina содержит следующие узлы:

  • cn — общее имя (common name);
  • ou — организационная единица (organizational unit);
  • c — страна (country);
  • o — организация (organization).

Таким образом, DN-имя nina.finance.us.wowcompany уникальным образом определяет лицо с именем Nina, которое работает в финансовом отделе (finance) филиала в США (US) компании Wowcompany. Обратите внимание, что каждый из отдельных узлов называют относительными отличительными именами (relative distinguished names — RDN), поэтому, по сути, DN — это всего лишь строка имен RDN.

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

Oracle Net Service и безопасность пользователя предприятия. Один сервер каталогов может содержать несколько контекстов Oracle. OID создаст заданный по умолчанию контекст Oracle в корне дерева информации каталога. В дереве DIT контекст Oracle RDN (cn=OracleContext) является местоположением по умолчанию, которое клиенты применяют для поиска в каталоге соответствующих дескрипторов соединений для указанных идентификаторов соединений.

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

Административный контекст, называемый также контекстом именования с помощью каталогов, — это запись каталога, которая содержит контекст Oracle. Следующий простой пример демонстрирует эти несколько запутанные понятия.

Полное имя DN для базы данных orcl выглядит так: 

dc=com,dc=wowcompany
cn=orcl,
cn=description,
cn=address,
cn=port,
cn=service_name

В записи DN dc означает domain component (компонент домена) и обычно используется для описания элементов доменов в каталоге.

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

dc=com,dc=wowcompany,cn=OracleContext

Обратите внимание, что dc определяет компонент домена, а cn означает общее имя (common name). В этом примере и com, и wowcompany — компоненты домена, поэтому они расположены в верхней части дерева каталога.

 

Инсталляция OID

OID можно установить с применением программного обеспечения сервера приложений Oracle Application Server 10g Release 2 (10.1.2.0.0). При использовании универсального инсталлятора Oracle в окне Select a Product to Install (Выберите продукт для установки) потребуется выбрать опцию Oracle AS Infrastructure 10g (Инфраструктура сервера приложений Oracle 10g). Эта опция позволяет установить новую службу OID на сервер. На следующей странице универсального инсталлятора Oracle — Select Installation Type (Выберите тип установки) — выберите опцию Identify Management and Metadata Repository (Управление идентификацией и хранилище метаданных). Она создает хранилище метаданных Metadata Repository, существование которого обязательно для инсталляции OID.

Рассмотрение установки и управления OID выходит за рамки настоящей книги. За более подробной информацией обращайтесь к документации Oracle Application Server Release 2 на веб-сайте http://technet.oracle.com.

Как только служба OID будет сконфигурирована, можно приступать к вводу в этот каталог имен сетевых служб. Для этого применяется несколько методов. Проще всего добавлять имена служб в Oracle Net Manager, если записи добавляются индивидуально, или же импортировать в OID весь файл tnsnames.ora, используя Oracle Enterprise Manager.

Вас заинтересует / Intresting for you:

Обновление до Oracle Database ...
Обновление до Oracle Database ... 5524 просмотров Илья Дергунов Tue, 21 Nov 2017, 13:18:05
Видеокурс по администрированию...
Видеокурс по администрированию... 10579 просмотров Илья Дергунов Mon, 14 May 2018, 05:08:47
Поддерживаемые Oracle типы дан...
Поддерживаемые Oracle типы дан... 5724 просмотров Валерий Павлюков Wed, 24 Oct 2018, 08:00:37
Создание базы данных Oracle
Создание базы данных Oracle 18945 просмотров Александров Попков Wed, 14 Nov 2018, 12:44:39
Войдите чтобы комментировать

Oracle_Admin аватар
Oracle_Admin ответил в теме #8951 07 март 2018 05:12
Сверх подробный мануал по настройке tnsnames.ora и методах подключения к СУБД Oracle! Спасибо.