Oracle Essentials Oracle Database 11g (15 page)

Oracle Net Manager

In Oracle8, Oracle provided a GUI utility called the Net8 Assistant used to create the various configuration files required for Net8; this utility was renamed the Oracle Net Manager with the Oracle9
i
release.

Like the Database Configuration Assistant, the Oracle Net Manager is written in Java, provides the same look and feel across platforms, and is typically first accessed from the installer. The Oracle Net configuration files have a very specific syntax with multiple levels of nested brackets. Using the Oracle Net Manager allows you to avoid the errors that are common to hand-coded files. This utility, which automates the configuration of various Oracle Net components, is shown in
Figure 3-4
as it appears in Oracle Database 11
g
.

Figure 3-4. Oracle Net Manager

Debugging Network Problems

If you’re having a problem with your network, one of the first steps toward debugging the problem is to check that the Oracle Net files were generated, not hand-coded. If you’re in doubt, back up the current configuration files and use the Oracle Net Manager to regenerate them. In fact, when Oracle Support assists customers with Oracle Net problems, one of the first questions they ask is whether or not the files were handcoded.

66

|

Chapter 3: Installing and Running Oracle

Auto-Discovery and Agents

Beginning with Oracle 7.3, Oracle provided auto-discovery features that allowed it to find new databases automatically. Support for auto-discovery increased and improved with each Oracle release since then. Since Oracle8
i
, the Universal Installer and Oracle Net Manager work together smoothly to automatically configure your Oracle Net network.

A key piece of the Oracle network that enables auto-discovery is the Oracle Intelligent Agent. The agent is a piece of software that runs on the machine with your Oracle database(s). It acts as an agent for other functions that need to find and work with the database on the machine. For example, the agent knows about the various Oracle instances on the machine and handles critical management functions, such as monitoring the database for certain events and executing jobs. The agent provides a central point for auto-discovery: Oracle Net discovers instances and databases by interrogating the agent. We’ll examine the general use of agents and their role in

managing Oracle in Chapter 5.

Oracle Net Configuration Files

Oracle Net requires several configuration files. The default location for the files used to configure an Oracle Net network are as follows:

• On Windows,
ORACLE_HOME\net80\admin
for Oracle8 and
ORACLE_

HOME\network\ admin
for Oracle8
i
and more current releases

• On Unix,
ORACLE_HOME/network/admin

Youcan place these files in another location, in which case youmust set an environment or system variable called TNS_ADMIN to the nondefault location. Oracle then uses TNS_ADMIN to locate the files. The vast majority of systems are configured using the default location.

The files that form a simple Oracle Net configuration are as follows:
LISTENER.ORA

Contains details for configuring the Oracle Net Listener, such as which instances or services the Listener is servicing. As the name implies, the Listener “listens” for incoming connection requests from clients that want to access the Oracle database over the network. For details about the mechanics of the Listener’s function,

see the later section “Oracle Net and Establishing Network Connections.”

TNSNAMES.ORA

Decodes a service name into a specific machine address and Oracle instance for the connection request. (If you’re using Oracle Names or OID, as described earlier, youdon’t need to use the
TNSNAMES.ORA
file as part of your configuration.) This file is key to Oracle Net’s location transparency. If youmove a database from one machine to another, youcan simply update the
TNSNAMES.

Configuring Oracle Net

|

67

ORA
files on the various clients to reflect the new machine address for the existing service name. For example, suppose that clients reach the database using a service name of SALES. The
TNSNAMES.ORA
file has an entry for the service name SALES that decodes to a machine named HOST1 and an Oracle instance called PROD. If the Oracle database used for the SALES application is moved to a machine called HOST2, the
TNSNAMES.ORA
entry is updated to use the machine name HOST2. Once the
TNSNAMES.ORA
files are updated, client connection requests will be routed transparently to the new machine with no application changes required.

SQLNET.ORA

Provides important defaults and miscellaneous configuration details. For example,
SQLNET.ORA
contains the default domain name for your network.

LDAP.ORA

For Oracle8
i
and later releases, the
LDAP.ORA
file contains the configuration information needed to use an LDAP directory, such as the Oracle Internet Directory. This information includes the location of the LDAP directory server and the default administrative context for the server. This is no longer required for an LDAP server that is registered with the Domain Name Server (DNS) since Oracle Database 10
g
.

As mentioned in
Chapter 2,
Oracle9
i
added a server parameter file, named
SPFILE
, which provides storage for system parameters youhave changed while your Oracle9
i
instance is running, using the ALTER SYSTEM command. With the
SPFILE
, these new parameter values are preserved and used the next time you restart your Oracle instance. Youcan indicate whether a particu

lar change to a system parameter is

intended to be persistent (in which case it will be stored in the
SPFILE
) or temporary.

The
SPFILE
is a binary file that is kept on the server machine. By default, an Oracle9
i
or later instance will look for the
SPFILE
at startup and then for an instance of the
INIT.ORA
file.

The
SPFILE
can also be kept on a shared disk, so that it can be used to initialize multiple instances in an Oracle Real Application Clusters configuration.

Starting Up the Database

Starting a database is quite simple—on Windows you simply start the Oracle services (or specify that the services are started when the machine boots), and on Unix and Linux you issue the STARTUP command from SQL*Plus, or through Enterprise Manager. While starting a database appears to be a single action, it involves an instance and a database and occurs in several distinct phases. When you start a database, the following actions are automatically executed:

68

|

Chapter 3: Installing and Running Oracle

1.
Starting the instance
. Oracle reads the instance initialization parameters from the
SPFILE
or
INIT.ORA
file on the server. Oracle then allocates memory for the System Global Area and starts the background processes of the instance. At this point, none of the physical files in the database have been opened, and the instance is in the NOMOUNT state. (Note that the number of parameters that must be defined in the
SPFILE
in Oracle Database 10
g
and Oracle Database 11
g
as part of the initial installation setup have been greatly reduced. We described the initialization parameters required in Oracle Database 11
g
in Chapter 2.)

There are problems that can prevent an instance from starting. For example, there may be errors in the initialization file, or the operating system may not be able to allocate the requested amount of shared memory for the SGA. You also need the special privilege SYSOPER or SYSDBA, granted through either the operating system or a password file, to start an instance.

2.
Mounting the database
. The instance opens the database’s control files. The initialization parameter CONTROL_FILES tells the instance where to find these control files. At this point, only the control files are open. This is called the MOUNT state, and the database is accessible only to the database administrator.

In this state, the DBA can perform only certain types of database administration.

For example, the DBA may have moved or renamed one of the database files. The datafiles are listed in the control file but aren’t open in the MOUNT state. The DBA can issue a command (ALTER DATABASE) to rename a datafile. This command will update the control file with the new datafile name.

3.
Opening the database
. The instance opens the redo log files and datafiles using the information in the control file. At this point, the database is fully open and available for user access.

Shutting Down the Database

Logically enough, the process of shutting down a database or making it inaccessible involves steps that reverse those discussed in the previous section: 1.
Closing the database
. Oracle flushes any modified database blocks that haven’t yet been written to the disk from the SGA cache to the datafiles. Oracle also writes out any relevant redo information remaining in the redo log buffer. Oracle then checkpoints the datafiles, marking the datafile headers as “current” as of the time the database was closed, and closes the datafiles and redo log files. At this point, users can no longer access the database.

2.
Dismounting the database
. The Oracle instance dismounts the database. Oracle updates the relevant entries in the control files to record a clean shutdown and then closes them. At this point, the entire database is closed; only the instance remains.

3.
Shutting down the instance
. The Oracle software stops the background processes of the instance and frees, or deallocates, the shared memory used for the SGA.

Shutting Down the Database

|

69

In some cases (e.g., if there is a machine failure or the DBA aborts the instance), the database may not be closed cleanly. If this happens, Oracle doesn’t have a chance to write the modified database blocks from the SGA to the datafiles. When Oracle is started again, the instance will detect that a crash occurred and will use the redo logs to automatically perform what is called
crashrecovery
. Crash recovery guarantees that the changes for all committed transactions are done and that all uncommitted or in-flight transactions will be cleaned up. The uncommitted transactions are determined after the redo log is applied and automatically rolled back.

Accessing a Database

The previous sections described the process of starting up and shutting down a database. But the database is only part of a complete system—you also need a client process to access the database, even if that process is on the same physical machine as the database.

Server Processes and Clients

To access a database, a user connects to the instance that provides access to the desired database. A program that accesses a database is really composed of two distinct pieces—a client program and a server process—that connect to the Oracle instance. For example, running the Oracle character-mode utility SQL*Plus involves two processes:

• The SQL*Plus process itself, acting as the client

• The Oracle server process, sometimes referred to as a
shadow process
, that provides the connection to the Oracle instance

Server process

The Oracle server process always runs on the computer on which the instance is running. The server process attaches to the shared memory used for the SGA and can read from it and write to it.

As the name implies, the server process works for the client process—it reads and passes back the requested data, accepts and makes changes on behalf of the client, and so on. For example, when a client wants to read a row of data stored in a particular database block, the server process identifies the desired block and either retrieves it from the database buffer cache or reads it from the correct datafile and loads it into the database buffer cache. Then, if the user requests changes, the server process modifies the block in the cache and generates and stores the necessary redo information in the redo log buffer in the SGA. The server process, however, does not
70

|

Chapter 3: Installing and Running Oracle

write the redo information from the log buffer to the redo log files, and it does not write the modified database block from the buffer cache to the datafile. These actions are performed by the Log Writer (LGWR) and Database Writer (DBWR) processes, respectively.

Client process

The client process can run on the same machine as the instance or on a separate computer. A network connects the two computers and provides a way for the two processes to talk to each other. In either case, the concept is essentially the same—

two processes are involved in the interaction between a client and the database.

When both processes are on the same machine, Oracle uses local communications via Inter Process Communication (IPC); when the client is on one machine and the database server is on another, Oracle uses Oracle Net over the network to communicate between the two machines.

Application Servers and Web Servers As Clients

Although the discussion in the previous section used the terms
client
and
server
extensively, please don’t assume that Oracle is strictly a client/server database. Oracle was one of the early pioneers of client/server computing based on the notion of two tasks: a client and a server. But when you consider multitier computing involving web and application servers, the notion of a client changes somewhat. The

“client” process becomes the middle tier, or application server.

Youcan logically consider any process that connects to an Oracle instance a client in the sense that it is served by the database. Don’t confuse this usage of the term
client
with the actual client in a multitier configuration. The eventual client in a multitier model is some type of program providing a user interface—for example, a browser running Java.