Oracle RMAN 11g Backup and Recovery (92 page)

260
Part II: Setup Principles and Practices

Note that we use tags for these backups. It is important that the tags are named the same in both the
recover
and
backup
commands.

You can also change the order of the command, performing the
backup incremental
first and then the
recover copy of database
command second, as seen in this example: RUN {

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr update'

DATABASE;

RECOVER COPY OF DATABASE WITH TAG 'incr update';

}

Changing the order in this way will result in the incremental level 1 backups being applied to the level 0 base backups immediately; thus, there is no delay in the application of the incrementals to the base backup. This keeps the base backup as current as possible.

Note that this strategy assumes a retention policy of redundancy 1. If you need a more complex retention policy, you will need to use the
until
clause to ensure that you can meet your recovery window. For example, if your retention policy is 7 days, you will set your retention policy to redundancy of 1, and you will adjust your script to use the
until
clause as seen here: RUN {

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr update'

DATABASE;

RECOVER COPY OF DATABASE WITH TAG 'incr update' until time "sysdate-8";

}

Metalink note 7457989.1 provides a more in-depth discussion on the issue of retention. It is important if your retention is time based that you still set redundancy to 1, and that you use the
until
clause to properly ensure your recovery window. Using a recovery window or a redundancy

> 1 will result in files never being removed from the FRA, and thus, you will quickly run out of space.

Metalink note 7457989.1 also provides some insight into the block change tracking file and an inherent limit in that file. By default, Oracle’s block change tracking file can only track bitmap changes of up to 8 days between
recover
commands. If you need a recovery window of > 7 days or if you want to perform additional level 1 incrementals, you will need to modify the parameter
_bct_bitmaps_per_file
to allow for additional bitmaps.

RMAN Workshop:
Do an Incremental Backup

Workshop Notes

This workshop assumes that your database has been configured with automatic channels (as shown in Chapter 3). It also assumes that you have configured a database account called backup_

admin for backups (as described in Chapter 3). In addition, it assumes that if you are using the MML layer, it has been configured. Finally, your database must be configured for and operating in ARCHIVELOG mode.

Step 1.
Start up RMAN:

C:\>rman target backup admin/robert

Chapter 11: RMAN Backups
261

Step 2.
Perform a level 0 incremental backup. Include the archived redo logs in the backup set, and then remove them after the backup:

backup incremental level 0 database plus archivelog delete input;

Step 3.
The next day, perform a level 1 incremental backup. Again, include the archived redo logs in the backup, and remove them after they are backed up:

backup incremental level 1 database plus archivelog delete input;

That about covers RMAN backups. The next chapter will be even more fun, because in it we discuss how to restore these backups and recover our databases.

Getting Started

We have covered a number of different backup options, and you may be left wondering where you should start. Let us make a suggestion or two. We recommend that you start with a test database, one that is very unimportant (better yet, one you have created for just this process).

Here is an RMAN Workshop to get you started!

RMAN Workshop:
Get Your Database Backed Up!

Workshop Notes

This workshop is more of an overall list of things that you need to accomplish to get your database backed up. We have covered a great deal of ground in the last few chapters, and we felt it would be a good idea to summarize everything important up to this point.

Step 1.
Set up a special account in your test database that will be responsible for backup operations. Configure the account as described in Chapter 3. Note that you can opt to use the SYS account, but we prefer to use a separate account.

Step 2.
Set up your MML layer, and be clear on what it requires you to do when performing backup and recovery commands.

Step 3.
As we describe in Chapter 3, use the
configure
command to configure a separate default channel for each device that you are backing up to, unless your specific device supports multiple channels (as some do). Set the default degree of parallelism, as shown in Chapter 3, such that each of the channels will be used during the backup. If you need to configure maximum set sizes, do so; otherwise, don’t bother with that now.

Step 4.
Use the
configure
command to configure automated backups of your control file and SPFILE (if you are using one). For now, let them be created in the default location. You will want to change this later, but for now, just leave it there.

Step 5.
Make sure your operating system backup backs up your Oracle RDBMS software (this also makes sure your control file backups will be backed up!).

262
Part II: Setup Principles and Practices

Step 6.
At first, we suggest that you not use a recovery catalog. Once you have the RMAN

basics down pat and are ready to deploy RMAN to the enterprise, then you can consider a recovery catalog.

Step 7.
For the first few trials, run your database in NOARCHIVELOG mode if you can. Shut down and mount your database, and execute a few
backup database
commands. Make sure the backup sets are getting created where you expect them to.

Step 8.
Go to Chapter 13 and recover the database. We suggest you make cold backups of the entire database, control file, and online redo logs (using the
cp
or
copy
command) first, just in case you run into some learning curves.

Step 9.
Once you are good at recovering databases in NOARCHIVELOG mode, put the database in ARCHIVELOG mode, and do the same thing again. Back up the database using the
backup database plus archivelog
command.

Step 10.
Go to Chapter 13 and Chapter 15 and do some recoveries. Become an RMAN

recovery expert before you go any further.

Step 11.
Play around with the
crosscheck
command, the
list
command, and the
report
commands (see Chapters 17 and 18 for more details on these commands). Become really comfortable with these commands and their purpose.

Step 12.
If you have a large enterprise environment (say, over ten databases), go ahead and add a recovery catalog to the mix, and connect to it and back up your database with it. We strongly encourage you to use a separate recovery catalog for development/test and production databases.

Again, we suggest that you run through the gamut of backup and restore situations while using a recovery catalog before you move on.

Step 13.
Once you are very comfortable with RMAN, create scripts to automate and schedule the process. For example, if you are running on Unix, a script such as the following could be scheduled through
cron
(we include an offline and online script here):

# For offline backups, use this script

#!/bin/ksh

# for offline backups, avoid shutdown aborts at all costs!

rman target rman backup/password<

shutdown immediate

startup mount

backup database;

alter database open;

quit

EOF

If you are doing online backups, use this script:

#!/bin/ksh

rman target rman backup/password<

backup database plus archivelog;

quit

EOF

Chapter 11: RMAN Backups
263

These are korn shell scripts, which is one of the more commonly used shell scripting languages in Unix. Of course, RMAN works on a number of different platforms, so you can use the scripting language you are most comfortable with. In this script, we use what is known as a
here
document.

That’s what the EOF is in the fourth line of the first script and in the second line of the second script. A here document acts like the user is “here” and typing the input that you see listed from the EOF on the top line, until the closing EOF several lines later. Optionally, you could just use a command script created by a text editor, and call it from the RMAN command line, like this: rman target rman backup/password @backup.cmd

In this case, your backup.cmd script would look like this for an offline backup: shutdown immediate

startup mount

backup database;

alter database open;

quit

For a hot backup, it would look like this:

backup database plus archivelog;

quit

You can also store scripts in RMAN by using the RMAN
create script
command. We will discuss stored RMAN scripts in Chapter 11, since storing scripts in RMAN requires a recovery catalog.

Step 14.
Before you move your backups into production, test restores of the backups you have set up in your test environments. Make sure you are comfortable that everything works as it should. We suggest that you use your old backup strategy in dual until you have successfully tested several restores.

Step 15.
Move your RMAN backup strategy into production carefully. Do it one system at a time. Choose your least “visible” systems to convert first. We suggest that you do several test recoveries as you move out into production, and continue (if possible) to do dual backups on each database until you have recovered that production database on a test box with an RMAN

backup successfully. Also, you might want to consider separate archived redo log backups, if that is required.

Step 16.
Perform disaster recovery and test backups often. We also suggest that, at least once a week, you execute a
restore database validate check logical
command on each database to make sure that the database is recoverable.

You will note that with each of these steps, we err on the side of caution. We leave it up to you to decide when you feel comfortable with your RMAN setup. There is just nothing more disheartening than trying to restore your database and getting the following error message from RMAN: RMAN-00571:

RMAN-00569:

ERROR MESSAGE STACK FOLLOWS

RMAN-00571:

RMAN-03002: failure of restore command at 07/07/2006 17:14:55

RMAN-06026: some targets not found - aborting restore

264
Part II: Setup Principles and Practices

Summary

In this chapter, we have covered RMAN backups galore. We looked at how to do offline backups and online backups using RMAN. We also looked at RMAN incremental backups. We discussed the impact of configured defaults on backups, and how much easier they make the backup process. We also introduced the numerous options you can use with backups, such as using tags, overriding the default retention policy, and forcing backups of read-only datafiles. We looked at methods of detecting database corruption with RMAN. All in all, it’s been a full chapter, but we hope you have found it to be a worthwhile one. You are now a step closer to being an RMAN

expert, but the real fun is yet to come, and that’s recovery. Hang on, because that’s coming up next.