Oracle Database Connection Methods

There are three ways to access the Oracle database: the first is to directly access the shared memory of the database instance by the application process, and the second is to access the database on the local machine through the beq protocol, the third method is access through the network protocol. The first method is rarely used. We will not discuss it. The following focuses on accessing the database through the second and third methods.

First, the last two methods of accessing the database are based on the two-task structure. You must create a service process (server process or foreground process) on the database server) to serve the client application (here we will only discuss the independent server mode. The Shared Server mode is very similar and we will describe it later ). To access the database in the two-task architecture, you must first create a process on the server. when starting a process, you must first map the shared memory, then, the Session Initialization can be completed through the internal data structure in the shared memory.

On the local machine, the database is connected without SQL * Net. The frontend and user processes communicate with each other through the IPC Mechanism. The communication protocol is the famous Bequeath protocol, or BEQ protocol. If you connect to the database through SQL * Net, you need to use the network protocol. The TCP/IP protocol has become the most widely used protocol. Therefore, we mainly face the TCP/IP protocol. More than 10 years ago, the famous SPX protocol, DECnet protocol, and Token Ring Protocol were once the DBA Process configuration protocols. Socket communication is used between front-end processes and user processes using SQL * Net. In fact, on the server, we can also use SQL * Net to connect to the database, but we seldom do this, because the BEQ protocol is more efficient than Socket communication.

In addition to the different protocols used, is there any difference between connecting a database instance through the BEQ protocol on the local machine and connecting a database instance through SQL * Net? Many DBAs may feel different, because the database protocol is directly connected on the local machine, the foreground process is a sub-process generated by the shell Process, and the database instance is connected through SQL * Net, the server process is a sub-process generated by LISTENER (tnslsnr). If the attributes of the LISTENER process are different, the sub-process generated will be different from the sub-process directly generated by shell. This difference exists in earlier Oracle versions, but since the $ ORACLE_HOME/bin/oracle image file is set to the s attribute, this problem does not exist. Oracle images use the s attribute to convert attributes of sub-processes to Oracle users.

However, the BEQ protocol and network protocol are different in terms of service processes. The BEQ protocol communicates through IPC, so you do not need to use Socket and connect through the network protocol (SQL * Net, the customer process is initially connected to the tnslsnr process. After the tnslsnr process accepts the connection request, it creates a sub-process for it and notifies the client process to reconnect to the sub-process to continue working. At this time, there is a Socket redirection problem. When a listener generates a sub-process, it allocates an unused port number for the new connection. After the sub-process is started, it listens on the port and notifies the client process, it is required to redirect to the new port number. In this case, the client process closes the old Socket and opens a new Socket to complete the login operation.

Some DBAs may be confused about the above discussion. How can we discuss the instance problem and suddenly turn to the working mechanism of the listener? What role does this knowledge play to DBAs? We have been emphasizing that the instance is the channel through which the client accesses the database. Therefore, it is very meaningful to discuss how the client connects to the database through the listener.

First, many customers have high requirements on system security. Therefore, a large number of network ports on the server are blocked and only required. So for Oracle databases, we only need to open the port needed by the listener? In fact, this is not the case. Apart from opening listening ports similar to 1521, we also need to open some high ports which will be used for Socket redirection.

May be many users in the client connection to the database often encounter errors such as TNS-12535, always from the network timeout point of view, however, such analysis is often difficult to find the real cause of failure. In a firewall environment, this type of problem is often caused by Socket redirection in the firewall environment, especially for Firewalls with NAT functions. The client is connected to an IP address after NAT translation. During redirection, the listener requires the client to connect to the real IP address, which causes connection timeout. In this case, the general solution is to use connect manager (CMAN). laobai has encountered several such customers and finally solved the problem through CMAN.