oracle что такое listener

Урок 4: Настройка прослушивателя. Остановка и запуск экземпляра БД

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

Прослушиватель

Прослушиватель управляется файлом listener.ora. Может быть сконфигурирован только один файл listener.ora, на сервере может быть настроено несколько прослушивателей, и этот единственный файл может обслуживать их все. Как правило, если на одном сервере настроено несколько прослушивателей, то это сделано либо с целью обеспечения отказоустойчивости, либо для балансировки обращений к базе данных. Несколько прослушивателей, так же настраиваются при использовании Real Application Cluster.

Каждый прослушиватель представляет собой именованный процесс, запускаемый на каждом сервере баз данных. По умолчанию, прослушиватель имеет имя LISTENER и создается при установке Oracle. Если же вы настраиваете несколько прослушивателей, то каждый должен иметь уникальное имя. Ниже представлен пример файла listener.ora:

# listener.ora Network Configuration File:
/u01/app/oracle/product/11.1.0/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = test.all-oracle.ru)
(PORT = 1521))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
)
)

Теперь вы имеете общее представление о прослушивателе. И можем настроить прсолушиватель для нашей базы данных.

Откроется окно графического приложения:

Предлагаются варианты, чего собственно будем настраивать. Нас интересует прослушиватель, поэтому выбираем «Listener configuration» и переходим далее.

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

Здесь предстоит указать протоколы, которые будут использованы. Как правило, используется обычный TCP, его и выбираем. Жмем далее.

Указываем порт, который будет использоваться прослушивателем. По умолчанию, это 1521. Оставляем как есть и переходим далее.

Сейчас система интересуется, будет ли настраиваться еще один прослушиватель, отвечаем нет, переходим далее, и завершаем настройку. Если все хорошо, то на следующем экране система сообщит об успешном завершении настройки.

Теперь, когда прослушиватель настроен, можно познакомится с основными командами управления. Для управления прослушивателем используется утилита lsnrctl, расположена там же, где и утилита для настройки прослушивателя. Для ее запуска выполним:

Результатом исполнения, будет приглашение работать с консолью прослушивателя:

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

Аналогичным образом можно выполнить остановку или просмотреть статус.

Это все хорошо, скажете вы, но как быть если прослушивателя два, или три, как объяснить Oracle с каким прослушивателем хочет работать пользователь?

В случае, если у вас более одного прослушивателя, вы должны указать имя прослушивателя в команде. Например, выполним запуск прослушивателя, обратившись по имени:

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

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

oracle@test:export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1
oracle@test:export ORACLE_SID=test

Если база данных потушена, то об этом будет сообщено: Connected to an idle instance. Т.е. мы подключились к простаивающему экземпляру. Если же база данных поднята, то сообщится версия базы данных и редакция. Сейчас база данных погашена, для работы с ней, требуется ее запустить. Для этого выполним:

Сейчас база данных готова к работе. Для того что бы прверить работоспособность можно снова зайти в sqlplus и выполнить любой sql запрос. Например:

Вам будет выведена информация о базе данных.

Остался вопрос, как остановить базу данных. Остановка базы данных осуществляется так же через sqlplus. Для этого заходим в него, как было описано выше, при описании запуска базы данных Oracle. Ниже показана процедура остановки экземпляра базы данных и прослушивателя:

Сейчас база данных и прослушиватель остановлены. На этом завершим урок. В дальнейших уроках, будет более подробно остановимся на запуске и остановке экземпляра базы данных. Расскажу о параметрах остановки и запуска экземпляра и как они могут повлиять на работоспособность базы данных или помочь в случае сбоев.

Источник

Listener Oracle

Стас Белков

Автор статьи. Известный специалист в мире IT. Консультант по продуктам и решениям Oracle. Практикующий программист и администратор баз данных. Подробнее.

Листенер (слушатель) Oracle Net Listener — служба, которая действует только на сервере и прослушивает входящие запросы на подключение. Oracle предоставляет утилиту lsnrctl, управляющую процессом листенера. Место слушателя в сетевой обработке Oracle можно кратко описать следующим образом.

Файл listener.ora, который по умолчанию размещается в каталоге $ORACLE_HOME/network/admin в системах UNIX и в каталоге $ORACLE_HOME\network\admin в системах Windows, содержит информацию о конфигурации Listener Oracle. Поскольку служба слушателя действует только на сервере, клиентские компьютеры не содержат никакого файла listener.ora. Типичный файл listener.ora приведен в листинге ниже.

Все параметры конфигурации в этом файле имеют значения по умолчанию. Поэтому службу листенера не обязательно конфигурировать вручную. После создания первой базы данных на сервере служба TNS Listener Oracle автоматически запускается, и файл конфигурации слушателя, listener.ora, помещается в каталог, определенный по умолчанию. При создании новой базы данных ее информация о сетевых подключений и службах автоматически добавляется в файл конфигурации tns listener Oracle. При запуске экземпляра база данных автоматически регистрируется в слушателе, и слушатель начинает прослушивать запросы на подключение к этой базе данных.

Процесс PMON Oracle отвечает за динамическую регистрацию имен служб баз данных Oracle в листенере (Listener) — при создании новые базы данных Oracle будут автоматически регистрироваться в службе TNS Listener Oracle. Процесс PMON будет обновлять файл listener.ora после создания каждой базы данных на сервере.

Для обеспечения возможности автоматической регистрации файл init.ora или SPFILE должен содержать следующие параметры:

Если значение параметра SERVICE_NAMES не указано, по умолчанию ему присваивается значение глобального имени базы данных, являющееся сочетанием параметров DB_NAME и DB_DOMAIN. Значение параметра INSTANCE_NAME, устанавливаемое по умолчанию — идентификатор SID, введенный во время установки Oracle или создания базы данных.

Состояние листенера на сервере можно проверить с помощью утилиты lsnrctl, как показано в листинге ниже. Вывод показывает длительность работы Listener Oracle и размещение файла конфигурации службы слушателя. Он содержит также имена баз данных, которые слушатель “прослушивает” на предмет запросов на подключение.

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

Команды TNS Listener Oracle

После вызова утилиты lsnrctl помимо status можно выполнять и другие важные команды. Например, команда services позволяет выяснить, какие службы слушатель отслеживает на предмет запросов на подключение.

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

Ознакомиться с доступными командами утилиты lsnrctl можно с помощью команды help, введенной в интерфейсе lsnrctl, как показано в листинге ниже.

После вызова утилиты lsnrctl запуск Listener можно осуществить с помощью команды start, а его остановку — с помощью команды stop. Если эти команды требуется выдать из командной строки операционной системы, можно использовать команды lsnrctl start и lsnrctl stop.

При внесении изменений в файл listener.ora единственный способ ввода этих изменений в действие — перезапуск слушателя. Другой, более безопасный способ — просто перезагрузка информации Listener, в результате чего последние выполненные изменения слушателя будут внесены в файл конфигурации. Команда lsnrctl reload позволяет перезагрузить TNS Listener Oracle “на лету”, без его перезапуска. Подключенные в текущий момент клиенты останутся подключенными во время перезагрузки Listener (или даже при его перезапуске), поскольку слушатель уже “отдал” подключения базе данных и не участвует в обмене данными между клиентом и службой базы данных.

Внимание! Изменять файл listener.ora не рекомендуется, если только для этого не существует веской причины. Кроме того, при использовании динамической автоматической регистрации служб необходимость в модификации файла возникает значительно реже. Тем не менее, в некоторых случаях приходится изменять определенную часть файла Listener, содержащую информацию о конфигурации сети для всех служб, которые слушатель отслеживает на предмет запросов подключения.

Управление Listener

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

Несколько TNS Listener

На одном сервере могут действовать более одной службы Listener NET Oracle, но обычно такую конфигурацию придется применять в Oracle RAC. При использовании нескольких служб слушателя можно конфигурировать параметр CONNECT_TIME_FAILOVER, который определяет длительность ожидания клиентом подключения через одного Listener, прежде чем будет предпринята попытка подключения с помощью другого Listener Oracle.

Установка размера очереди

Иногда большое количество одновременных запросов на подключение со стороны клиентов могут перегрузить службу слушателя. Чтобы уберечь Listener от сбоя, можно использовать параметр QUEUESIZE в файле конфигурации listener.ora для указания допустимого количества параллельно выполняющихся запросов на подключение.

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

Установка пароля для Oracle Listener

При первоначальной установке Listener утилита не имеет никакой защиты паролем. Любой пользователь, имеющий доступ к операционной системе, без труда может остановить Listener Oracle и воспрепятствовать клиентам подключаться, просто введя команду lsnrctl stop в командной строке.

На заметку! Установленный по умолчанию пароль службы слушателя — listener, и при использовании Listener этот пароль указывать не нужно.

Собственный пароль для утилиты Listener Oracle можно установить, как показано в листинге ниже.

После того как пароль успешно изменен, службу Listener нельзя будет останавливать или запускать как раньше — для этого придется ввести пароль пользователя. Для указания листенеру Оракл нового пароля необходимо использовать выражение set password в приглашении утилиты lsnrctl, после чего можно еще раз запустить или остановить службу Oracle Net Listener. Обратите внимание, что выражение set password не устанавливает новый пароль, а просто вынуждает слушателя запрашивать пароль для выполнения административных задач.

Результат неудачной попытки остановки Listener вследствие отсутствия предоставленного пароля показан в листинге ниже. Затем листенер был корректно остановлен посредством применения команды set password.

Источник

12
Configuring and Administering the Listener

The listener is a separate process that runs on the database server computer. It receives incoming client connection requests and manages the traffic of these requests to the database server. This chapter describes how to configure the listener to accept client connections.

This chapter contains these topics:

Listener Configuration Overview

A version 9 listener is required for an Oracle9 i database. Previous versions of the listener are not supported for use with an Oracle9 i database. However, it is possible to use a version 9 listener with previous versions of the Oracle database.

Supported services, that is, the services to which the listener forwards client requests, can be configured in the listener.ora file or this information can be dynamically registered with the listener. This dynamic registration feature is called service registration and is used by Oracle9 i or Oracle8 i instances. The registration is performed by the PMON process—an instance background process—of each database instance that has the necessary configuration in the database initialization parameter file. Dynamic service registration does not require any configuration in the listener.ora file.

Service registration offers the following benefits:

Service registration reduces the need for the SID_LIST_ l istener_name parameter setting, which specifies information about the databases served by the listener, in the listener.ora file.

The SID_LIST_ l istener_name parameter is still required if you are using Oracle Enterprise Manager to manage the database.

Because the listener always knows the state of the instances, service registration facilitates automatic failover of the client connect request to a different instance if one instance is down.

In a static configuration model, a listener would start a dedicated server upon receiving a client request. The server would later find out that the instance is not up, causing an » Oracle not available » error message.

Service registration enables the listener to forward client connect requests to the least loaded instance and dispatcher or dedicated server. Service registration balances the load across the service handlers and nodes.

Oracle Enterprise Manager tools require static service configuration in the listener.ora file.

Listener Configuration During Installation

Oracle Universal Installer launches Oracle Net Configuration Assistant during software installation. Oracle Net Configuration Assistant enables you to configure the listening protocol address and service information for an Oracle database.

During an Enterprise Edition or Standard Edition installation on the database server, Oracle Net Configuration Assistant automatically configures a listener with a name of LISTENER that has a TCP/IP listening protocol address for the Oracle database. During a Custom installation, Oracle Net Configuration Assistant prompts you to configure a listener name and a protocol address of your choice.

Additionally, a listening IPC protocol address for external procedure calls is automatically configured, regardless of the installation type.

Oracle Net Configuration Assistant also automatically configures service information for the Oracle database and the external procedures in the listener.ora file.

While service information is not required in the listener.ora file, Oracle Net Configuration Assistant assumes that you are using Oracle Enterprise Manager to monitor the database. Oracle Enterprise Manager requires this information to discover the database.

Figure 12-1 Example listener.ora File

Oracle9i Net Services Reference Guide for further information about identifying listeners by unique names and creating multiple listener entries in the listener.ora file

Customizing Listener Configuration

If the default or installed configuration is not adequate for a particular environment, you can use Oracle Net Manager to customize the listener.ora configuration.

This section contains these configuration topics:

Configuring Listening Protocol Addresses

To configure additional protocol addresses for the listener:

If a listener has never been created:

The Choose Listener Name dialog box appears.

A new Address tab appears.

When configuring the listener to listen on TCP/IP, you should enter the default port of 1521. If you do not, you must configure the LOCAL_LISTENER parameter in the initialization parameter file and resolve the listener name through a naming method.

If the computer has more than one IP address and you want the listener to listen on all available IP addresses, configure TCP/IP or TCP/IP with SSL and enter the host name of the computer in the Host field.

Configuring Access to Oracle JServer

Clients access Enterprise JavaBeans (EJBs) and Common Object Request Broker Architecture (CORBA) applications, provided with the Oracle JServer option, in an Oracle8 i database over an Inter-Orb Protocol (IIOP) connection. IIOP is an implementation of General Inter-Orb Protocol (GIOP) over TCP/IP. To support access to CORBA and EJB, you configure the listener with a protocol address with port 2481 for TCP/IP or port 2482 for TCP/IP with SSL.

To configure a protocol address for Oracle JServer in an Oracle8 i database:

A new Address tab appears.

The listener.ora file updates with the following:

Oracle8i Enterprise JavaBeans Developer’s Guide and Reference for complete instructions for configuring client connections to EJB and CORBA applications

Handling Large Volumes of Concurrent Connection Requests

If you expect the listener to handle large volumes of concurrent connection requests, then you can specify a listener queue size for its TCP/IP listening endpoints. To specify the listener queue size, specify the QUEUESIZE parameter at the end of the protocol address with its value set to the expected number of concurrent requests. For example:

Figure 12-2 listener.ora File with Queue Size

The default number of concurrent connection requests is system specific. Following are the defaults for the Solaris Operating System and Windows NT:

Configuring Static Service Information

In order for the listener to accept client connect requests to an Oracle8 release 8.0 or Oracle7 database, you must configure the listener.ora file with information about the database. Static configuration is also required for other services, such as external procedures, Heterogeneous Services, and some management tools, including Oracle Enterprise Manager.

For Oracle9 i and Oracle8 i databases, the listener uses the dynamic service information about the database and instance it has received through service registration before using statically configured information in the listener.ora file.

Table 12-1 describes static service settings that you can set in the listener.ora file.

Table 12-1 Static Service Settings in listener.ora

Use to specify the Oracle System Identifier (SID) of the instance. You can obtain the SID value from the INSTANCE_NAME parameter in the initialization parameter file.

Global Database Name

Use to identify the database service.

While processing a client connection request, the listener tries to match the value of this parameter with the value of the SERVICE_NAME parameter in the client connect descriptor. If the client connect descriptor uses the SID parameter, then the listener does not attempt to map the values. This parameter is primarily intended for configurations with Oracle8 release 8.0 or Oracle7 databases (where dynamic service registration is not supported for dedicated servers). This parameter may also be required for use with Oracle9 i and Oracle8 i database services by some configurations and management tools.

Oracle Home Directory

On UNIX, this setting is optional. Use it specify the Oracle home location of the instance. Without this setting, the listener assumes its Oracle home for the instance.

On Windows NT, this settings is ignored. The Oracle home specified by the ORACLE_HOME parameter in HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME ID of the Windows NT registry is used.

If you are using connect-time failover or Transparent Application Failover (TAF), such as in an Oracle9 i Real Application Cluster environment, then do no set the GLOBAL_DBNAME parameter.

To statically configure the listener:

A new Database tab appears.

Table 12-1 for a description of the fields

For example, an excerpt of a listener.ora file statically configured for a database service called sales.us.acme.com looks like this:

Configuring Password Authentication for the Listener

If you are administering the listener remotely over an insecure network and require maximum security, configure the listener with a secure protocol address that uses the TCP/IP with SSL protocol. If the listener has multiple protocol addresses, ensure that the TCP/IP with SSL protocol address is listed first in the listener.ora file.

It is important to provide security through a password for the listener. With a password, privileged operations, such as saving configuration changes or stopping the listener, used from the Listener Control utility will require a password.

Use the Listener Control utility’s CHANGE_PASSWORD command or the Oracle Net Manager to set or modify an encrypted password in the PASSWORDS_ listener_name parameter in the listener.ora file. If the PASSWORDS_ listener_name parameter is set to an unencrypted password, you must manually remove it from the listener.ora file prior to modifying it. If the unencrypted password is not removed, you will be unable to successfully set an encrypted password.

To set or modify an encrypted password with Oracle Net Manager:

To set a new encrypted password with the CHANGE_PASSWORD command, issues the following commands from the Listener Control utility:

Bold denotes user input. The password is not displayed when entered.

To modify an encrypted password with the CHANGE_PASSWORD command:

Oracle9i Net Services Reference Guide for further information about the CHANGE_PASSWORD command

Configuring Service Registration

For Oracle9 i and Oracle8 i databases, the listener uses the dynamic service information about the database and instance it has received through service registration before using statically configured information in the listener.ora file. Dynamic service registration is configured in the database initialization file. It does not require any configuration in the listener.ora file. However, listener configuration must be synchronized with the information in the database initialization file.

This section contains the following configuration topics related to service registration:

Configuring Service Registration

To ensure service registration works properly, the initialization parameter file should contain the following parameters:

The value for the SERVICE_NAMES parameter defaults to the global database name, a name comprising the DB_NAME and DB_DOMAIN parameters in the initialization parameter file, entered during installation or database creation. The value for the INSTANCE_NAME parameter defaults to the SID entered during installation or database creation.

Oracle9i Database Reference for further information about the SERVICE_NAMES and INSTANCE_NAME parameters

Registering Information with the Default, Local Listener

By default, the PMON process registers service information with its local listener on the default local address of TCP/IP, port 1521. As long as the listener configuration is synchronized with the database configuration, PMON can register service information with a nondefault local listener or a remote listener on another node. Synchronization is simply a matter of specifying the protocol address of the listener in the listener.ora file and the location of the listener in the initialization parameter file.

Registering Information with a Nondefault Listener

If you want PMON to register with a local listener that does not use TCP/IP, port 1521, configure the LOCAL_LISTENER parameter in the initialization parameter file to locate the local listener.

For a shared server environment, you can alternatively use the LISTENER attribute of the DISPATCHERS parameter in the initialization parameter file to register the dispatchers with a nondefault local listener. Because both the LOCAL_LISTENER parameter and the LISTENER attribute enable PMON to register dispatcher information with the listener, it is not necessary to specify both the parameter and the attribute if the listener values are the same.

Set the LOCAL_LISTENER parameter as follows:

Set the LISTENER attribute as follows:

listener_alias is then resolved to the listener protocol addresses through a naming method, such as a tnsnames.ora file on the database server.

For example, if the listener is configured to listen on port 1421 rather than port 1521, you can set the LOCAL_LISTENER parameter in the initialization parameter file as follows:

Using the same listener example, you can set the LISTENER attribute as follows:

You can then resolve listener1 in the local tnsnames.ora as follows:

If you set the parameter to null with the statement that follows, then the default local address of TCP/IP, port 1521 is assumed.

See the Oracle9i SQL Reference for further information about the ALTER SYSTEM SET statement.

To register information with another local listener:

Registering Information with a Remote Listener

Registration to remote listeners, such as in the case of Oracle9 i Real Application Clusters, can be configured for shared server or dedicated server environments.

If you want PMON to register with a remote listener, configure the REMOTE_LISTENER parameter in the initialization parameter file to locate the remote listener.

For a shared server environment, you can alternatively use the LISTENER attribute of the DISPATCHERS parameter in the initialization parameter file to register the dispatchers with any listener. Because both the REMOTE_LISTENER parameter and the LISTENER attribute enable PMON to register dispatcher information with the listener, it is not necessary to specify both the parameter and the attribute if the listener values are the same.

Set the REMOTE_LISTENER parameter as follows:

Set the LISTENER attribute as follows:

listener_alias is then resolved to the listener protocol addresses through a naming method, such as a tnsnames.ora file on the database server.

You can set the REMOTE_LISTENER parameter in the initialization file for the instance on host sales2-server as follows:

You can then resolve listener_sales2 in the local tnsnames.ora on sales1-server as follows:

Likewise, you can resolve listener_sales1 in the local tnsnames.ora on sales2-server as follows:

If shared server is configured, you can set the DISPATCHERS parameter in the initialization parameter file as follows:

You can then resolve listener_sales in the local tnsnames.ora as follows:

If you set the parameter to null with the statement that follows, then PMON de-registers information with the remote listener with which it had previously registered information.

See the Oracle9i SQL Reference for further information about the ALTER SYSTEM SET statement.

To register information with remote listener:

Configuring a Naming Method

The listener name alias specified for the LOCAL_LISTENER parameter, REMOTE_LISTENER parameter, or LISTENER attribute can be resolved through one of the following naming methods:

tnsnames.ora File

A net service name entry should be created for the protocol address without the CONNECT_DATA section of the connect descriptor. Oracle Net Manager does not enable you to configure a tnsnames.ora file without the CONNECT_DATA information. Therefore, Oracle Corporation recommends that you manually modify the tnsnames.ora file.

For example, if LOCAL_LISTENER is set to listener1 and listener1 uses TCP/IP on port 1421, the entry in the tnsnames.ora file would be:

Multiple addresses are supported, but connect-time failover and client load balancing features are not supported.

Chapter 15, «Enabling Advanced Features of Oracle Net Services» for further information about multiple address configuration

Oracle Names Server

An entry for the listener alias name can be made to an Oracle Names server through Oracle Net Manager:

Listener Administration

Once the listener is configured, the listener can be administered with the Listener Control utility. This section describes some of the common administrative tasks for the listener, including the following topics:

Oracle9i Net Services Reference Guide for a complete listing of all the Listener Control utility commands and the Oracle Net Manager online help contents

Starting and Stopping the Listener

STOP Command

To stop the listener from the command line, enter:

START Command

To start the listener from the command line, enter:

In addition to starting the listener, the Listener Control utility verifies connectivity to the listener.

Monitoring Runtime Behavior

The STATUS and SERVICES commands provide information about the listener. When entering these commands, follow the syntax as shown for the STOP and START commands.

STATUS Command

The STATUS command provides basic status information about a listener, including a summary of listener configuration settings, the listening protocol addresses, and a summary of services registered with the listener.

You can also obtain the status of a listener through the Oracle Enterprise Manager Console. See the Oracle Enterprise Manager Administrator’s Guide for further information.

The STATUS command generates output with the sections described in Table 12-2.

Table 12-2 Listener Control Utility STATUS Command

STATUS of the LISTENER

Specifies the following:

Listening Endpoints Summary

Lists the protocol addresses the listener is configured to listen on

Displays a summary of the services registered with the listener and the service handlers allocated to each service

Identifies the registered service

Specifies the name of the instance associated with the service along with its status and number of service handlers associated with the service

Status can be one of the following:

Figure 12-3 shows example output of the STATUS command.

Figure 12-3 Listener Control Utility’s STATUS Command Output

SERVICES Command

The SERVICES command provides detailed information about the services and instances registered and the service handlers allocated to each instance.

The SERVICES command generates output with the sections described in Table 12-3.

Table 12-3 Listener Control Utility SERVICES Command

Identifies the registered service

Specifies the name of the instance associated with the service

The status field indicates if the instance is able to accept connections.

This section also identifies the following about the service handler:

— A READY state means that the service handler can accept new connections.

— A BLOCKED state means that the service handler cannot accept new connections.

Following this, additional information about the service handler displays, such as whether the service handler is a dispatcher, a local dedicated server, or a remote dedicated server on another node.

Figure 12-4 shows example output of the SERVICES command.

Figure 12-4 Listener Control Utility’s SERVICES Command Output

Client connection requests to hr.us.acme.com are handled by one dispatcher named D001 and one dedicated server.

Monitoring Log Files

When you notice any of the following conditions, review and monitor the listener log file for the following:

Источник

• ← Что значит основа слова
• Увеличение плоского эпителия в моче о чем это говорит →