Oracle RMAN 11g Backup and Recovery (13 page)

■
startup mount
Causes the startup process to stop after it has successfully started the database instance and then mounted it. This command is helpful if you need to recover the SYSTEM tablespace.

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

■
startup read only
Causes your Oracle database (or standby database) to open in READ

ONLY mode. Thus, DML operations are not supported, but you can query the database.

This is handy if you are doing point-in-time recovery and you want to make sure you have recovered the database to the correct point in time before you commit to the new database incarnation with the
resetlogs
command.

■
startup force
Causes the database to be shut down with a
shutdown abort
(discussed in the next list). This command can be followed by the mode you wish the database to be opened in again. Examples include

■

startup force restrict

■

startup force mount

■

startup force nomount

Of course, now that you know how to start up the database, you need to know how to shut it down. Again, from SQL*Plus, you can use the
shutdown
command, which comes in these flavors:

■
shutdown
(also
shutdown normal
) Causes Oracle to wait for all user processes to disconnect from the database. Once this has occurred, the database will be completely shut down. Use of this option avoids instance recovery. After the
shutdown
command is executed, no new user processes are able to connect to the database.

■
shutdown immediate
Kills all existing user sessions and rolls back all uncommitted transactions. Use of this option avoids instance recovery. After
shutdown immediate
is executed, no new user processes are able to connect to the database.

■
shutdown abort
Basically, crashes the database. Use of this option requires instance (but not media) recovery. After
shutdown abort
is executed, no new user processes are able to connect to the database.

■
shutdown transactional
Causes Oracle to wait for all user processes to commit their current transactions and then disconnects the user processes and shuts down the database.

While it is waiting for these transactions to complete, no new user sessions are allowed to connect to the database.

As we proceed through this book, we use many of these commands, and it is important to understand what state the database and its associated instance are in when the command has completed.

Oracle Architecture

Our tour continues as we begin looking at the physical components of Oracle. First, we take a look at the processes that make up an Oracle database. Then, we look at Oracle memory structures and the different logical, physical, and physi-logical structures that make up an Oracle database. Finally, we discuss the differences between an instance and an Oracle database.

The Oracle Processes

When the
startup nomount
command is issued, Oracle attempts to start an Oracle
instance.
An Oracle instance is started after several required operating system processes (programs) are started

12
Part I: Getting Started with RMAN in Oracle Database 11
g
and the SGA memory area is allocated. In this section, we are going to look at the processes that get Oracle started. First, we look at the basic five Oracle processes required for any Oracle database to be functional. Next, we look at user and server processes. Finally, we look at other, optional Oracle processes that you might see from time to time.

NOTE

This is just a basic introduction to the Oracle processes. If you

want more in-depth detail on them, please refer to the Oracle

documentation.

The Five Required Oracle Processes

If an Oracle Database 11
g
instance has successfully started, a minimum of five different processes will start. Of course, on certain systems (such as Microsoft-based OSs), the five different processes are really just threads of a single Oracle process, but the basic idea is still the same. These required processes are as follows:

■
PMON
Also known as the process monitor process (and one of what some call the

“Jamaican processes”).

■
SMON
Also known as the system monitor process (and the other “Jamaican process”).

■
DBW
n
Known as the database writer processes. An instance can be configured with up to nine of these processes in Oracle Database 11
g
(but generally no more than one is required). DBWn is responsible for writing information to the database datafiles from the database buffer cache structure in the SGA.

■
LGWR
The log writer process is responsible for writing generated redo to the database online redo logs from the log buffer. LGWR is signaled to do these writes when a user session is committed, when the redo log buffer is nearly full, and at other times as required.

■
CKPT
During a checkpoint operation, the CKPT process notifies DBWn of the checkpoint. The CKPT process also updates database datafile headers with current checkpoint information.

The User and Server Processes

When a user connects to the database, a user process is spawned (or a new thread is started on Windows NT) that connects to a separately spawned server process. These processes communicate with each other using various protocols, such as Bequeath or TCP/IP.

Other Optional Oracle Processes

A number of other Oracle processes may be launched as well when the Oracle instance is started (and in some cases, optional processes may actually be started much later on demand), depending on the configuration of the Oracle database parameter file. Most of these processes have little bearing on RMAN and database backup and recovery (unless the failure of one of the processes causes the database to crash, which is rare), so we won’t spend much time on them. All of the optional processes are described in the Oracle documentation, online at otn.oracle.com, as well as in several Oracle Press books.

One set of optional processes that does have some bearing on RMAN and backup and recovery are the ARCH
n
processes. These processes (one or many of them) are critical to the backup and Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
13

recovery process if you are doing online backups. See the section titled “ARCHIVELOG Mode vs.

NOARCHIVELOG Mode,” later in the chapter, for more on the ARCHn process(es).

Oracle Memory and RMAN

In this section, we look at the memory areas that we need to be concerned with in relationship to RMAN. As with any process, RMAN does require memory for its own operations and as a part of its database interactions. First, we describe the Oracle SGA in more detail, and then we look at the Private Global Area (PGA).

The Oracle System Global Area

The principal memory structure that we are concerned with in terms of RMAN and backup and recovery is the System Global Area (SGA). The SGA consists of one large allocation of shared memory that can be broken down into several memory substructures:

■ The database buffer cache

■ The shared pool

■ The redo log buffer

■ The large pool

■ The Java pool

■ The Streams pool

Of particular interest to the RMAN user are the shared pool and the large pool. RMAN uses several Oracle PL/SQL packages as it goes through its paces (as you will read in Chapter 2). These packages are like any other Oracle PL/SQL packages in that they must be loaded into the shared pool. If the shared pool is not large enough, or if it becomes fragmented, it is possible that the RMAN packages will not be able to execute. Thus, it is important to allocate enough memory to the shared pool for RMAN operations.

The large pool is used by RMAN in specific cases and is not used by default, even if it is configured. RMAN allows you to duplex RMAN backups (or to make concurrent copies of the same backup in different places) if either of the database parameters, BACKUP_TAPE_IO_SLAVES

or DBWR_IO_SLAVES, is set to TRUE. These parameters are typically set to TRUE if you wish to simulate asynchronous IO. If these two parameters are set, Oracle can use the large pool memory rather than local memory (PGA). The use of the PGA is the default, so don’t get confused and allocate tons of memory to the large pool when it will never get used.

Defining Memory Allocations in the SGA

The individual sizes of the SGA components are allocated based on the settings of parameters in the database parameter file. Depending on the version of the database you are using, these parameters include MEMORY_MAX_SIZE, MEMORY_TARGET, SGA_MAX_SIZE, SGA_TARGET, SHARED_

POOL_SIZE, DB_CACHE_SIZE, DB_
n
K_CACHE_SIZE, LOG_BUFFER, LARGE_POOL_SIZE, and JAVA_POOL_SIZE (and several others). Each of these is defined in the Oracle documentation, so refer to it if you need more information on them. In Chapter 2, we will cover in detail the main parameters that have some bearing in terms of RMAN usage.

14
Part I: Getting Started with RMAN in Oracle Database 11
g
To recap quickly, we have discussed the makings of an Oracle instance in the last several pages. We have talked about the different Oracle processes and the different Oracle memory structures. When the processes and the memory all come together, an Oracle instance is formed.

Now that we have an instance, we are ready for a database. In the next section, we discuss the various structures that make up an Oracle database.

The Oracle Database

Our tour now turns its attention to the Oracle database architecture itself. An Oracle database is made up of a number of different structures—some physical, some logical, and some physi-logical.

In this section, we look at each of these types of structures and discuss each of the individual components of the Oracle database. We will conclude this section by looking at the flash recovery area (FRA) and Automatic Storage Management (ASM).

Oracle Physical Components

The Oracle database physical architecture includes the following components:

■ Database datafiles

■ Online redo logs

■ Archived redo logs

■ Database control files

■ Oracle tablespaces

■ Flashback logs (optional)

Each of these items is physically located on a storage device that is connected to your computer.

These objects make up the physical existence of your Oracle database, and to recover your database, you may need to restore and recover one or more of these objects from a backup (except the flashback log). Let’s look at each of these objects in a bit more detail.

Database Datafiles
The database datafiles are the data storage medium of the database and are related to tablespaces, as you will see shortly. When information is stored in the database, it ultimately gets stored in these physical files. Each database datafile contains a
datafile header
that contains information to help track the current state of that datafile. This datafile header is updated during checkpoint operations to reflect the current state of the datafile.

Database datafiles can have a number of different statuses assigned to them. The primary statuses we are interested in are ONLINE, which is the normal status, and OFFLINE, which is generally an abnormal status. A database datafile might take on the RECOVER status, as well, indicating that there is a problem with the datafile and that recovery is required.

If the database is in ARCHIVELOG mode (more on this later), you can take a datafile offline, which may be required for certain recovery operations. If the database is in NOARCHIVELOG

mode, then you can only take the database datafile offline by dropping it. Offline dropping of a datafile can have some nasty effects on your database (such as loss of data), so drop datafiles with care.

Online Redo Logs
If the Oracle SCN can be likened to the counter on a VCR, then the redo logs can be likened to the videotape. (This analogy becomes harder and harder as DVRs replace Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
15

VCRs!) The online redo logs are responsible for recording every single atomic change that occurs in the database. Each Oracle database must have a minimum of two different online redo log groups, and most databases generally have many more than that, for performance and data preservation reasons.

Each online redo log group can have multiple members located on different disk drives for protection purposes. Oracle writes to the different members in parallel, making the write process more efficient. Oracle writes to one redo log group at a time, in round-robin fashion. When the group has been filled, the LGWR process closes those redo logs and then opens the next online redo log for processing.