Shulou(Shulou.com)06/02 Report--

Working process of listener

Let's talk about the working process of the listener. Generally, the listener runs as a stand-alone process in the operating system, waiting on a specific network port (default: 1521), waiting for the arrival of client requests. 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 arrives as scheduled, the listener looks up the corresponding database instance information against the list of registered services, and obtains the ORACLE_HOME path of the specified instance. It is equivalent to indicating that a connection can be made.

The interaction between the client and the instance is not direct, but is realized through Server Process as a proxy intermediary. All instructions SQL are sent to the instance by the client through Server Process, and this architecture is a protection mechanism for instance and database files by Oracle.

When the listener gets the request, it allocates a Server Process corresponding to it from the Oracle instance. There are some differences between different Oracle connections.

If it is a dedicated connection mode, that is, a client connection corresponds to a Server Process. The listener then asks OS to fork (create) a Server Process to try to interact with the listener.

In the case of shared connection mode, multiple clients share a Server Process (note: this is not a connection pool yet). The listener then 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. Server Process sends its process number and connection address information in OS to the listener. The listener passes the client information to the Server Process.

After the listener gets the information about the Server Process, it returns it to the client connector. After getting the information, the client will reconnect and contact Server Process at the established server port according to the returned information.

Until this time, the client program will not send the connection user name, password and other information to Server Process for login verification and other operations. This ends the work of the listener.

There is a technical detail, that is, when Server Process connects with the client, it is allowed not to use port 1521. The specific connection port is with random factors. Under the 9i version of Windows platform, if a firewall is installed and only port 1521 is allowed to communicate, it will bring some connection problems. Fortunately, on other platforms and later versions, a port sharing technology has been implemented that allows connections to use port 1521 with listeners.

This paper introduces the working principle of listeners, and let's talk about the mechanism of dynamic and static registration.

Dynamic and static registration mechanism

In the above, we have a preliminary understanding of the role of registration, which is to implement the database instance name and service name to register with the running listener program. The current Oracle supports both static registration and dynamic registration.

Static registration, as the name implies, is that the display specifies which service name the listener program will listen for that instance. When starting the listener, the listener does not know whether the listening instance service exists. Until a client requests the specified service.

Specify that the location of the static registration is in the listener.ora parameter file, which is the structure of a typical parameter file.

# listener.ora Network Configuration File: d:\ 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 = D:\ oracle)

(PROGRAM = extproc)

)

(SID_DESC =

(GLOBAL_DBNAME = orcl)

(ORACLE_HOME = D:\ oracle)

(SID_NAME = orcl)

)

)

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = IPC) (KEY = EXTPROC0))

(ADDRESS = (PROTOCOL = TCP) (HOST = 127.0.0.1) (PORT = 1521))

)

)

Among them, the SID_DESC in the SID_LIST configuration node is the node project that configures static registration. The service items used to configure the current listener registration in SID_LIST are configured through multiple SID_DESC, and each SID_DESC is basically a configuration project. The default is when registering dynamically, only PLSExtProc projects are available.

In the static configuration project, the service project is configured through GLOBAL_NAME, the name of the database instance is specified through SID_NAME, and the basic directory of Oracle database software installation is configured through ORACLE_HOME.

Dynamic registration is a registration method corresponding to static registration. It is also configured through listener.ora. The following is a typical configuration parameter file.

# listener.ora Network Configuration File: d:\ 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 = D:\ oracle)

(PROGRAM = extproc)

)

)

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = www-0e6111dff74) (PORT = 1521))

)

)

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

The action of dynamic registration is completed by the database instance on the host where the listener is located. Dynamic registration is a feature that cannot be turned off on Oracle. The background process PMON of an instance registers the parameter information of the instance with the listener every once in a while (one to two minutes) to achieve dynamic registration.

The registered information is the database parameters service_name and instance_name. You can view it through the Show Parameter command.

SQL > show parameter instance_name

NAME TYPE VALUE

-

Instance_name string orcl

SQL > show parameter service_names

NAME TYPE VALUE

-

Service_names string orcl

In general, when the database is established, these two parameters have been set up and will not change easily.

If the instance_name parameter is not set, the system selects the parameter db_name to return as the instance name. If service_names is not set, the two parameters db_name and db_domain are combined into a service name to implement registration.

One problem worth noting is that the service_names parameter is a parameter that can specify multiple service names, separated by commas. In other words, an Oracle instance can provide services as multiple service names at the same time. Service_name is a concept proposed by Oracle in a recent version to replace SID_NAME. Using the specified method of Service, multiple Oracle instances can provide consistent data access services (that is, RAC).

In general, it is recommended to set the two parameters instance_name and service_name. Because it will affect the effect of dynamic registration to some extent.

If these two parameters are not specified as shown, a dynamic registration will be made only when the database instance is started after the listener instance. Once the listener is restarted later, the dynamic registration information will not exist and it will be difficult to register again. Therefore, we recommend setting these two parameters.

Only when the display sets two values will PMON register the registration information periodically. From the command line, you can also force PMON to perform a registration operation immediately.

SQL > alter system register

2

System altered

Finally, let's talk about the role of dynamic registration to support error transfer failover. The initiator of the registration operation is the PMON background process. PMON is the most important background process of the Oracle instance. Many materials and DBA determine the status of the database instance based on the status of the process. PMON is responsible for dynamic registration. if dynamic registration cannot be carried out, it means that PMON has lost its working ability, which means that the instance served by the listener can no longer work.

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

Of course, the collapse we're talking about here is the collapse of an example. If the listener program crashes, the situation is different.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.