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.