To use a tnsnames.ora file, you use the name of the entry you placed in the file. The client software (SQL*Plus in this example) looks by default in the directory $ORACLE_ HOME/network/admin for the tnsnames.ora file for the connection details associated with the ORCL entry, and uses that information to connect me to my pluggable database:
$ sqlplus scott/tiger@ORCL
And listed next is what the connection to a database in Oracle’s cloud looks like now:
$ sqlplus scott/tiger@OCLD
The strings (ORCL or OCLD in these prior examples) could have been resolved in other ways. For example, it could have been resolved using a naming service provided by the Lightweight Directory Access Protocol (LDAP) server, similar in purpose to DNS
for hostname resolution. However, the use of the tnsnames.ora file is common in most small to medium installations (as measured by the number of hosts that need to connect to the database) 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 specified hostname and port. The connection to the instance on my laptop uses a hostname of localhost and a port of 1521 (the default port and can be configured on other ports). If the DBA (me) 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 (because there is no such service, e.g., 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/Linux, this is achieved via fork() and exec() system calls (the only way to create a new process after initialization in UNIX/Linux 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/Linux, it would look as shown in Figure 2-8.
However, 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 OS 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 also accept 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-9 illustrates this process.
Figure 2-9. The listener process and shared server connections
From the client’s perspective, it doesn’t care or know if it’s making a dedicated server or shared server connection. The end result should be a successful connection to the database instance so that the client can interact with the database.
Summary
This completes our overview of the Oracle architecture. In this chapter, we defined the terms database, instance, container database, pluggable database, real application cluster (RAC) database, and sharded database. It’s especially important to understandOracle’s multitenant architecture as this is the recommended Oracle architecture going forward. The use of non-CDB databases will be desupported by Oracle at some point in the future.
We also saw how to connect to the database through either a dedicated server connection or a shared server connection. It’s worth noting that an Oracle instance may use both connection types simultaneously. In fact, an Oracle database always supports dedicated server connections—even when configured for a shared server.
Now you’re ready to take a more in-depth look at the files that comprise the database and the processes behind the server—what they do and how they interact with each other. You’re also ready to look inside the SGA to see what it contains and what its purpose is. You’ll start in the next chapter by looking at the types of files Oracle uses to manage the data, and the role of each file type.
