Oracle RMAN 11g Backup and Recovery (38 page)

62
Part II: Setup Principles and Practices

et’s get started with this RMAN thing, shall we? Let’s just reach down, pull on the handle, I said, pull on the handle…and, it doesn’t start. We first need to set up RMAN and our database for backup and recovery operations before we can actually do anything. In this chapter, we look at initial RMAN setup requirements and options. First, we dive into Oracle redo logs a little deeper than we did in Chapter 1.

These are critical structures in the Oracle database for recovery. Building on that discussion, we look at putting the database in ARCHIVELOG mode, in case you want to do online backups. We then look at the basic RMAN interface, so that you can get into RMAN itself. Next, we discuss configuring RMAN for database backup operations. Finally, we discuss the RMAN recovery catalog, including why you might want to use it and how to configure it.

Configuring Your Database to Run in

ARCHIVELOG Mode

Now that you have learned about ARCHIVELOG mode and NOARCHIVELOG mode in Chapter 1

and learned how important redo is to your database, you probably understand why many DBAs run their databases in ARCHIVELOG mode. If you are content with running in NOARCHIVELOG mode, then much of this section’s discussion will not apply to you. If you are going to run in ARCHIVELOG

mode, you will need to do some basic configuration, which is the topic of this section.

When running in ARCHIVELOG mode, you have two choices in configuring where the archived redo logs are copied. In fact, you can choose to use both choices. The first choice is to configure for ARCHIVELOG destination directories, and the second is to configure the Oracle flash recovery area (FRA). We will discuss those two topics next. Afterward, we will discuss actually putting the database in ARCHIVELOG mode.

ARCHIVELOG Destination Directories

When configuring ARCHIVELOG mode, you will need to decide where you want Oracle to create archived redo logs. The option that has been available for the longest is to use archive log destination directories. To use archive log destination directories, you set some specific parameters in Oracle to configure this option. First, you use the LOG_ARCHIVE_DEST_
n
(where
n
is a number in the range of 1 to 10) parameter to define up to ten different archive log destinations. These destinations can be local directories, network directories (for example, NT folders), NAS (network-attached storage), or even a defined database service name if you are using standby database/Data Guard. Note that there is no default location defined for LOG_ARCHIVE_DEST_
n
.

If you are using SPFILES, you use the
alter system
command to set the LOG_ARCHIVE_DEST_

n
parameter as seen here:

alter system set log archive dest 1 'location c:\oracle\oraarc\beta1';

NOTE

Setting the LOG_ARCHIVE_DEST directory to a directory location that

does not exist, or that Oracle cannot write to, is a common mistake.

Just make sure that after you set the parameter and put the database in
ARCHIVELOG mode, you issue an
alter system switch logfile
command
to make sure that ARCH is writing the archived redo logs properly.

Each LOG_ARCHIVE_DEST_
n
location can be defined as either a mandatory or optional location. By default, all LOG_ARCHIVE_DEST_
n
locations are optional in Oracle Database 11
g.

Chapter 3: RMAN Setup and Configuration
63

Mandatory locations mean just that—the archived redo logs have to be written to that location.

Failure of the ARCH process to write to mandatory locations will result in suspension of database activities fairly quickly (after you have cycled through all the online redo logs). Optional locations will have no impact on database operations.

alter system set log archive dest 1 'location c:\oracle\oraarc\beta1 mandatory'; In Oracle Database 11
g,
all LOG_ARCHIVE_DEST_
n
locations are optional by default (though one location must always succeed since the minimum setting of LOG_ARCHIVE_MIN_SUCCEED_

DEST is 1). The parameter LOG_ARCHIVE_MIN_SUCCEED_DEST indicates how many archive log destination directories must have successful copies for an online redo log to be considered successfully archived. The default setting for LOG_ARCHIVE_MIN_SUCCEED_DEST is 1, and this is the minimum setting for this parameter. Here is an example of setting this parameter to a value of 2: alter system set log archive min succeed dest 2;

Other parameters are related to archived redo logs, the ARCH process, and the LOG_

ARCHIVE_DEST series of parameters:

■
LOG_ARCHIVE_STATE_
n
Defines one of two different states for each archive log destination. If set to ENABLE, the ARCH process will consider the destination associated with this state as a valid archive log destination. If set to DEFER, the ARCH process will not archive logs to the related LOG_ARCHIVE_DEST_
n
location.

■
LOG_ARCHIVE_FORMAT
Provides a template for Oracle to use when naming archived redo logs. As Oracle creates the archived redo logs, it renames them in such a way that each of the archived redo logs has a unique name assigned to it. Using the LOG_

ARCHIVE_FORMAT parameter, you can manipulate the default naming standard as you require. This parameter has no effect for archived redo logs being created in the FRA.

■
LOG_ARCHIVE_START
This parameter is obsolete in Oracle Database 10
g
and later versions. Oracle will now start the ARCH process for you automatically.

■
LOG_ARCHIVE_MAX_PROCESSES
This parameter defines the number of ARCH

processes that Oracle initially starts when the database is started.

NOTE

If you are running Oracle Database 9
i
or earlier, you will need to
make sure you set the LOG_ARCHIVE_START parameter to TRUE

when configuring your database for ARCHIVELOG mode. This is

no longer required in Oracle Database 10
g
and later.

Each of the different parameters mentioned thus far is defined in the
Oracle Database 11
g
Reference Manual
(which is part of the overall Oracle documentation), should you need further information on them.

In the following example, we have a database we want to put in ARCHIVELOG mode. We will create three different archive log destination directories, including one to a service name that supports an Oracle standby database. We will also enforce the requirements that at least two of these destinations must be written to in order for the movement of the archived redo log to be considered complete, and that the standby database must be one of those two locations. Here is

64
Part II: Setup Principles and Practices

an example of the use of the various database parameter file parameters related to ARCHIVELOG

mode operations:

log archive dest 1 'location d:\oracle\oraarc\robt mandatory'

log archive dest 2 'location z:\oracle\oraarc\robt optional'

log archive dest 3 'service recover1 mandatory'

log archive min succeed dest 2

log archive format "robt %s %t.arc"

In this example, our first archive log destination goes to d:\oracle\oraarc\robt. The second archive log destination is to a secondary location on the Z: drive. We have made this an optional archiving location because it is a networking device (which may not be all that reliable). The third destination is to an Oracle Net service (probably a standby database) called recover1. This will cause Oracle to send the archived redo logs through Oracle Net as they are generated.

Proceeding through the example, by using the LOG_ARCHIVE_MIN_SUCCEED_DEST

parameter, we have indicated that the archived redo logs must be successfully copied to at least two different locations. The format of the archived redo log is defined with the LOG_ARCHIVE_

FORMAT parameter.

The Flash Recovery Area

The flash recovery area (FRA) allows you to centralize storage of all recovery-related files. The FRA can use locally attached storage, the Oracle Cluster File System (OCFS), or Automatic Storage Management (ASM) features. Table 3-1 lists the file types that can be contained within the FRA.