«sql*net»

Министерство высшего образования Российской Федерации Удмуртский государственный университет Кафедра высшей математикиРеферат по теме «SQL*NET»Выполнил: студент гр.38-41 Шишков И. А. Проверил: Вотинцев А.А.. Ижевск 2003ОглавлениеВведение1)Архитектура SQL*NET2)Операции SQL*NET 3)Содержание файлов конфигурации4)Практическая часть5)ЛитератураВведениеSQL*Net – это программное обеспечение удаленного доступа к данным, принадлежащее корпорации Oracle. Этот продукт осуществляет все коммуникации (как клиент/сервер, так и сервер/сервер) через любую сеть. Благодаря SQL*Net, базы данных и их приложения могут располагаться на разных компьютерах и общаться как равные приложения. Используя SQL*Net, можно получать преимущества всех средств сервера Oracle. ^ Функции SQL*Net SQL*Net предоставляет основу для двух дополняющих друг друга способов распределенных коммуникаций через сеть: клиент/сервер и сервер/сервер. ^ Распределенная обработка / Кооперативная обработка При распределенной, или кооперативной, обработке клиенты и серверы взаимодействуют для разрешения единственной транзакции данных, – даже если приложения и базы данных являются разделенными логическими сущностями, в том числе и на разных физических машинах. Транзакция распределяется между местоположениями клиента и серверов; клиент и серверы должны кооперироваться, чтобы выполнить транзакцию. Распределенная обработка позволяет распределять соответствующие ресурсы от подходящих машин в сети. Клиент, например, может выполняться на дружественной к пользователю графической рабочей станции или настольном компьютере, тогда как сервер может находиться на машине, более подходящей для эффективной обработки данных. Распределенная обработка также позволяет централизовать обрабатываемые данные, так что множество клиентских приложений могут одновременно обращаться к единственному серверу. ^ SQL*Net в распределенной обработке SQL*Net отвечает за обеспечение связей между скооперированными партнерами в распределенной транзакции, будь то клиент/сервер или сервер/сервер. Когда клиент или сервер делает запрос на соединение, SQL*Net принимает этот запрос и, если в него вовлечено несколько машин, передает его своему нижележащему уровню, прозрачному сетевому субстрату (TNS), для передачи через подходящий коммуникационный протокол соответствующему серверу. На сервере, SQL*Net принимает запрос от TNS и передает его базе данных в виде сетевого сообщения с одним или несколькими параметрами (например, предложение SQL). За исключением начального соединения, все приложения, как локальные, так и удаленные, генерируют одни и те же запросы, независимо от того, выполняются ли они на одном и том же компьютере или распределены между несколькими компьютерами. Рис.1 показывает локальное приложение (слева), в противоположность приложению клиент-сервер (справа). В обоих случаях приложение представляет собой экран ввода данных ^ Функциональные преимущества SQL*Net SQL*Net предоставляет пользователям сетевых приложений следующие преимущества: сетевую прозрачность независимость от протоколов независимость от среды/топологии способность работы в гетерогенной сетевой среде прозрачность местоположения хорошие диагностические средства ^ Конфигурация сервер/сервер В конфигурации сервер/сервер, эта же способность работы в гетерогенной сети расширяется для обеспечения межбазовых коммуникаций для распределенных запросов и обновлений в Oracle.В SQL*Net возможны два типа соединений сервер/сервер: прямое соединение между двумя серверами в одном и том же сообществе. соединение между серверами в разных сообществах через один или несколько экземпляров Interchange. ^ Конфигурация клиент/серверВ среде SQL*Net , клиент и сервер могут принадлежать разным сетевым сообществам, соединенным через один или несколько экземпляров продукта MultiProtocol Interchange. Сообщество – это группа компьютеров, взаимодействующих друг с другом через один и тот же протокол транспортного уровня, такой как TCP/IP; компьютеры, разделяющие такой общий протокол, называются членами сообщества. Используя Interchange как посредник, приложения на машинах клиента и сервера могут связываться друг с другом даже при отсутствии общего транспортного протокола. Все данные, обмениваемые в приложениях клиент/сервер, продвигаются по своему пути при посредстве экземпляров Interchange.Рис. 2 показывает соединение между клиентом и сервером, использующими различные протоколы в соседних сообществах. Обе сети соединены через MultiProtocol Interchange. На клиенте инсталлированы SQL*Net и протокольный адаптер Oracle, специфичный для Протокола A, в то время как на сервере инсталлированы SQL*Net и протокольный адаптер Oracle, специфичный для Протокола B. Interchange имеет адаптеры для обоих протоколов A и B.Рис. 2. Работа в гетерогенной сети с соединением клиент/серверРис. 1. Локальная и распределенная обработка1. Архитектура SQL*NetДля соединения клиента с сервером и установления сессии Oracle продукт SQL*Net использует прозрачный сетевой субстрат (TNS) и промышленные стандарты сетевых протоколов. В этом разделе будут описаны следующие пункты.прозрачный сетевой субстрат (Transparent Network Substrate, TNS) коммуникационная роль SQL*Net распределенная обработка с SQL*Net операции SQL* Net SQL*Net и сетевой приемник Прозрачный сетевой субстрат Прозрачный сетевой субстрат (TNS), образующий основу для нового поколения сетевых продуктов Oracle, представляет собой новую технологию, которая позволяет Oracle разворачивать сеть приложений над любыми существующими компьютерными сетями. Благодаря TNS, связываемость между приложениями (по принципу равный-с-равным) возможна там, где связываемость между машинами недоступна.^ Коммуникационая роль SQL*Net В распределенной транзакции, SQL*Net отвечает за посылку информации через различные сети от имени клиентского приложения или сервера базы данных. В любой такой конфигурации, имеются в общем случае два различных типа компьютеров, выступающих как клиент и сервер. SQL*Net гарантирует разрешение всех различий между клиентами и серверами, таких как внутренние представления данных или национальные наборы символов, обеспечивая тем самым прозрачность коммуникаций между клиентом и сервером. SQL*Net передает все коммуникационные задачи в TNS через его общие точки входа, и не зависит от специфики механизма коммуникаций, используемого под TNS (будь то TCP/IP, DECnet, разделяемая память и т.п.).^ Распределенная обработка с SQL*Net В выполнении распределенной транзакции участвуют несколько компонент программного обеспечения, в зависимости от типа транзакции (клиент/сервер или сервер/сервер). Рис. 3 показывает эти компоненты для сессии клиент/сервер  ^ Рис.3. Компоненты сессии Oracle клиент/серверКлиентское приложение Клиентское приложение обеспечивает всю пользовательскую деятельность, такую как символьный или графический интерфейс, управление экраном, представление данных, поток задачи и другую специфику приложения. Приложение определяет все операции SQL, которые необходимо направить серверу базы данных, и передает эти операции через пользовательский программный интерфейс (UPI). ^ Пользовательский программный интерфейс (UPI) UPI представляет собой небольшой слой программного кода, который содержит всю информацию, необходимую для инициирования диалога SQL между клиентом и сервером. UPI определяет обращения к серверу для: синтаксического разбора предложений SQL открытия курсора для предложения SQL привязки переменных клиентского приложения к разделяемой памяти сервера описания содержимого возвращаемых полей на базе значений в словаре данных сервера исполнения предложений SQL внутри пространства памяти курсора выборки одной или нескольких строк данных в клиентское приложение закрытия курсора Two Task Common Слой Two Task Common обеспечивает преобразование набора символов и типа данных между клиентом и сервером. Этот слой оптимизирован так, чтобы выполнять преобразование только при необходимости, для каждого соединения индивидуально. SQL*Net Роль SQL*Net состоит в установлении и поддержании соединения между клиентским приложением и сервером и обмене сообщениями между ними. Во время начального соединения, SQL*Net отвечает за установление различий во внутренних представлениях данных и наборах символов и определение того, какие преобразования требуются для данного соединения. SQL*Net принимает входящие соединения базы данных от сетевого приемника и передает управление серверу базы данных.^ Прозрачный сетевой субстрат (TNS) TNS принимает запросы от сетевых приложений, – в данном случае от SQL*Net, – и разрешает все общие вопросы межмашинной связываемости, такие как: как будут обрабатываться прерывания между клиентом и сервером в зависимости от возможностей каждой из сторон местоположение сервера или назначение TNS будут ли в соединении участвовать один или несколько экземпляров MultiProtocol Interchange Обобщенный набор функций TNS передает управление протокольному адаптеру Oracle для выполнения специфичного для сети вызова. ^ Протокольный адаптер Oracle Протокольный адаптер Oracle отвечает за установление соответствия между функциями TNS и промышленно-стандартным протоколом, использующимся в соединении клиент/сервер (или в отдельной части такого соединения, в случае соединения между множественными сообществами). Каждый протокольный адаптер отвечает за установление эквивалентности между TNS и функциями конкретного протокола, включая трансляцию форматов параметров и разрешение тонкостей, связанных с характеристиками времени в том или ином протоколе. ^ Конкретные сетевые протоколы Любое программное обеспечение Oracle в процессе соединения клиент/сервер требует существующего стека сетевых протоколов для установления межмашинного соединения между двумя компьютерами. Сетевой протокол отвечает только за перенос данных с машины клиента на машину сервера, после чего данные поступают в распоряжение протокольного адаптера Oracle на стороне сервера.^ Подъем вверх по стеку сервера Подъем вверх по стеку сервера представляет собой процесс, обратный тому, который был выполнен на стороне клиента. Одной операцией, уникальной для стороны сервера, является акт приема начального соединения. Сервер имеет сетевой приемник, который регулярно прослушивает входящие соединения и определяет их назначение. На основе специфицированного в соединении идентификатора сервера Oracle (SID), соединение передается SQL*Net и далее серверу Oracle. Компоненты, находящиеся над SQL*Net, OPI и сервер Oracle, отличаются от соответствующих компонент на стороне клиента.^ Программный интерфейс Oracle (OPI) OPI функционально дополняет UPI; задача этого интерфейса – отвечать на любое из возможных сообщений, присылаемых от UPI. Например, запрос UPI на выборку 25 строк данных заставит OPI ответить возвратом 25 строк после их извлечения.^ Сервер Oracle Сторона сервера Oracle в соединении отвечает за прием запросов от клиентского кода UPI и разрешение предложений SQL от имени приложения клиента. Принятый запрос обрабатывается, и результирующие данные передаются OPI для их форматирования и возврата приложению клиента. ^ Взаимодействие сервер/сервер Когда два сервера взаимодействуют для выполнения распределенной транзакции, процесс и все диалоги остаются теми же, как и в сценарии клиент/сервер, с той разницей, что здесь нет клиентского приложения. Сервер имеет свою собственную версию интерфейса UPI, которая называется NPI. Интерфейс NPI может осуществлять все функции, которые UPI выполняет для клиентов, позволяя координирующему серверу создавать запросы SQL, адресуемые к дополнительным серверам. Рис.4 показывает соединение сервер/сервер и все соответствующие слои.  Рис.4. Компоненты сессии Oracle сервер/сервер^ 2. Операции SQL*Net SQL*Net предоставляет девять индивидуальных функций. Эти функции принадлежат трем общим классам: операции соединений операции данных операции исключений Все функции применяются в инструментах и базах данных, использующих SQL*Net для распределенной обработки, хотя ни одна из этих функций не видна пользователю. 2.1 Операции соединений SQL*Net поддерживает две основных операции соединений:соединение с сервером отсоединение от сервера Соединение с сервером Операция соединения между клиентским приложением и сервером инициируется во время любого стандартного подключения к базе данных, и содержит такую информацию, как имя клиентской машины и имя пользователя, передаваемые удаленной машине. Клиентское приложение инициирует запрос на соединение с удаленной базой данных (или другой сетевой службой), предоставляя краткое имя желаемого назначения. Это краткое имя, называемое именем службы (сервиса), преобразуется в сетевой адрес, который содержится в дескрипторе соединения, хранящемся в файле конфигурации сети TNSNAMES.ORA либо в базе данныхОтсоединение от сервера Запрос на отсоединение от сервера может быть инициирован несколькими различными способами: по инициативе пользователя запросом на другое соединение аварийным завершением соединения по таймауту Разъединение по инициативе пользователя. Пользователь может выдать запрос на разъединение по концу транзакции клиент/сервер, или сам сервер может отсоединиться от другого сервера, когда все данные сервер/сервер переданы и в дальнейшем соединении нет необходимости (самый простой случай).^ Запрос на другое соединение. В случае, когда клиентское приложение соединено с сервером и требует доступа к другому пользовательскому учетному имени на сервере (или тому же имени на другом сервере), большинство инструментов Oracle сначала отсоединяют приложение от первоначального сервера. После того, как разъединение выполнено, инициируется запрос на новое соединение. ^ Аварийное прекращение соединения. Может случиться, что одна из программных компонент под SQL*Net закончит соединение или прервет коммуникации, а SQL*Net не будет своевременно информирован об этом.Во время очередной операции данных SQL*Net, модуль TNS распознает сбой и уведомит SQL*Net о необходимости сбросить операции клиента и сервера, что приведет к разъединению текущей операции. ^ Разъединение по таймауту или обнаружение зависшего соединения (только версия 2.1). В соединении с включенным средством распознавания зависшего соединения, от сервера к клиенту периодически с заданным интервалом (обычно несколько минут) посылается небольшой тестовый пакет. Если соединение не работает (обычно из-за недоступности клиентского процесса или машины), оно закрывается, после того как операция передачи сгенерирует ошибку. 2.2 Операции данных SQL*Net поддерживает четыре набора операций с данными клиент/сервер:синхронная передача данных синхронный прием данных асинхронная передача данных асинхронный прием данных Концепция передачи и приема данных между клиентом и сервером от имени UPI и OPI довольно прямолинейна. Диалоговый запрос SQL передается от UPI, через запрос на передачу, в SQL*Net. На стороне сервера, SQL*Net обрабатывает запрос на прием и передает данные базе данных. На обратном пути от сервера все происходит в обратном порядке. Все запросы на прием и передачу синхронны; иными словами, когда клиент инициирует запрос, он ждет ответа от сервера. После этого он может выдавать очередной запрос. 2.3 Операции исключений SQL*Net поддерживает три операции исключений:инициирование прерывания через соединение TNS сброс соединения для синхронизации после прерывания проверка условий соединения Из этих трех операций только первая может контролироваться пользователем. Когда пользователь нажимает Ctrl-c или клавишу прерывания, приложение вызывает эту функцию. Остальные две операции исключений применяются внутренне продуктами, использующими SQL*Net, для разрешения вопросов, связанных с таймером. SQL*Net может инициировать проверку канала связи, например, чтобы удостовериться в прибытии новых данных. Функция сброса служит для разрешения ненормальных состояний, например для синхронизации соединения после возникновении прерывания. ^ 3. Содержимое файлов конфигурации SQL*Net Краткий обзор файлов конфигурации, используемых сетевыми продуктами Oracle. LISTENER.ORA TNSNAMES.ORA SQLNET.ORA Файлы конфигурации клиента Клиенты имеют обычно три файла конфигурации, которые создает Network Manager, а также один, который должен быть создан вручную. Эти файлы содержат информацию о: сетевых назначениях навигации в сети трассировке и журнализации TNSNAMES.ORA – Этот файл содержит список имен служб и дескрипторов соединений для сетевых назначений. Необходим, если используется Oracle Names. Этот файл должен генерироваться и модифицироваться только с помощью Oracle Network Manager. SQLNET.ORA – Этот файл содержит необязательные параметры диагностики, информацию клиента об Oracle Names, а также несколько других необязательных параметров. SQLNET.ORA может содержать параметры, специфичные для узла. ^ Файлы конфигурации сервера Серверы в сети, включающей распределенные базы данных, также требуют наличия файлов, необходимых для клиентов, потому что, когда серверы используют связи баз данных для соединения с другими машинами серверов, они, по существу, выступают в качестве клиентов. LISTENER.ORA Этот файл включает имена и адреса всех приемников на машине, системные идентификаторы (SIDы) баз данных, а также различные управляющие параметры, используемые управляющей утилитой приемника. Этот файл должен генерироваться и модифицироваться только с помощью Oracle Network Manager. Файлы LISTENER.ORA и TNSNAMES.ORA содержат частично одинаковую информацию. Адрес в дескрипторе соединения сервера в TNSNAMES.ORA – тот же самый, что и адрес приемника для сервера в LISTENER.ORA. Аналогично, дескриптор соединения в файле TNSNAMES.ORA включает SID, который требуется (как SID_NAME) в файле LISTENER.ORA^ Конфигурирование приемника TNS: LISTENER.ORA Прежде, чем сервер базы данных сможет принимать соединения от клиентов SQL*Net, на платформе этого сервера должен быть запущен приемник. На большинстве платформ для этой цели используется сетевой приемник. Файл конфигурации для сетевого приемника имеет имя LISTENER.ORA. Этот файл содержит четыре части:имя приемника определение адреса приемника описание баз данных, использующих этот приемник параметры, определяющие поведение приемника Имена приемников Имя приемника должно быть легким для использования. По умолчанию принимается имя LISTENER, которое рекомендуется для стандартных установок, требующих лишь одного приемника на машине. Имя приемника должно быть уникальным в сети. Эта уникальность автоматически гарантируется тем, что Network Manager присоединяет к задаваемому вами имени имя узла и его домен Имя приемника должно быть уникальным на машине. Если на машине несколько приемников, то каждый из них должен иметь уникальное имя. ^ IPC – адреса для приемника Помимо вызовов от других узлов, приемник прослушивает вызовы межпроцессной связи (IPC). Например, на машине UNIX, IPC-адаптер представляет собой адаптер для коммуникационного механизма сокета доменов UNIX (UDS); на машине VMS – это адаптер для коммуникационного механизма почтового ящика (MBX). IPC-адреса должны быть включены в файл LISTENER.ORA. Network Manager генерирует входы IPC автоматически, не требуя вашего ввода. Формат IPC-адреса, одинаковый для всех платформ, имеет вид: (ADDRESS= (PROTOCOL=IPC) (KEY=строка)) Network Manager создает два IPC-адреса для каждой базы данных, прослушиваемой данным приемником. В первом из них значение KEY совпадает с именем службы. Этот IPC-адрес используется для соединений из других приложений на этом же узле. Имена служб описываются ниже в этой главе, в разделе “TNSNAMES.ORA”. Во втором IPC-адресе значение KEY совпадает с системным идентификатором базы данных (SID), Описание баз данных для приемника Следующая секция файла LISTENER.ORA описывает системные идентификаторы (SIDы) баз данных, прослушиваемых этим приемником. Эта секция имеет следующий синтаксис: SID_LIST_имя_приемника=[(SID_LIST=](SID_DESC=(SID_NAME=SID) (окружение_Oracle=путь_базы_данных))[(SID_DESC=(SID_NAME=SID)(окружение_Oracle=путь_базы_данных)) …][)] Здесь SID – это системный идентификатор Oracle соответствующего сервера базы данных. Ключевое слово, обозначенное как “окружение_Oracle”, специфично для операционной системы. Его значение, обозначенное как “путь_базы_данных”, указывает местоположение исполнительных модулей этой базы данных. Можно заметить, что приемник может прослушивать несколько баз данных на данной машине. Однако можно создавать разные приемники для баз данных. Все приемники на одной и той же машине совместно используют единственный файл LISTENER.ORA. ^ Управляющие параметры LISTENER.ORA Третья секция файла LISTENER.ORA содержит список параметров, управляющих поведением приемника: PASSWORDS_имя_приемника=(пароль[,…пароль]) Этот необязательный параметр допускает указать один или более паролей. STARTUP_WAIT_TIME_имя_приемника=число Этот параметр задает время в секундах, в течение которого приемник ожидает перед тем, как ответить на первую команду управления состоянием приемника. Эта возможность гарантирует, что приемник с медленным протоколом будет иметь достаточно времени стартовать, прежде чем ответить на запрос статуса. По умолчанию 0. CONNECT_TIMEOUT_имя_приемника=число Этот параметр задает время в секундах, в течение которого приемник ожидает перед тем, как получить действительный запрос SQL*Net на соединение после начала соединения. Приемник разрывает соединение, если превышен этот таймаут. По умолчанию 10; нулевое значение отменяет таймаут. TRACE_LEVEL_имя_приемника=OFF|USER|ADMIN Этот параметр задает уровень детализации трассировки для событий приемника. Возможные варианты: OFF, USER или ADMIN. По умолчанию OFF. TRACE_DIRECTORY_имя_приемника=путь_директории_файла_трассировки Этот параметр задает каталог, в котором размещается файл трассировки. Умолчание зависит от операционной системы. TRACE_FILE_имя_приемника=имя_файла_трассировки Этот параметр задает имя файла трассировки. По умолчанию принимается имя_приемника.trc (на большинстве платформ). LOG_DIRECTORY_имя_приемника=путь_директории_журнала_приемника Этот параметр задает каталог, в котором размещается файл журнала, автоматически генерируемый для событий приемника. Умолчание зависит от операционной системы LOG_FILE_имя_приемника=имя_файла_журнала_приемника Этот параметр задает имя файла журнала приемника. По умолчанию принимается имя_приемника. log (на большинстве платформ). TNSNAMES.ORA Файл TNSNAMES.ORA используется клиентами и серверами распределенной базы данных для того, чтобы идентифицировать потенциальные назначения, – как серверы, так и, возможно, экземпляры Interchange. (Если в сети используется Oracle Names, то файлы TNSNAMES.ORA не нужны; серверы Names получают требуемую информацию из определения сети, хранящегося в базе данных.) Каждая запись в файле TNSNAMES.ORA включает два элемента: имя службы дескриптор соединения Всем дескрипторам соединений в файле TNSNAMES.ORA назначаются имена служб. Пользователь специфицирует имя службы, – краткое слово вместо длинного дескриптора соединения, – чтобы указать сетевую службу, с которой он хочет соединиться. Содержимое файла TNSNAMES.ORA представляет собой список имен служб, сопоставленных дескрипторам соединений TNS. Имя службы для базы данных должно совпадать с глобальным именем этой базы данных, определенным системным администратором. Альтернативные имена служб, или алиасы, могут назначаться службе базы данных через файл TNSNAMES.ORA. Хотя можно иметь несколько алиасов для одной и той же службы базы данных, но нельзя ь несколько приемников для одной и той же службы базы данных. Каждой базе данных требуется дескриптор соединения. Дескриптор соединения для базы данных описывает местоположение сетевого приемника и системный идентификатор (SID) базы данных, с которой осуществляется соединение. Дескрипторы соединений баз данных состоят из двух секций, содержащих: адрес приемника (ADDRESS) SID базы данных, передаваемый как данные соединения приложения (CONNECT_DATA ) ^ Секция ADDRESS Адрес приложения – это информация, требуемая для того, чтобы связаться с этим приложением (в данном случае – службой базы данных) в рамках данного протокола связи. Эта информация включает сообщество, в которое входит назначение, протокол, используемый этим сообществом, и параметры, специфичные для этого протокола. ^ Секция CONNECT_DATA SQL*Net использует ключевое слово CONNECT_DATA для обозначения системного идентификатора (SID) удаленной базы данных. Когда SQL*Net на стороне сервера принимает запрос на соединение, TNS передает содержимое параметра CONNECT_DATA приемнику, который идентифицирует целевую базу данных. CONNECT_DATA – это независимое от протокола ключевое слово, указывающее, что специфичные для приложения данные будут поставляться во время соединения, а SID ссылается на системный идентификатор Oracle для сервера базы данных.^ Адреса Interchange Дескриптор соединения для Interchange содержит лишь одну секцию – секцию ADDRESS_LIST. В этой секции перечисляются все адреса Interchange, включая требуемые протоколом специфичные ключевые слова. Дескриптор соединения для Interchange не содержит секции CONNECT_DATA. ^ Корректировка дескрипторов соединений Каждый раз, когда в сеть добавляется новая база данных, нужно добавить в файл TNSNAMES.ORA новое имя службы и новый дескриптор соединения. Для обновления файлов TNSNAMES.ORA нужно Oracle Network Manager. ^ Системные и пользовательские файлы TNSNAMES.ORA На большинстве платформ могут существовать две версии файла TNSNAMES.ORA: одна общесистемная (доступная всем пользователям), и еще одна, необязательная, личная версия на уровне пользователя. Если существует такой личный файл TNSNAMES.ORA, то его содержимое имеет преимущество над общесистемным файлом. Иными словами, если некоторое имя службы привязано в этих файлах к разным дескрипторам соединений, то будет использоваться тот дескриптор, который описан в локальном файле пользователя. Локальный файл TNSNAMES.ORA не подменяет собой системный файл, но дополняет его. Например, если разработчик создает базу данных, которая в общем случае недоступна другим пользователям, то он может создать личный файл TNSNAMES.ORA, сопоставляющий имя службы этой базы данных ее дескриптору соединения. Благодаря наличию собственного файла TNSNAMES.ORA, разработчик получает возможность работать со своей базой данных, не обращаясь к системному администратору. SQLNET.ORA Файл SQLNET.ORA создается для всех клиентов и узлов в сети. Этот файл содержит пять различных типов информации: интервал времени между опросами, тестирующими существование соединения клиент-сервер (распознавание зависших соединений) необязательные параметры трассировки и журнализации умалчиваемые домены параметры клиента для использования с Oracle Names другие необязательные параметры Распознавание зависших соединений Необязательный параметр SQLNET.EXPIRE_TIME определяет, как часто SQL*Net посылает пробный пакет, чтобы удостовериться в существовании соединения клиент-сервер. В случае аварийного останова клиента соединение может оставаться открытым неограниченное время, если не будет идентифицировано и закрыто системой. Если этот параметр специфицирован, то SQL*Net периодически тестирует сеть, чтобы выяснить, нет ли недействительного соединения, которое должно быть прекращено. Если он обнаруживает зависшее или неиспользуемое соединение, то он возвращает ошибку, что заставляет серверный процесс завершиться. Распознавание зависших соединений добавляет некоторые накладные расходы в систему:Тестирование зависших соединений генерирует дополнительный сетевой трафик. Посылаемый проверочный пакет весьма мал, но такой пакет посылается по каждому соединению через интервалы времени, заданные параметром SQLNET.EXPIRE_TIME в файле SQLNET.ORA. При обнаружении зависшего соединения серверу Oracle может потребоваться выполнить дополнительную обработку, чтобы отличить событие проверки соединения от других возможных событий, в зависимости от операционной системы. Для некоторых протоколов, обобщенное средство SQL*Net проверки зависших соединений ничем не лучше, чем собственный алгоритм, присущий нижележащему транспортному протоколу. В таком случае нет необходимости включать это средство. ^ Необязательные параметры трассировки Если выбрать любые необязательные параметры трассировки в карте Client Profile на экране Network Manager, то соответствующие параметры появляются в файле SQLNET.ORA. TRACE_LEVEL_CLIENT TRACE_FILE_CLIENT TRACE_DIRECTORY_CLIENT Для серверов, нужно добавить любые параметры трассировки в файл SQLNET.ORA вручную; Network Manager не генерирует их. Аналогично, если нужно установить необязательные параметры журнализации либо задать отличные от стандартных пути или имена для журналов клиента или сервера, то нужно отредактировать файл SQLNET.ORA вручную. Network Manager не создает необязательных параметров журнализации. ^ Умалчиваемые домены Независимо от того, используете ли вы Oracle Names, файл SQLNET.ORA включает параметр, задающий умалчиваемый домен. Параметры Oracle Names Если используется Oracle Names, то требуется еще один параметр, NAMES.PREFERRED_SERVERS. Этот параметр задает один или несколько адресов серверов Names, которые клиент предпочитает использовать. Могут появиться также несколько необязательных параметров трассировки для Oracle Names ^ Дополнительные параметры SQLNET.ORA Файл SQLNET.ORA используется главным образом для задания средства распознавания зависших соединений, параметров трассировки и умалчиваемого домена. Однако могут оказаться полезными и параметры, которые описывают некоторые дополнительные функции. Следующие параметры, если они используются, должны добавляться в файл SQLNET.ORA вручную; эти параметры не затрагиваются при использовании Network Manager. ^ Отключение IPC Если по какой-то причине нужно чтобы IPC-адреса автоматически отыскивались на некоторых узлах в сети, то добавляется следующий параметр в файл SQLNET.ORA для каждого такого узла: AUTOMATIC_IPC=OFF Если этот параметр опущен, то по умолчанию соединение отыскивает IPC-адрес. ^ Использование выделенного сервера Обычно, когда приемник принимает запрос на соединение, он передает этот запрос существующему процессу, т.е. использует многопоточный сервер. Чтобы приемник запускал специально выделенный серверный процесс для соединений с этой базой данных нужно добавить следующую строку в файл SQLNET.ORA для узла приемника: USE_DEDICATED_SERVER=ON Умалчиваемое значение – OFF. Важно, чтобы все создаваемые вручную записи вставлялись в файл SQLNET.ORA после того, как этот файл распределен в соответствующее назначение. Ввиду того, что этот файл генерируется одинаковым для всех клиентов с одним и тем же профилем клиента, ручное редактирование его до рассылки на другие узлы может привести к нежелательным последствиям.4. Практическое задание В качестве задания были рассмотрены файлы Listener.ora,Tnsnames.ora,Sqlnet.ora.Файл Listener.ora^ LISTENER = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = 3) (Port = 1521) ) (ADDRESS = (PROTOCOL = TCP) (Host = 127.0.0.1) (Port = 1521) )# (ADDRESS = # (PROTOCOL = SPX)# (Service = 3_lsnr)# ) )^ STARTUP_WAIT_TIME_LISTENER = 0CONNECT_TIMEOUT_LISTENER = 10TRACE_LEVEL_LISTENER = ADMINSID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = ORCL) ) )Описание параметровListener – имя приемника по умолчанию.ADDRESS_LIST – адреса приемников.Далее указывается описание этих приемников.Имя протокола,адреса хоста и порта.В следущем разделе файла listener.ora содержится список параметров управляющих поведением приемника STARTUP_WAIT_TIME_LISTENER = 0 Этот параметр задает время в секундах, в течение которого приемник ожидает перед тем, как ответить на первую команду управления состоянием приемника. Эта возможность гарантирует, что приемник с медленным протоколом будет иметь достаточно времени стартовать, прежде чем ответить на запрос статуса. CONNECT_TIMEOUT_LISTENER = 10 Этот параметр задает время в секундах, в течение которого приемник ожидает перед тем, как получить действительный запрос SQL*Net V2 на соедин