Avamar 7.3 RMAN configuration (Part 2)

Previously we looked at how to backup oracle using the Avamar plugin. So lets look at how I currently use the RMAN plugin for Avamar to test my database restores.

Since we will be using a test server to restore to, the easiest way is not to register the instance in RMAN if you are using a catalog. So all the restores will be using the target control file only. In an actual restore to a server with a registered rman instance we would log into the catalog. In this case we would be likely just doing a recover database against the metadata cataloged for a real disaster recovery situation.

The first assumption is that you have installed an oracle instance, and oracle home on your backup test server. The quickest way to do that is run dbca and just create a small database with the same SID as you want to restore from tape. After creating the database shut it down and delete all the data files associated with it. Also navigate to and remove any files under fast_recovery_area/autobackup. If rman finds old backups there it could create a new incarnation of the restored database.

Once you have your environment set up properly you first need to startup the instance in nomount mode to restore the control files from tape. If you have the spfile great, if not you can create or modify a pfile from the dbca instance you created earlier. Usually the only variables that might need tweaking are the undo_tablespace name, and memory_target. The spfile will get restored from tape as well, but if you have any limitations on resources you may not want to use the spfile from the production server. In my case the memory on my backup server is why I usually modify the parameter file for restore tests.

Once you have a valid spfile or pfile you should be able to startup nomount as shown below.

image

 

As explained in my first post on Avamar backups, make sure that your my-avtar-flags.txt has the correct target named which should be your backup server you are restoring too. Also the server should point to your Avamar server, and the path should be the name of the server where that you are pulling the original backup from:

–debug
–pidname=Oracle
–pidnum=1002
–logfile=/home/oracle/logs/backup_prod.log
–vardir=/usr/local/avamar/var
–id=oracle
–bindir=/usr/local/avamar/bin
–ap=secretpassword
–path=/Oracle/viradbprod02
–server=hqavamar01.Lojackone.lojack.com
–expires=30
–target=”viradbbackup”

example above

–server Avamar server

–target server being restored too.

–path original server path in Avamar where backup exists.

The other file taskfile.txt should just have these two lines

–no_of_channels=1

–operation=restore

With all these files correctly adjusted and our database instance in nomount mode we should be able to start a restore by doing two steps.

1. restore control files and mount.

2. restore and recover the database.

So for the first step we can create an rman script that restores the backup from avamar we want. To do this we first go to Avamar and select the control file for the backup we want to restore.

image

If you used the backup scripts I had in my first post your control files will be labeled as above. You can see the name has the SID LJPROD , the database id 421323215 and last the date YYYYMMDD. Given that information we can write a script with the following commands:

image

After saving that script we can restore our control file by running it

source your sid to set environment

. oraenv LJPROD

rman target /

@name_of control_file_restore_script

image

From the above script you can see two control files where restored one under oracledata/SID and one in fast_recovery_area/SID. We can also see that the database changed from nomount to mounted state.

In the mounted state we can create another rman script to restore our datafiles to the newly mounted database.

image

You can see in the above script there are commented out lines in case we didn’t want to restore to the latest scn. There are a few ways we could do an incomplete recovery, but in this case we will attempt a full recovery to the last scn possible.

image

when we hit the recover database step we should see our archivelogs being restored as follows:

image

If we are missing archivelogs RMAN will throw the RMAN-06054, 03002 indicating the missing sequence number and its starting SCN.

image

So now you can restore these archivelogs from either tape or from primary if this was part of a dataguard lag issue.

Running:

RMAN> LIST BACKUP OF ARCHIVELOG ALL;

This will give you a list of all the archivelogs and the last SCN rman finds on tape or file system.

Options:

1.) Find the archivelogs on tape or primary if in a Dataguard configuration. Any missing archivelogs will require you to do an incomplete recovery.

2.) Do an incomplete recovery by SCN or by date or of course you can always do either RECOVER DATABASE UNTIL CANCEL or RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE . Followed of course with ALTER DATABASE OPEN RESETLOGS; 

RMAN is an awesome tool, and the Avamar plugin working on demand is really not that bad once you get use to the text file configurations. You should practice restores often. On my critical systems I try to do restore tests a couple times each month.

This entry was posted in Oracle. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s