Oracle RMAN 11g Backup and Recovery (16 page)

22
Part I: Getting Started with RMAN in Oracle Database 11
g
Instance Startup (startup nomount)

The first thing that occurs when starting the database is instance startup. It is here that Oracle parses the database parameter file and makes sure that the instance is not already running by trying to acquire an instance lock. Then, the various database processes (as described in “The Oracle Processes,” earlier in this chapter), such as DBWn and LGWR, are started. Also, Oracle allocates memory needed for the SGA. Once the instance has been started, Oracle reports to the user who has started it that the instance has been started back, and how much memory has been allocated to the SGA.

Had Eliza issued the command
startup nomount
, then Oracle would have stopped the database startup process after the instance was started. She might have started the instance in order to perform certain types of recovery, such as control file re-creation.

Mounting the Database (startup mount)

The next stage in the startup process is the mount stage. As Oracle passes through the mount stage, it opens the database control file. Having done that successfully, Oracle extracts the database datafile names from the control file in preparation for opening them. Note that Oracle does not actually check for the existence of the datafiles at this point, but only identifies their location from the control file. Having completed this step, Oracle reports back that it has mounted the database.

At this point, had Eliza issued the command
startup mount
, Oracle would have stopped opening the database and waited for further direction. When the Oracle instance is started and the database is mounted but not open, certain types of recovery operations may be performed, including renaming the location of database datafiles and recovery system tablespace datafiles.

Opening the Database

Eliza issued the
startup
command, however, so Oracle moves on and tries to open the database.

During this stage, Oracle verifies the presence of the database datafiles and opens them. As it opens them, it checks the datafile headers and compares the SCN information contained in those headers with the SCN stored in the control files. Let’s talk about these SCNs for a second.

SCNs are Oracle’s method of tracking the state of the database. As changes occur in the database, they are associated with a given SCN. As these changes are flushed to the database datafiles (which occurs during a
checkpoint
operation), the headers of the datafiles are updated with the current SCN. The current SCN is also recorded in the database control file.

When Oracle tries to open a database, it checks the SCNs in each datafile and in the database control file. If the SCNs are the same and the bitmapped flags are set correctly, then the database is considered to be consistent, and the database is opened for use.

NOTE

Think of SCNs as being like the counter on a VCR. As time goes on,

the counter continues to increment, indicating a temporal point in

time where the tape currently is. So, if you want to watch a program
on the tape, you can simply rewind (or fast forward) the tape to the
counter number, and there is the beginning of the program. SCNs

are the same way. When Oracle needs to recover a database, it

“rewinds” to the SCN it needs to start with and then replays all of

the transactions after that SCN until the database is recovered.

Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
23

If the SCNs are different, then Oracle automatically performs
crash or instance recovery,
if possible. Crash or instance recovery occurs if the redo needed to generate a consistent image is in the online redo log files. If crash or instance recovery is not possible, because of a corrupted datafile or because the redo required to recover is not in the online redo logs, then Oracle requests that the DBA perform
media recovery.
Media recovery involves recovering one or more database datafiles from a backup taken of the database and is a manual process, unlike instance recovery. Assisting in media recovery is where RMAN comes in, as you will see in later chapters.

Once the database open process is completed successfully (with no recovery, crash recovery, or media recovery), then the database is open for business.

Shutting Down the Database

Of course, Eliza will probably want to shut down the database at some point in time. To do so, she could issue the
shutdown
command. This command closes the database, unmounts it, and then shuts down the instance in almost the reverse order as the startup process already discussed.

There are several options to the
shutdown
command.

Note in particular that a
shutdown abort
of a database is basically like simulating a database crash. This command is used often, and it rarely causes problems. Oracle generally recommends that your database be shut down in a consistent manner, if at all possible.

If you must use the
shutdown abort
command to shut down the database (and in the real world, this does happen frequently because of outage constraints), then you should reopen the database with the
startup
command (or even better,
startup restrict
). Following this, do the final shutdown on the database using the
shutdown immediate
command before performing any offline backup operations. Note that even this method may result in delays shutting down the database because of the time it takes to roll back transactions during the shutdown process.

NOTE

As long as your backup and recovery strategy is correct, it really

doesn’t matter whether the database is in a consistent state (as with
a normal
shutdown
) or an inconsistent state (as with a
shutdown
abort
) when an offline backup occurs. Oracle does recommend that
you do cold backups with the database in a consistent state, and we

recommend that, too (because the online redo logs will not be getting
backed up by RMAN). Finally, note that online backups eliminate this
issue completely!

Using the Database and Internals

In this section, we are going to follow some users performing different transactions in an Oracle database. First, we provide you with a graphical roadmap that puts together all the processes, memory structures, and other components of the database for you. Then, we follow a user as the user makes changes to the database. We then look at commits and how they operate. Finally, we look at database checkpoints and how they work.

Process and Database Relationships

We have discussed a number of different processes, memory structures, and other objects that make up the Oracle database. Figure 1-2 provides a graphic that might help you better understand the interrelationships between the different components in Oracle.