Networker

Re: [Networker] Advice on backup strategy for Oracle RMAN backups?

2007-01-19 18:48:18
Subject: Re: [Networker] Advice on backup strategy for Oracle RMAN backups?
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Fri, 19 Jan 2007 18:43:02 -0500
One thing we tried, which didn't work. but did prove interesting is that we marked the saveset for the last backup of the catalog cf as 'suspect' and ditto with the clone copy. We were hoping that this might force NetWorker to use the saveset cf from the previous backup. However, this was not the case. Instead, when we used RMAN/NMO, it still used the most recent version (from the source volume) and didn't seem to care that it had been set to 'suspect'. What's interesting is that if you check that status (clflag) of the save set
after the recovery, it was changed back to non-suspect.

I guess the 'suspect' flag doesn't affect NMO but only normal save set recovers, and NetWorker
will simply reset it when NMO is involved.

We're thinking to resolve this whole issue by simply having a cron job on the backup server like:

savegrp prod
savegrp catalog_full
savegrp catalog_disk_full
savegrp catalog_disk_full_tape

and simply disabling the groups on the GUI. The first group backs up the production database on the Oracle client using a save set which is an RMAN script and writes the data to tape using RMAN/NMO.
Cloning is enabled for this group.

The second group does the same thing but with the catalog database instead. This catalog
is small. Cloning is enabled for this group.

The third group does the same thing but instead of writing the data to tape, its RMAN script instead writes it to disk. It could write just the cf, but the entire catalog is pretty tiny anyway.

The fourth group does a conventional NetWorker backup on the area on disk that the previous group
wrote to. Cloning is not enabled.

This ensures that each group runs immediately after the previous group finishes, it runs in the correct order (the catalog will have the most up to date information from the main database after the main database has been backed up), and we don't have to guess how much time to allow between groups, etc. If for some reason we had to recover the catalog cf from a backup further back (not the most recent) then we could use standard save set recover to
recover from tape to disk (created by fourth group) and then we use RMAN
to restore from the disk (created from third group). That's a worst case scenario. Otherwise,
we'd just use the most recent cf written to tape from second group.

George


Uwe Weber wrote:

Hi,
Uwe Weber wrote:

How would NetWorker know when to back up the data on disk? In other
words, how could you set it up so that NetWorker wouldn't attempt to
back it up if RMAM wasn't finished sending it to disk ye

If you have set controlfile autobackup to on in RMAN it will backup the current cf after every succesfull backup operation.
So -depending on your setup- you will find quite a few
cf backups in the directory you specified.
IIRC you can specify pre- and postscripts in nsrnmo. That would be
the place to put the name of a script that does something like
'save /path/mycfbackups'. This is my nsrnmo.sh template:

# Optional Variable: POSTCMD
# Default value: NONE
# Description: This variable can be used to run a command or command # script after nsrnmostart has completed. It will be launched once for
# every saveset entered in the client setup.
#
POSTCMD=

1. Just set the start time for the NetWorker group far enough beyond
the start time
for the RMAN cron job on the client so as to allow enough of a
window? In other
words, guesstimate?

RMAN cronjob? Do you not start the Oracle backups from a NW group?
If the postcommand is no option, you can create a group that
only backups  /path/mycfbackups. And schedule this group to run after
the oracle group. For the unlikely event that RMAN is still writing to the cf backup while the save is running you will get the usual 'warning: file_name changed during save'. But controlfiles will
be typically smaller than 100 MB, so if you give NW maybe 1/5 H
between the groups, this should be no problem.
For additional security your DBA should multiplex the controlfiles
and you could send the RMAN cf autobackups to a diferent disk
or another machine.
2. Create a cron job on the primary backup server that does something
like:

savegrp group1
savegrp group2

were the NSR client resource for the given client is a member of
group1 and it has the
Oracle RMAN script as its saveset,but instead of the script backing
it up to tape, it instead sends it to
disk. Next, another NSR client resource for the same client is a
member of group2, and its saveset
is the affected area on disk where the data gets written, so the
second savegrp command will back that
area up to tape but not until the first completes. Would this be
reasonable?

Not for normal backups, I am afraid. I assume that you would delete the RMAN backups after transferring them to tape and
then RMAN would not know where to look for it's backuppieces,
so instead of just saying 'restore database' at the RMAN prompt
you would have to restore the necessary backuppieces from tape
to disk and then use RMAN. And you would have paid for NMO without
using it :->.

It is much easier with backing up the cf autobackups , b/c
you can use the restore controlfile from RMAN command.

Example RMAN config and backup session:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/opt/oracle/orabackup/%F';

new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/opt/oracle/orabackup/%F';
new RMAN configuration parameters are successfully stored
RMAN> backup database;
Starting backup at 19-JAN-07
[snip session log of database backup]
Finished backup at 19-JAN-07
Starting Control File and SPFILE Autobackup at 19-JAN-07
piece handle=/opt/oracle/orabackup/c-2607733149-20070119-00 comment=NONE
Finished Control File and SPFILE Autobackup at 19-JAN-07

Example restore:
RMAN> run
2> {
3> allocate channel c1 device type disk;
4> restore controlfile from '/opt/oracle/orabackup/c-2607733149-20070119-00';
5> }

allocated channel: c1
channel c1: sid=156 devtype=DISK

Starting restore at 19-JAN-07

channel c1: restoring control file
channel c1: restore complete, elapsed time: 00:00:02

RMAN> recover database;

Starting recover at 19-JAN-07
Starting implicit crosscheck backup at 19-JAN-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 19-JAN-07

Starting implicit crosscheck copy at 19-JAN-07
using channel ORA_DISK_1
Finished implicit crosscheck copy at 19-JAN-07

searching for all files in the recovery area
cataloging files...
no files cataloged

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 2 is already on disk as file /opt/oracle/oradata/testhome/redo01.log archive log filename=/opt/oracle/oradata/testhome/redo01.log thread=1 sequence=2
media recovery complete, elapsed time: 00:00:02
Finished recover at 19-JAN-07

RMAN> alter database open resetlogs;

database opened

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER



--
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145       | Voice: (301) 713-3284 x210
1315 East West Highway        | Fax:   (301) 713-3301
Silver Spring, MD 20910-3282  | Web Site:  http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -
To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER