Oracle Listener Understanding

Original website: http://www.360doc.com/content/11/0412/10/6670178_109025796.shtml

Oracle Listener Listener is an important database server component that plays an important role throughout the Oracle architecture. It manages the communication between the Oracle database and the client, listens for connection requests on a specific NIC port (TCP 1521 by default), and forwards the connection to the database, and the following sections briefly describe the listener in several ways.

1. function of the Listener

From the current Oracle version, Listener is primarily responsible for the following features:

The
1. listens for client requests. The listener runs on top of the database server and is associated with an Oracle instance (which can be multiple), and is a specialized process that will see the corresponding running process in the Windows service project or Linux running process list. On Windows named Tnslsnr,linux/unix platform is Lsnrctl. The listener waits on the server development port (default: 1521), listening for client requests.
2. assigns Server Process to client requests. The listener is only responsible for receiving requests and then forwarding the request to Oracle Server Process. In Oracle's service model, client processes do not allow direct manipulation of database instances and data, but instead use a service process Server (also known as a Shadow process) as a proxy. After the listener accepts the request, it asks the operating system (or the Dispatcher component) to fork (or assign) a Server Process to connect with the client.
3. To register the instance service. Essentially, Listener is the bridge between establishing the connection between the instance and the client process. The connection between Listener and instances is achieved through the process of registration. The process of registering is the instance telling the listener that its database DB instance name instance_name and the service name Service_names. Listener registration on this information, the client request based on the listening registration information, find the correct service instance name. In the current Oracle version, there are two ways of dynamic registration and static registration.
4. Error transfer failover. Failover is an important aspect of RAC fault tolerance, and its functionality is the ability to automatically transfer requests to other available instances when a DB instance crashes. can provide a large degree of usability (availability) functionality. In this process, the discovery instance has crashed and the request is transferred to another instance, which is a function of Listener.
5. load Balancing measurement. In the RAC architecture, Oracle implements load balancing. When a customer request arrives, Oracle bypasses the higher-load instance and transfers the request to the less-loaded instance for processing based on the load of all instances in the current RAC cluster environment. In earlier RAC versions, the load weight was measured by the number of connections that the listener is currently maintaining, rather than seeing the load of multiple instances in real time. Communicate between listeners in a RAC environment.

2. Operation of the Listener

The listener is available for direct operation on both Windows and Linux/unix platforms. The following are examples of Linux platform operations, similar to other platforms.

In the Command Line window (CMD), enter Lsnrctl to enter the Listener control window.

[Email protected] ~]$ Lsnrctl

Lsnrctl for linux:version 10.2.0.4.0–production on 06-apr-2011 14:31:46
Copyright (c) 1991, Oracle. All rights reserved.
Welcome to Lsnrctl, type ' help ' for information.

Lsnrctl>

You can view the supported listener actions by entering the command help. Here are just a few of the common ones:

To view the current listener status:

By typing status, you can view the status of the current listener, corresponding to the operation log information and service registration information. As follows:

lsnrctl> status

Connecting to (Description= (address= (protocol=tcp) (host=127.0.0.1) (port=1521)))

STATUS of the LISTENER
————————
Alias LISTENER
Version Tnslsnr for Linux:version 10.2.0.4.0–production
Start Date 18-mar-2011 18:03:56
Uptime.-Min. Notoginseng sec
Trace level off
Security on:local OS Authentication
SNMP OFF

Listener Parameter File/home/oracle/product/10.2.0/db_1/network/admin/listener.ora

Listener Log File/home/oracle/product/10.2.0/db_1/network/log/listener.log

Listening Endpoints Summary ...

(Description= (address= (protocol=tcp) (host=127.0.0.1) (port=1521)))
Services Summary ...
The Service "Test" has 2 instance (s).
Instance "Test", status UNKNOWN, have 1 handler (s) for the This service ...
Instance "Test", status ready, have 1 handler (s) for the This service ...
Service "Testxdb" has 1 instance (s).
Instance "Test", status ready, have 1 handler (s) for the This service ...
Service "TEST_XPT" has 1 instance (s).
Instance "Test", status ready, have 1 handler (s) for the This service ...
The command completed successfully

Lsnrctl>

The next few things that require additional attention.

Listener parameter file/home/oracle/product/10.2.0/db_1/network/admin/listener.ora//Parameters used

The listener starts with a parameter file, and of course no parameter file listeners can start, when the listener is acting according to the default behavior. This parameter specifies the location of the listener parameter file, Listener.ora. This file is a text type parameter file that describes the listener listening port, host name, and static registration information. Listener.ora is configured dynamically as the database instance is established and the listener is established.

Listener log file/home/oracle/product/10.2.0/db_1/network/log/listener.log//operation log Location

Listener logs are a repository of records and descriptions of listener work and errors. By carefully studying the log content, you can help us discover current listener issues, troubleshoot connection failures, and understand how listeners work.

As already noted above, the listener has a registration function, with the status command (the same effect as the Services command). You can see what services are currently being registered and used to check the connection service failure, which is a common tool.

To turn the listener on/off:

The listener's behavior is controlled by the parameter file, and we sometimes need to adjust the listener's parameters. The method of adjusting the listening parameters can be done through the GUI interface provided by Oracle, or by manually modifying the Listener.ora.

Because the parameter file Listener.ora is a text file. Oracle for text-type parameter files, in most cases, does not support hot loading. This is true of Pfile and Listener.ora.

The interface GUI is used to configure using the Net configuration Assistant. After the configuration is complete, the configuration program automatically restarts the listener program to load the modified parameter file. If you manually modify the Listener.ora, you have to manually monitor the shutdown and start.

Lsnrctl> stop
Connecting to (Description= (address= (protocol=tcp) (host=127.0.0.1) (port=1521)))
The command completed successfully

Lsnrctl> start
Starting/home/oracle/product/10.2.0/db_1/bin/tnslsnr:please wait ...
Tnslsnr for Linux:version 10.2.0.4.0–production
System parameter File Is/home/oracle/product/10.2.0/db_1/network/admin/listener.ora
Log messages Written To/home/oracle/product/10.2.0/db_1/network/log/listener.log
Listening on: (Description= (Address= (protocol=tcp) (host=127.0.0.1) (port=1521)))
Connecting to (Description= (address= (protocol=tcp) (host=127.0.0.1) (port=1521)))

STATUS of the LISTENER
————————
Alias LISTENER
Version Tnslsnr for Linux:version 10.2.0.4.0–production
Start Date 06-apr-2011 14:35:27
Uptime 0 days 0 hr. 0 min. 0 sec
Trace level off
Security on:local OS Authentication
SNMP OFF
Listener Parameter File/home/oracle/product/10.2.0/db_1/network/admin/listener.ora
Listener Log File/home/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary ...

(Description= (address= (protocol=tcp) (host=127.0.0.1) (port=1521)))
Services Summary ...
The Service "Test" has 1 instance (s).
Instance "Test", status UNKNOWN, have 1 handler (s) for the This service ...
The command completed successfully

Lsnrctl>

Here is a more about the listener parameter configuration. The GUI can be used to satisfy most of the situation, and can avoid the listener failure caused by spelling errors (the listener does not check the configuration item for correctness). However, in some more complex situations, such as the case where a machine is bound to multiple IPs, or the complexity of the configuration of a RAC, it tends to use the manual Listener.ora method.

In addition, the LSNRCTL prompt line provides the reload command to reload file and SID information in the case of Listener startup. But I still prefer the combination of stop+start.

If it is under the Windows platform, launching the shutdown listener can also be done in the list of system service items, with the same effect.

3. The listener's working process

Let's talk about the listener's work process. In general, the listener runs as a standalone process in the operating system, waiting on a specific network port (default: 1521), awaiting the arrival of the client request. Note: When we configure the naming service on the client side, we enter 1521 to establish a connection with the listener program.

When a request "goes as expected", the listener finds the corresponding DB instance information against the list of services already registered, obtaining the Oracle_home path to the specified instance. Equivalent to indicate that a connection can be made.

Client-to-instance interaction is not straightforward and is implemented through Server Process as a proxy intermediary. All instruction SQL is sent to the instance by the client through Server Process, which is an Oracle protection mechanism for instance and database files.

When the listener obtains the request, it assigns a Server Process from the Oracle instance to the corresponding one. There are some differences between the different Oracle connection methods here.

In the case of private connection mode, a client connection corresponds to a Server Process. The listener will ask the OS to fork (create) a Server Process and try to interact with the listener.

In the case of shared connection mode, multiple clients share one Server Process (note: This is not a connection pool). The listener requests a Server process to interact with the Dispatcher process (the process that manages shared mode connections).

The connection between the Server Process and the listener is actually the exchange of information. The Server process sends itself to the listener for processing number and connection address information in the OS. The listener passes the client information to the Server Process.

After the listener obtains information about the Server Process, it returns it to the client connector. After the client obtains the information, it is re-connected, and the server process is contacted based on the information returned.

Until this time, the client program will connect the user name, password and other information to the Server process, login verification and other operations. This is the end of the listener's work.

There is a technical detail, that is, when Server Process is connected to the client, it is allowed to not use port 1521. The specific connected ports are random. In the 9i version of the Windows platform, if the firewall is installed, only allow 1521 port communication, there are some connectivity issues. Fortunately, in other platforms and later versions, a port sharing technology is implemented, and the connection can use port 1521 with the listener.

4. Dynamic/static registration mechanism for listeners

The principle of the listener is introduced, and the mechanism of static registration is described below. In the above content, we have a preliminary understanding of the role of registration, registration is to register the database as a service to the listener. The client does not need to know the database name and the instance name, but only needs to know the service name provided by the database to request a connection to the database. This service name may or may not be the same as the instance name. During database server startup, the database server registers the appropriate service with the listener (whenever a database is started, two messages are registered to the listener by default: the instance and service corresponding to the database server. Equivalent to this: there is a listener between the database server and the client (Listener), in the Listener, the corresponding database corresponding to the service name (a database may have more than one service name), when the client needs to connect to the database, only need to provide a service name, You can establish a connection between the client and the server. Currently, Oracle supports both static and dynamic registration methods.

Static registration as the name implies, is the display of the specified listener program for that instance with which service name for listening. When the listener is started, the listener is unaware of the presence of the instance service being monitored. Until a client requests the specified service.

A static registration is a configuration that reads the Listener.ora file when the instance starts and registers the instance and service with the listener. Whenever a database is started, two messages are registered to the listener by default: the instance and service for the database server.

At static registration, the Global_dbname in the Listener.ora file provides the service name, and the sid_name in the Listener.ora file provides the registered instance name. Here is the structure of a typical parameter file:

# Listener.ora Network Configuration File:/home/oracle/product/10.2.0/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.

Sid_list_listener =
(Sid_list =
(Sid_desc =
(Sid_name = Plsextproc)
(Oracle_home =/home/oracle/product/10.2.0/db_1)
(program = Extproc)
)

(Sid_desc =
(Global_dbname = Test)
(Oracle_home =/home/oracle/product/10.2.0/db_1)
(Sid_name = Test)
)
)

LISTENER =
(Description_list =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = 127.0.0.1) (PORT = 1521))
)
)

The Sid_desc in the Sid_list configuration node is the node project that configures the static registration. The service items used in Sid_list to configure the current listener registration are configured through multiple Sid_desc, and each sid_desc is basically a configuration item. The default is dynamic registration only when the Plsextproc project.

When installed by default, a PL/SQL external program (EXTPROC) entry is installed in Listener.ora, which is the listener that Oracle uses to invoke the default configuration of the external program, whose name is usually ExtProc or plsextproc, but it is generally not used and can be directly from Listener.ora this is removed because there are a number of attacks on ExtProc, and Oracle is also recommended for removal when no external programs are used. Plsextproc is the meaning of PL/SQL external procdure, which is to invoke external statements in PL/SQL, such as the C,java write process. Now that Oracle has full support for Java, it's obsolete, and the reason to keep it is to consider compatibility with older versions of the database instance. Listener.ora can sometimes be copied between multiple DB instances, check to see if the copied files contain unwanted services, and ensure that only the services that are really needed are left, reducing the surface of the listener being attacked. In fact, Oracle DBAs should pay particular attention to the security of the listener, as hackers can easily hack into an Oracle db instance without a security configuration listener. If you want to learn about Oracle listener Security configuration.

In a static configuration project, configure the service project through the Global_name, sid_name specify the name of the DB instance through the Oracle_home configuration for the base directory of the ORACLE database software installation.

Dynamic registration is a method of registration that corresponds to a static registration. It is also configured by Listener.ora. The following is a typical configuration parameter file:

# Listener.ora Network Configuration File:/home/oracle/product/10.2.0/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.

Sid_list_listener =
(Sid_list =
(Sid_desc =
(Sid_name = Plsextproc)
(Oracle_home =/home/oracle/product/10.2.0/db_1)
(program = Extproc)
)
)

LISTENER =
(Description_list =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = 127.0.0.1) (PORT = 1521))
)
)

Comparing the static registration file above, you can find that the item displaying the specified service name and database instance name is missing. Only local address and listener port information.

The dynamically registered action is the completion of the database instance on the host where the listener resides. Dynamic registration is a feature that cannot be turned off by Oracle. The instance's background process Pmon, which registers the parameter information of the instance to the listener at intervals (one minute or two) for dynamic registration.

The registered information is database parameters service_name and instance_name. Can be viewed through the show Parameter command.

Sql> show parameter instance_name;

NAME TYPE VALUE
———————————— ———– ——————————
instance_name string Test

Sql> Show parameter service_names;

NAME TYPE VALUE
———————————— ———– ——————————
Service_names string Test

When the general database is established, both parameters are set and will not be easily changed.

If the instance_name parameter is not set, the system chooses the parameter db_name to be returned as the instance name. If Service_names is not set, the db_name and db_domain two parameters are combined into a service name implementation to register.

A notable problem is that the Service_names parameter is a comma-delimited parameter that can specify multiple service names. That is, an Oracle instance can serve as a service at the same time as multiple service names. Service_Name is a concept that Oracle has proposed in a recent release to replace Sid_name. With service-specific methods, multiple Oracle instances can uniformly provide consistent data access services (that is, RAC).

Typically, the instance_name and service_name two parameters, or the recommended settings. Because it will affect the effect of dynamic registration to some extent.

If the specified two parameters are not displayed, the dynamic registration is done only once when the DB instance is started after the listener instance. Once the listener restarts, the dynamically registered information does not exist and is difficult to register again. Therefore, we recommend that you set these two parameters on the.

Pmon will register the registration information periodically only if it shows a setting of two values. From the command line, you can also force Pmon to perform a registration operation immediately.

Sql> alter system register;
System Altered

Finally, let's talk about the role of dynamic registration, which supports error transfer failover. The initiator of the registration operation is the Pmon background process, Pmon is the most important background process for Oracle instances, and many data and DBAs determine the state of the DB instance in the state of the process. Pmon is responsible for dynamic registration, if not dynamic registration, Pmon has lost the ability to work, it means that the listener service instance has not been able to work.

Through the mechanism of dynamic registration, the listener can know that the server instance served has crashed, and can implement the error transfer for the client's request.

Of course, the crash we're talking about here is an instance of collapse. If the listener program crashes, the situation is another way.

We can use the command Lsnrctl status to see whether a service is registered statically or dynamically. An instance state of UNKNOWN indicates that this service is a statically registered setting. The listener is then used to indicate that it does not know any information about the instance, and only when the client makes a connection request does it check that the instance exists. A dynamically registered database is indicated by the status BLOCKED (for a standby database) in state information. Dynamically registered databases are logged off dynamically from the listener regardless of when the database is closed, and the information associated with them disappears from the status list. This way, the listener always knows its state, regardless of whether the database is running or closed. This information will be used for fallback (fallback) and load balancing of connection requests.

Oracle Listener Understanding