Pro Oracle Database 11g Administration (80 page)

479

CHAPTER 17 ■ CONFIGURING RMAN

Table 17–2.
Implementation of Architectural Decisions

Decision Point

Implementation in Script

Line Number in Script

1. Running the RMAN client remotely or

Running script locally on the

Line 26, connecting

locally

database server.

locally (not a network

connection).

2. Specifying the backup user

Using SYS to connect.

Line 27, starting rman

connecting with /.

3. Using online or offline backups

Online backup.

N/A. The database is

assumed to be up

during the backup.

4. Setting the archive-redo log

LOG_ARCHIVE_DEST_N and

N/A. Set outside of the

destination and file format

LOG_ARCHIVE_FORMAT initialization

script.

parameters set outside of the

script in a database-initialization

file.

5. Configuring the RMAN backup

Using the CONFIGURE command

Lines 38 through 43.

location and file format

directly in the script.

6. Setting autobackup of the control file

Enabled in the script.

Line 35.

7. Specifying the location of the

Placed in the same directory as

Line 36.

autobackup of the control file

the backups.

8. Backing up archive-redo logs

Backing up with the rest of the

Line 45.

database. Specifically, using the

PLUS ARCHIVELOG clause.

9. Determining the location for the

Using the default location.

N/A

snapshot control file

10. Using a recovery catalog

Not using.

Line 26, connecting as

nocatalog.

11. Using a media manager

Not using.

Lines 38 through 43,

device type disk.

12. Setting the

Using the default.

N/A

CONTROL_FILE_RECORD_KEEP_TIME

initialization parameter

480

CHAPTER 17 ■ CONFIGURING RMAN

Decision Point

Implementation in Script

Line Number in Script

13. Configuring RMAN’s backup-

Configuring to a redundancy of 1,

Line 37, configuring.

retention policy

crosschecking, and deleting

Line 47, using RMAN to

obsolete backups and archive

delete old files.

redo log files.

14. Configuring the archive-redo logs’

Using the same retention policy

N/A

deletion policy

as applied to the backups.

15. Setting the degree of parallelism

Setting a degree of 5.

Lines 38 through 43.

16. Using backup sets or image copies

Using backup sets.

Line 45.

17. Using incremental backups

Incremental level 0, the same as a

Line 45.

full backup.

18. Using incrementally updated

Not using.

N/A

backups

19. Using block-change tracking

Not using.

N/A

20. Configuring compression

Using basic compression.

Line 45.

21. Configuring encryption

Not using.

N/A

22. Configuring miscellaneous settings

Not using.

N/A

A few aspects about this script need further discussion (in addition to what’s included in the table).

Line 11 sets the required OS variables by running a script named oraset. See Chapter 2 for details on running oraset and sourcing OS variables. Many DBAs choose to hard-code OS variables such as ORACLE_HOME and ORACLE_SID into the script. However, you should avoid hard-coding variables and instead use a script to source the required variables. Running a script is much more flexible, especially when you have many databases on a box with different versions of Oracle installed.

Line 15 sets the NLS_DATE_FORMAT OS variable to a value that includes hours, minutes, and seconds.

This ensures that when RMAN runs commands that are appropriate, it displays the date output with a time component. This can be invaluable when you’re debugging and diagnosing issues. By default, RMAN displays only the date component. Knowing just the date when a command ran is rarely enough information to determine the timing of the commands as they were executed. At minimum, you need to see hours and minutes (along with the date).

Lines 18 through 24 check for the existence of a lock file. You don’t want to run this script if it’s already running. The script checks for the lock file, and if it exists, the script exits. After the backup has finished, the lock file is removed (lines 66 through 68).

Line 28 sets the ECHO parameter to on. This instructs RMAN to display in the output the command before it runs it. This can be invaluable for debugging issues. Line 29 displays all the configurable variables. This also comes in handy for troubleshooting issues because you can see what the RMAN

variables were set to before any commands are executed.

Lines 35 through 43 use the CONFIGURE command. These commands run each time the script is executed. Why do that? You only need to run a CONFIGURE command once, and it’s stored in the control 481

CHAPTER 17 ■ CONFIGURING RMAN

file—you don’t have to run it again, right? That is correct. However, I’ve occasionally been burned when a DBA with poor habits configured a setting for a database and didn’t tell anybody, and I didn’t discover the misconfiguration until I attempted to make another backup. I strongly prefer to place the CONFIGURE

commands in the script so the behavior is the same regardless of what another DBA may have done outside of the script. The CONFIGURE settings in the script also act as a form of documentation: I can readily look at the script and determine how settings have been configured.

Lines 31 through 33 run CROSSCHECK commands. Why do that? Sometimes files go missing, or a rogue DBA may remove archive-redo log files from disk with an OS command outside of RMAN. When RMAN

runs, if it can’t find files that it thinks should be in place, it throws an error and stops the backup. I prefer to run the CROSSCHECK command and let RMAN reconcile what files it thinks should be on disk with those that are actually on disk. This keeps RMAN running smoothly.

You run DELETE NOPROMPT OBSOLETE on line 47. This removes all backup files and archive-redo log files that have been marked as OBSOLETE by RMAN as defined by the retention policy. This lets RMAN

manage which files should be kept on disk. I prefer to run the DELETE command after the backup has finished (as opposed to running it before the backup). The retention policy is defined to be 1, so if you run DELETE after the backup, it leaves one backup copy on disk. If you run DELETE before the backup, it leaves one copy of the backup on disk. After the backup runs, there are be two copies of the backup on disk, which I don’t have room for on this server.

Line 59 creates a trace file that contains the CREATE CONTROLFILE SQL statement that would be required for this database in the event you had to re-create the control file. Line 62 writes the database identifier (DBID) to the alert log file. This may come in handy for some types of control-file restores when you need the database ID to perform the restore.

You can execute the shell script from the Linux/Unix scheduling utility cron as follows: 0 16 * * * $HOME/bin/rmanback.bsh INVPRD >$HOME/bin/log/INVPRDRMAN.log 2>&1

The script runs daily at 1600 hours military time on the database server. A log file is created (INVPRDRMAN.log) to capture any output and any errors associated with the RMAN job. See Chapter 21 for details on automating jobs through cron.

Again, the script in this section is basic; you’ll no doubt want to enhance and modify it to meet your requirements. This script gives you a starting point with tangible RMAN recommendations and how to implement them.

Using a Recovery Catalog

When you use a recovery catalog, it’s possible to create the recovery-catalog user in the same database on the same server as your target database. However, that approach isn’t recommended because you don’t want the availability of your target database or the availability of the server on which the target database resides to affect the recovery catalog. Therefore, you should create the recovery-catalog database on a different server than your target database.

Creating a Recovery Catalog

When I use a recovery catalog, I prefer to have a dedicated database that is used only for the recovery catalog. This ensures that the recovery catalog isn’t affected by any maintenance or downtime required by another application (and vise versa).

Listed next are the steps for creating a recovery catalog:

1. Create a database on a different server than your target database, to be used for a recovery catalog. Make sure the database is adequately sized. I’ve found that Oracle’s recommended sizes are usually much too small. Here are some

adequate recommendations:

482

CHAPTER 17 ■ CONFIGURING RMAN

•

•

•

•

•

group

•

2. Create a tablespace to be used by the recovery-catalog user. I recommend naming the tablespace something like RECCAT so it’s readily identifiable as the tablespace that contains the recovery-catalog metadata:

CREATE TABLESPACE reccat

DATAFILE '/ora01/dbfile/O11R2/reccat01.dbf'

SIZE 500M

EXTENT MANAGEMENT LOCAL

UNIFORM SIZE 128k

SEGMENT SPACE MANAGEMENT AUTO;

3. Create a user that will own the tables and other objects used to store the target database metadata. I recommend that you name the recovery-catalog user something like RCAT so you can readily identify it as the user that owns the recovery-catalog objects. Also grant the RECOVERY_CATALOG_OWNER role to the RCAT user as well as CREATE SESSION:

CREATE USER rcat IDENTIFIED BY foo

TEMPORARY TABLESPACE temp

DEFAULT TABLESPACE reccat

QUOTA UNLIMITED ON reccat;

--

GRANT RECOVERY_CATALOG_OWNER TO rcat;

GRANT CREATE SESSION TO rcat;

4. Connect through RMAN as RCAT, and create the recovery-catalog objects: $ rman catalog rcat/foo

5. Now, run the CREATE CATALOG command:

RMAN> create catalog;

RMAN> exit;

6. This command may take a few minutes to run. When it’s finished, you can verify that the tables were created with the following query:

$ sqlplus rcat/foo

SQL> select table_name from user_tables;

7. Here’s some sample output:

483

CHAPTER 17 ■ CONFIGURING RMAN

TABLE_NAME

------------------------------

DB

NODE

CONF

DBINC

BRDSTN

CKP

TS

Registering a Target Database

Now you can register a target database with the recovery catalog. Log on to the target database server.

Ensure that you can establish Oracle Net connectivity to the recovery-catalog database. For example, one approach is to populate the TNS_ADMIN/tnsnames.ora file with an entry that points to the remote database. On the target database server, register the recovery catalog as follows: $ rman target / catalog rcat/foo@rcat

When you connect, you should see verification that you’re connecting to both the target and the recovery catalog:

connected to target database: O11R2 (DBID=3457609395)

connected to recovery catalog database

Next, run the REGISTER DATABASE command:

RMAN> register database;

Now, you can run backup operations and have the metadata about the backup tasks written to both the control file and the recovery catalog. Make sure you connect to the recovery catalog along with the target database each time you run RMAN commands:

$ rman target / catalog rcat/foo@rcat

Backing Up the Recovery Catalog

Make sure you include a strategy for backing up and recovering the recovery-catalog database. For the most protection, be sure the recovery-catalog database is in archivelog mode, and use RMAN to back up the database.

You can also use a tool like Data Pump to take a snapshot of the database. The downside to using Data Pump is that you can potentially lose some information in the recovery catalog that was created after the Data Pump export.

Keep in mind that if you experience a complete failure on your recovery-catalog database server, that you can still use RMAN to back up your target databases. You just can’t connect to the recovery catalog. So, any scripts that instruct RMAN to connect to the target and the recovery catalog must be modified.

Also, if you completely lose a recovery catalog and don’t have a backup, one option is to re-create it from scratch. As soon as you re-create it, you re-register the target databases with the recovery catalog.

You lose any long-term historical recovery-catalog metadata.

484

CHAPTER 17 ■ CONFIGURING RMAN

Synchronizing the Recovery Catalog

You may have an issue with the network that renders the recovery catalog inaccessible. In the meantime, you connect to your target database and perform backup operations. Some time later, the network issues are resolved, and you can again connect to the recovery catalog.

In this situation, you need to resynchronize the recovery catalog with the target database so that the recovery catalog is aware of any backup operations that aren’t stored in the recovery catalog. Run the following command to ensure that the recovery catalog has the most recent backup information: $ rman target / catalog rcat/foo@rcat

RMAN> resync catalog;

Keep in mind that you have to resynchronize the catalog only if for some reason you’re performing backup operations without connecting to the catalog. Under normal conditions, you don’t have to run the RESYNC command.