Mechanics of Connecting over TCP/IP

Expert Oracle Database Architecture 9i and 10g Programming Techniques And Solutions - page 60

We’ll investigate the most common networking case: a network-based connection request over a TCP/IP connection. In this case, the client is situated on one machine and the server resides on another machine, with the two connected on a TCP/IP network. It all starts with the client. The client makes a request using the Oracle client software (a set of provided application program interfaces, or APIs) to connect to database. For example, the client issues the following:


$ sqlplus scott/tiger@ora10g.localdomain

Here, the client is the program SQL*Plus, scott/tiger is the username/password, and ora10g.localdomain is a TNS service name. TNS stands for Transparent Network Substrate and is “foundation” software built into the Oracle client that handles our remote connections, allowing for peer-to-peer communication. The TNS connection string tells the Oracle software how to connect to the remote database. Generally, the client software running on yourmachine will read a file called tnsnames.ora. This is a plain-text configuration file commonly found in the [ORACLE_HOME]\network\admin directory ([ORACLE_HOME] represents the full path to your Oracle installation directory). It will have entries that look like this:

ORA10G.LOCALDOMAIN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ora10g)
)

This configuration information allows the Oracle client software to map the TNS connection string we used, ora10g.localdomain, into something useful—namely, a hostname, a port on that host on which a “listener” process will accept connections, the service name of the database on the host to which we wish to connect, and so on. A service name represents groups of applications with common attributes, service level thresholds, and priorities. The number of instances offering the service is transparent to the application, and each database instance may register with the listener as willing to provide many services. So, services are mapped to physical database instances and allow the DBA to associate certain thresholds and priorities with them.
This string, ora10g.localdomain, could have been resolved in other ways. For example, it could have been resolved using Oracle Internet Directory (OID), which is a distributed Lightweight Directory Access Protocol (LDAP) server, similar in purpose to DNS for hostname resolution. However, use of the tnsnames.ora file is common in most small to medium installations where the number of copies of such a configuration file is manageable.
Now that the client software knows where to connect to, it will open a TCP/IP socket connection to the server with the hostname localhost.localdomain on port 1521. If the DBA for our server has installed and configured Oracle Net, and has the listener listening on port 1521 for connection requests, this connection may be accepted. In a network environment, we will be running a process called the TNS listener on our server. This listener process is what will get us physically connected to our database. When it receives the inbound connection request,it inspects the request and, using its own configuration files, either rejects the request (e.g., because there is no such database, or perhaps our IP address has been disallowed connections to this host) or accepts it and goes about getting us connected.
If we are making a dedicated server connection, the listener process will create a dedicated server for us. On UNIX, this is achieved via a fork() and exec() system call (the only way to create a new process after initialization in UNIX is via fork()). The new dedicated server process inherits the connection established by the listener, and we are now physically connected to the database. On Windows, the listener process requests the database process to create a new thread for a connection. Once this thread is created, the client is “redirected” to it, and we are physically connected. Diagrammatically in UNIX, it would look as shown in Figure 2-4.

On the other hand, the listener will behave differently if we are making a shared server connection request. This listener process knows the dispatcher(s) we have running in the instance. As connection requests are received, the listener will choose a dispatcher process from the pool of available dispatchers. The listener will either send back to the client the connection information describing how the client can connect to the dispatcher process or, if possible, “hand off” the connection to the dispatcher process (this is operating system– and database version–dependent, but the net effect is the same). When the listener sends back the connection information, it is done because the listener is running on a well-known hostname and port on that host, but the dispatchers will be accepting connections on randomly assigned ports on that server. The listener is made aware of these random port assignments by the dispatcher and will pick a dispatcher for us. The client then disconnects from the listener and connects directly to the dispatcher. We now have a physical connection to the database.Figure 2-5 illustrates this process.