Oracle RMAN 11g Backup and Recovery (47 page)

%u

Indicates that an eight-character name, consisting of compressed representations of the backup set or image copy number and the time the backup set or image copy was created, should be substituted.

%U

This is the default file-naming pattern and provides a system-generated unique filename for RMAN-related files. The meaning of this substitution string differs when dealing with image copies or backup pieces.

When using backup set pieces, %U specifies a convenient shorthand for

%u_%p_%c that guarantees uniqueness in generated backup filenames.

The meaning differs when using image copies, and depending on the type

of image copy.

Meaning when used with an image copy of datafiles:

data-D-%d_id-%I_TS-%N_FNO-%f_%u

Meaning when used with an image copy of an archived redo log:

arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u

Meaning when used with an image copy of a control file:

cf-D_%d-id-%I_%u

%Y

Indicates that the year in the format YYYY should be substituted.

%%

Indicates that you wish to actually use the % character; for example, %%Y.

TABLE 3-3
Format String Specification Descriptions
(continued)

Chapter 3: RMAN Setup and Configuration
91

Configuring Default Automated Backups of the Control File and the SPFILE

RMAN in Oracle Database 10
g
and later offers the ability to back up the control file and the database parameter file, and you can configure these backups to take place by default. Again, you can use the
configure
command to configure this automated backup process to happen automatically during a backup. Here is an example of configuring automated backups of these important database files, and an example of turning off the default configuration: configure controlfile autobackup on;

configure controlfile autobackup off;

When autobackup of the control and parameter files is configured, the following rules apply:

■ The control file and the server parameter file will be automatically backed up with each RMAN
backup
or
copy
command issued that is not included in a
run
block.

■ If a
run
block is used, then the control files and parameter files will be backed up at the end of the
run
block if the last command is not
backup
or
copy
.

NOTE

If you are not going to use a recovery catalog and the following

conditions apply:

■
You wish to be able to recover your control file after an automated control file backup.

■
You are not using the FRA.

In addition to the last two types of automated control file backups, a special type of control file backup can be configured to occur as a direct result of database changes such as adding new tablespaces, adding datafiles, adding online redo logs, and so on. This type of automatic backup can only happen to disk. A special option of the
configure controlfile autobackup
command can be used to facilitate this backup. Here is an example:

RMAN> configure controlfile autobackup format for device type

disk to 'd:\backup\contf\robt %F'

When this option is used, the Oracle RDBMS will automatically back up the control file during database structure changes that impact the control file. These changes might include adding a new tablespace, altering the state of a tablespace or datafile (for example, bringing it online), adding a new online redo log, renaming a file, adding a new redo thread, and so forth.

Note that this automated backup can only be to disk, because tape is not supported. These backups can get a bit large (since the control file contains a history of many of the past backups), so make sure you allocate enough disk space to the backup directory. In spite of the additional space that will be required, these backups can be incredibly handy to have for recovery. Finally, be aware that if the backup fails for any reason, the database operation itself will not fail.

92
Part II: Setup Principles and Practices

NOTE

You must know the DBID of the database. You should, as a part of

your initial setup and configuration of RMAN, note the DBIDs of the

databases that you will be backing up and save that list somewhere

safe. The DBID of the database is available from the V$DATABASE

view in the DBID column. The DBID of the database is also displayed

when you start RMAN and connect to a target database, as shown in

this example:

[oracle@robertgfreeman ~]$ rman target /

Recovery Manager: Release 11.2.0.1.0 - Production on Thu Nov 5 04:04:06 2009

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

connected to target database: ROB1(
DBID=1854903786
)

Configuring Default Retention Policies

So, how long do you want to keep your database backups? RMAN enables you to configure a backup retention policy by using the
configure retention policy
command. If you configure a retention policy and are using the FRA, then RMAN and Oracle will take care of automatically removing backups when they become obsolete. If you are not using the FRA, then configuring a retention policy will not cause backups to be deleted automatically, but will cause expired backup sets to appear when the
report obsolete
command is executed. See Chapter 15 for more on
report obsolete
.

There are really three kinds of retention policies in Oracle: recovery window–based, redundancy-based, and none. Let’s look at each of these in more detail next.

Recovery Window–Based Retention Policies
The recovery window–based retention policy is designed to ensure that your database can be recovered to a specific point in time. For example, if you wanted to make sure that you could recover your database back to any point in time up to three days ago (assuming you were running in ARCHIVELOG mode, of course), you would set a recovery window–based retention policy of three days. The command to configure such a retention policy would be as follows:

RMAN> configure retention policy to recovery window of 3 days;

old RMAN configuration parameters:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

new RMAN configuration parameters:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

new RMAN configuration parameters are successfully stored

Note that the recovery window–based retention criteria can result in backups actually being maintained longer than the stated recovery window. For example, if your recovery window is three days, but your last full backup was five days ago, then that backup will remain valid until it is no longer needed to restore your database. Even if you back up your database today, five days later, the backup that is five days ago is still needed because it is the only source of recovery back to day 3. Figure 3-1 provides a graphical demonstration of this.

Chapter 3: RMAN Setup and Configuration
93

These backups are

This backup is

needed to restore

needed to restore

days 1–4

day 5

B

A

A

A

B

Day

1

2

3

4

5

3-day window

Key

B: Full backup

Both full backups

A: Archive log backup

required to restore

to 3 days ago

These backups are

These backups

no longer needed

are still needed

B

A

A

A

A

B

A

B

Day

1

2

3

4

5

6

7

8

3-day window

Key

B: Full backup

Backups from days 1–4

A: Archive log backup

are no longer needed.

Backups from days 6–8

are still needed.

Figure 3-1
Recovery window maintaining older backups