Владимир Пржиялковский,
преподаватель УКЦ Interface Ltd.

• Слово об именах
• Архитектура соединения с Oracle
• Журнализация и трассировка
• Включение трассировки клиентской компоненты Net8
• Включение трассировки серверной компоненты Net8
• Включение трассировки слухача
• Замечания по использованию

Можно без натяжек утверждать, что большая часть соединений с СУБД Oracle выполняется через сеть. Не все согласятся, что соединение по сети входит в тематику баз данных, но то, что администрирование таких подсоединений составляет заметную долю работы АБД, бесспорно.

Для организации соединения по сети к своей СУБД фирма Oracle предлагает целый ряд решений, не всегда, к сожалению, последовательных, а временами и “сыроватых”. Чтобы разобраться в этом ряду, нужен определенный уровень подготовки по сетевой тематике, не столь уж часто среди специалистов по базам данных встречающийся. К счастью, знание полного арсенала решений Oracle зачастую не требуется, и вполне можно обойтись весьма поверхностным владением вопроса. К нему, однако, относится способность АБД трассировать соединения с Oracle. Трассировка позволяет выявить многие нелады связи с СУБД и наметить выход из положения, и, тем не менее, ею нередко пренебрегают или не пользуются по незнанию.

Здесь будет описано, как можно использовать трассировку соединения с СУБД Oracle c клиентской и с серверной стороны. Такая трассировка дает администратору шанс разобраться в вопросе “Что творится с моим соединением с Oracle?”

В версии 9.1 СУБД компаниейOracle обещаны определенные новшества в организации трассирования, но пока этого не произошло и речь ниже пойдет о версии 8.

За организацию подсоединения клиентов к СУБД по сети в Oracle отвечает компонента под названием Net8. В версиях 7 и более ранних она называлась SQL*Net, а в версии 8 для привлечения большего внимания публики ее переименовали. Искоренить старое название из своей системы оказалось не под силу даже такому передовику производства, как фирме Oracle, так что сейчас в документации и программах встречаются и старое, и новое название. В версии 8 там, где употребляется “SQL*Net”, можно спокойно подставлять “Net8”.

Вот расшифровка других названий, которые могут встретиться в файлах трассировки соединения по сети. Большинство из них относятся к Net8/SQL*Net, но не все (кроме OCI, OPI и TTC):

• OCI – Oracle Call Interface
• OPI – Oracle Program Interface
• TTC – Two-Task Common
• NI – Network Interface
• NR – Network Routing
• NN – Network Naming
• NA – Network Authentication
• TNS – Transparent Network Substrate

В целом смысл многих из них понятен простым переводом на русский.

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

Схема приведена для самого распространенного варианта подключения к Oracle. Но, коль скоро она здесь присутствует, стоит упомянуть и о наличии других вариантов, встречающихся на практике реже. Так, несколько, или же существенно другая схема будет в Oracle иметься для протоколов GIOP – общения с CORBA-объектами – и для JDBC – общения с Java-программами.

Для слежения за тем, как работает соединение по Net8, в Oracle используется журнализация и трассировка. Какой-то принципиальной разницы между тем и другим нет и различие между ними чисто условное. Журнализация фиксирует в специальных файлах наиболее существенные события из “жизни соединения”, такие как, например, возникновение ошибки в Net8 или старт слухача (listener). Трассировка, уже в своих собственных файлах, собирает подробности о тех же событиях, например, о том, как фактически отрабатывалась процедура соединения.

Объектов журнализации и трассировки в сетевой поддержке Oracle может быть несколько, но дальше будут рассмотрены только три основных:

• клиентская компонента Net8
• серверная компонента Net8
• слухач (еще раз: это listener)

Журнальные файлы по умолчанию носят расширение log и располагаются в каталоге %ORACLE_HOME%\network\log. Если специально не указать иного, журнальный файл для сетевой и клиентских компонент Net8 будет называться sqlnet.log, а файл с журналом работы слухача – имя_слухача.log. Другие сетевые компоненты в Oracle имеют свои собственные журнальные файлы.

Трассировочные файлы по умолчанию носят расширение trc и располагаются в каталоге %ORACLE_HOME%\network\trace. Если специально не указать иного, трассировочный файл для сетевой и клиентских компонент Net8 будет называться sqlnet.trc или, иногда, cli.trc. Другие сетевые компоненты в Oracle будут иметь свои собственные трассировочные файлы.

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

• Указать в файле sqlnet.ora имя и место для файла трассировки:
  
  TRACE_DIRECTORY_CLIENT = имя_каталога
  TRACE_FILE_CLIENT = имя_файла
  
  Хотя это и не обязательно, но для более полного контроля полезно это сделать явно, не полагаясь на умолчание.
  
  Если мы, к тому же, пропишем
  
  TRACE_UNIQUE_CLIENT = ON,
  
  то для каждого нового соединения будет создаваться новый файл, в имя которого Oracle будет автоматически дописывать номер процесса – с тем, чтобы имена различались.
  
  
• Указать режим фиксации в трассировочном файле точного времени события (необязательно):
  
  TRACE_TIMESTAMP_ CLIENT = {{TRUE | ON} | {FALSE | OFF }}
  
  
• Указать там же масштаб сбора трассировочной информации:
  
  TRACE_LEVEL_CLIENT = {SUPPORT | ADMIN | USER | OFF},
  
  который последовательно убывает от максимального (SUPPORT) до нуля (OFF) в приведенном списке альтернатив.

Для того, чтобы включения трассировки серверной компоненты Net8 нужно (или полезно) на серверной машине выполнить следующее:

• Указать в файле sqlnet.ora имя и место для файла трассировки:
  
  TRACE_DIRECTORY_SERVER = имя_каталога
  TRACE_FILE_SERVER = имя_файла
  
  Точно так же, это не обязательно, но полезно для более полного контроля.
  
  
• Указать режим фиксации в трассировочном файле точного времени события (необязательно):
  
  TRACE_TIMESTAMP_SERVER = {{TRUE | ON} | {FALSE | OFF }}

• Указать там же масштаб сбора трассировочной информации:
  
  TRACE_LEVEL_SERVER = {SUPPORT | ADMIN | USER | OFF},
  
  который последовательно убывает от максимального (SUPPORT) до нуля (OFF) в приведенном списке альтернатив.

Похожие манипуляции с файлом listener.ora позволяют включить трассировку работы слухача (listener). Чаще всего слухач расположен на той же машине, что и экземпляр СУБД, хотя это и необязательно:

• Указать в файле listener.ora имя и место для файла трассировки:
  
  TRACE_DIRECTORY_ИМЯ-СЛУХАЧА = имя_каталога
  TRACE_FILE_ИМЯ-СЛУХАЧА = имя_файла
  
  Как и выше это необязательно, но желательно.
  
  Если там же прописать
  
  TRACE_FILENO_ИМЯ-СЛУХАЧА = число_файлов
  TRACE_FILELEN_ИМЯ-СЛУХАЧА = число_Кбайт,
  
  то для трассировки будут задействовано указанное число файлов указанного размера, которые будут использоваться по кругу, затирая свое содержимое на новом витке подобно онлайновым журнальным файлам.

• Указать режим фиксации в трассировочном файле точного времени события (необязательно):
  
  TRACE_TIMESTAMP_ИМЯ-СЛУХАЧА = {{TRUE | ON} | {FALSE | OFF }}
  
  Указать объем собираемой в трассировочный файл информации:
  
  TRACE_LEVEL_ ИМЯ-СЛУХАЧА = {SUPPORT | ADMIN | USER | OFF}
  
  с тем же смыслом приведенных альтернатив значений параметра, что и для клиента.

• Перезапустить слухач – например, парой команд из консольного окошка ОС:
  
  > lsnrctl stop
  > lsnrctl start

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

Особенно это касается трассировки серверной части, к которой стекаются соединения ото всех клиентов СУБД. Для серверной части, правда, есть и другой вариант противостоять неконтролируемому росту трассировочных файлов: задать желаемое число файлов нужного размера так, как было показано выше, и тогда объем трассировочной информации не перешагнет положенного предела. Этот вариант доступен только начиная с версии 8.1.

• Вы можете отправить свое мнение о материале его автору
• Другие статьи по продуктам Oracle из рубрики "Мастерская Oracle"

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Oracle
Отправить ссылку на страницу по e-mail