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

Due to the problem of 12c snooping registration, I would like to share some previous learning articles about the oracle 12c lreg process:

The pmon process has been undertaking a lot of work in the oracle database, such as cleaning up the process and monitoring registration, which means that a person needs to do several tasks at the same time, and when he is overwhelmed with one of them, it may affect the other tasks it is responsible for. The 11g R2 version of the database has encountered exceptions in service updates and service registration due to the pmon process being busy cleaning up abnormally interrupted sessions.

In previous versions of oracle12c, service registration has always been the responsibility of the PMON process, since 12c oracle introduced the LREG (listener registration) background process to take over this part of the work to reduce the work of PMON.

I. Oracle snooping and service registration:

In Oracle, a listener is a server-side process that monitors connection requests to clients and establishes and manages sessions. At different times after the database instance starts, the database instance contacts the listener and establishes a communication path to the instance.

Service registration allows listeners to determine whether the database service and its service handlers (service handlers) are available. During registration, the service registration process provides listener with the instance name, database service name, and the type (private or shared) and address of the service handlers.

Before oracle 12c, the pmon process was responsible for service registration:

After 12c, the service registration is replaced by the LREG process:

The listener cannot register the service without starting the LREG process, but the LREG process will regularly try to register. If local_listener is not configured, LREG will try to connect to the default port 1521 until the listener process starts. After the listener starts, the LREG can also register the service .litener registration information immediately using "alter system register" before periodic registration. In fact, this process is a dynamic registration process.

Another thing to note is that if the LREG process dies, it will be the same as pmon, and the database instance will crash. 12c the ora-500,ora-500 directly reported is to listen for the registration process to die.

Two. research on the working process of dynamic registration:

1. Use oradebug Event 10257 trace name context forever, level 1 6 to bring the lreg dump out. You can initially see the working process of lreg:

As can be seen from the information from dump, the lreg process updates its status every 3 seconds, and the instance information is registered about every 60 seconds. Below, if the monitoring is not started, the number of successes after LREG woken up to process network events after 0 cs is still 0, indicating that the registration cannot be successful at this time.

When the monitor is activated, the next registration after 60 seconds can be successfully registered.

two。 Use strace to track the work of the lreg process

When the database is running, a lot of things happen behind it, and the database is also an application software, all of which can be traced back to the working principle of the operating system. Before tracking lreg processes, you may need to understand two concepts in orcle snooping dynamic registration: file descriptors and Sockets files.

When the listening process starts, it creates two socket files under / var/tmp/.oracle.

These files are socket files, and 12214 in saw12214.1 is the process number, then it should be the listening process number. These socket documents are used for local client process communication using interprocess communication protocol (ipc) and different oracle, and these processes include: tns listener, css, crs, evm daemon; and even database and asm instance. These socket are created by processes that are actively listening. Here oracle snooping creates these socket files primarily for lreg and tnslsnr communication.

At the same time, several file descriptors are created under the corresponding process number file in the / proc directory. These file descriptors (file descriptor) are indexes created by the kernel to efficiently manage opened files, which are non-negative integers (usually small integers) that refer to opened files, and all system calls that perform the Icano operation pass through the file descriptor.

We can see that there are several file descriptors, so make sure there are file descriptors and sockets created for the process.

What about the dynamic registration of LREG procedures (previous versions of PMON) related to file descriptors and sockets files?

These processes use system calls to see if the listener is started, wait if no listener process is found, and try again after 3000 milliseconds. Until the listening startup, the file descriptor is opened by listening and bound by the process to establish a connection between each other.

To find out what the LREG process is doing, I use the STRACE OS utility to track its work. The output of the PMON process in 11g is not exactly the same because it is not a process specifically used to register instances in the listener. On the other hand, the sole purpose of LREG is to register dynamically, which explains the difference between the system calls used between the two processes.

The following is the log of the STRACE LREG process:

From the strace log above, you can see that the main call to the epoll_wait () function represents the time it takes to pass through the file descriptor to wait for a certain Icano event to occur. In fact, this is a continuous wait for the generation of an IO event, and when the table appears to the database layer, it should be understood as the process of monitoring whether the listening process is started. The time shown in the last parameter of epoll_wait (7, {}, 1024, 3000) is 3000 milliseconds (that is, 3 seconds).

Explanation of epoll_wait:

The next two lines of the getrusage () function represent the resource usage consumption, while the latter times () returns the time for the time function. In the previous time print, you can clearly see that the function is held every 3 seconds.

Further down is the socket function followed by a value of 10, which means that a socket function is used to process the file descriptor 10. Guess that this is the file descriptor used to establish a connection with the listener process. The socket used here is NETLINK, which creates a connection between the kernel and the network layer.

Take a closer look at the following function, which is an attempt to bind the file descriptor 10 returned by the previous function.

In the next few lines, this file descriptor will be used to connect to PID 2582, which is the PID of the LREG process.

Trying to establish a connection to IP address 127.0.0.1, port number is 1521.

Because the listening process is not started, and there is no file descriptor 10 associated with the process LREG, the connection is rejected, that is, no connection is established.

After starting the monitoring, lreg found that the monitoring, and can establish a normal connection, but did not report a rejected error.

More epoll_ctl and epoll_wait function calls can be seen in the above log of lreg process activity. Here, epoll seems to be a process that constantly triggers listening and manipulating certain file descriptions. Lreg calls epoll_wait every 3 seconds to monitor whether the listening process is started, and use epoll_ctl to add and delete a file descriptor when registration occurs. The details are really impossible to understand for the time being.

After the listener starts, you can use the lsof-I TCP:1521 command to see the connection between the lreg process and the tnslsnr process.

ESTABLISHED means to establish a connection. Indicates that two processes are communicating. Ncube-lm is nCube License Manager (that is, a license managed by ncube), which means to be allowed, to be certified and open, which is opened by tnslnr and is in the LISTEN state.

III. Summary:

Except for service registration, oracle 12c's network service architecture has not changed in the database. In previous versions, service registration was done through the PMON process. Now LREG (listener registration) handles it. LREG is an instance-level background process and is very important. Once the process is killed, it will cause the database instance to crash. It will do everything PMON has done in the past in terms of instance registration, such as service_update, service_register, service_died in the listening log listener.log.

Due to the specialization of the work, we can have a clearer understanding of the process of its work, such as monitoring every 3 seconds, trying to register every 60 seconds, etc.

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.