Files Supporting an Instance

There are a number of files that are used by an instance. The basic files for storing data are discussed in the
next section on data organization. An Oracle instance has its own set of files that do not store user data
but are used to monitor and manage the Oracle instance itself.

Initialization Files
Many parameters exist that affect the way that your Oracle instance operates. These parameters are
typically set and maintained by a database administrator and, as such, are beyond the scope of this book.
The initial values for these parameters are kept in initialization files.

Prior to Oracle9i, each instance had its own specific initialization file called INIT.ORA, as well as an
optional file with additional configuration information called CONFIG.ORA. Starting with Oracle9i, you
could have a virtual initialization file called the SPFILE, which could be shared with multiple instances.
SPFILE was especially handy for two reasons: You could change a configuration parameter for a running
instance and not have to save the change to the SPFILE, which means that the value of the parameter
would be reset to the stored value on the next startup. You can also use the SPFILE with Real Application
Clusters, discussed later in this chapter, where multiple instances worked together in a cluster and shared
the same initialization procedures.

Control File
The control file is used to store key information about an instance, such as the name of the instance, the
time the database was created, and the state of backup and log files for the database. An Oracle instance
requires a control file in order to operate. Although a control can be rebuilt, most Oracle installations use
multiple copies of the control file to avoid this possibility.

Redo Log Files
One of key features of a relational database is its ability to recover to a logically consistent state, even in
the event of a failure. Every relational database, including Oracle, uses a set of redo log files. These files
keep track of every interaction with the database. In the event of a database failure, an administrator can
recover the database by restoring the last backup and then applying the redo log files to replay user
interactions with the database.

Redo log files eventually fill up and roll over to start a new volume. You can set up Oracle to avoid writing
over existing logfiles by creating the database to automatically archive log files in ARCHIVELOG mode,
which is discussed in detail in the Oracle documentation.
Since redo logs are crucial for restoring a database in the event of a failure, many Oracle shops set up an
instance to keep multiple copies of a redo log file.

Rollback Segments
Unlike all other major databases, Oracle also uses rollback segments to store previous versions of data in
the database. The use of rollback segments makes it possible for the Oracle database to avoid the use of
read locks, which can significantly reduce performance degradation based on multiuser access as well as
providing a consistent view of data at any particular point in time. For more on rollback segments and
how they support multiuser concurrency, see Chapter 3, “Handling Multiple Users,” which covers this
important topic in detail.

Because rollback segments track every change to data, the rollback segments are updated as soon as a
change is made. This real-time update lets the Oracle database delay writing its redo log files until a
time when these writes can be done efficiently.

Oracle 10g includes the ability to designate an automatic UNDO tablespace, which assigns the responsibility
for managing rollback segments to the Oracle database itself.