RE: 10g RAC B&R Strategies
- From: "Randy Johnson" <oraclelist@xxxxxxxxxxxxx>
- To: "'oracle-l'" <Oracle-L@xxxxxxxxxxxxx>
- Date: Tue, 18 Mar 2008 12:53:32 -0500
[ So, is anyone actually doing this? That is, backing up the FRA to disk
with the 'backup recovery area' command
as per this Metalink note? ]
I had a client who's tape backup software didn't play well with RMAN; that
is it performed poorly and failed frequently. They were working on a
replacement which took several months. We needed an interrim solution so we
could continue to move forward with RMAN rollout. Here's how we did it.
1. Use RMAN to backup the databases to FRA.
2. Using RMAN's oracle.disksbt device, backup the FRA to an NFS file
system (a NetApp Filer).
This file system was mounted by all our database servers and thus
provided a nice centralized location for these "Tape backups".
3. Backup the NFS filesystem to the tape library.
It was a good interrim solution but I wouldn't want to live there long. One
obvious problem was coming up with a strategy for restoring backups from the
tape library to the NFS volume and managing that space gracefully.
My ideal tape backup solution would be to backup the FRA to a vitual tape
library (VTL). This has all the the advantages of backing up directly to
tape without having to manage/share a limited number of physical tape
devices across all your databases. They perform very well and provide an
integrated tape backup solution for RMAN. In this configuration your VTL's
will be migrated to real tape and shipped off site periodically.
-Randy Johnson
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of krish.hariharan@xxxxxxxxxxxx
Sent: Sunday, March 09, 2008 9:43 PM
To: jeffthomas24@xxxxxxxxx; 'oracle-l'
Subject: RE: 10g RAC B&R Strategies
Jeff,
I have seen several variants of "slow tape infrastructure". The bottom line
is that you should be able to satisfy the throughput requirements of your
backup. Having dealt with close to 80TB of backup using RMAN/NetBackup, I
would examine the assertion that you are able to scrape your backups to tape
(after a write to disk) but not able do that do that directly to tape; a
different story if you are not licensed for the VERITAS DBE (rman libobk)
then you are left to the task of scraping file systems.
Since you have asserted that upgrading the tape subsystem is not feasible
you can try a two pronged approach.
1. Backup to /backup: I would avoid the FRA unless you have other
motivations. Implement /backup and application VIP and a listener to go with
it which RMAN can attach to and thus RMAN connection would follow the VIP
2. Determine the bottleneck on the slow tape infrastructure. Often
times it is the network that surrounds it. In addition, depending on your
version of Veritas NetBackup you have the Disk Storage Unit (DSU) option
which can speed things up so that you are not bound by a circuit to tape.
Regards,
-Krish
Krish Hariharan
President/Executive Architect, Quasar Database Technologies, LLC
http://www.linkedin.com/in/quasardb
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jeffery Thomas
Sent: Sunday, March 09, 2008 6:27 PM
To: oracle-l
Subject: 10g RAC B&R Strategies
I have some serious doubts concerning our ability to devise a simple but
robust B&R strategy
with 10g RAC given some architectural constraints.
We have a slow tape infrastructure where we cannot directly stream RMAN
backups to tape.
Instead, with our current 9i VERITAS RAC systems, we have a shared file
system (/backup) to which
we stream our RMAN backups, with nightly O/S backups coming along and
copying the contents
of /backup to tape.
We are nearly ready to start building some new 10g RAC systems on Solaris,
and the plan was to
use a FRA. In addition, the plan was to use ASM only, no 3rd-party
clustered file systems such as Sun
Clusterware or VERITAS. As a result we can have a /backup file system on
only ONE node of the
cluster, due to the lack of a clustered file system other than ASM.
As stated in earlier threads in the Oracle-l archives as per RMAN backups to
the FRA: "FRA is primarily
a backup to disk to tape strategy. Backup to the FRA then backup the FRA
to tape."
Obviously, given our current configuation, we cannot do that.
As for backing up the FRA to disk, I found Metalink Note 420290.1, dated
March 2007, "Backup Flash
Recovery Area to Disk Location":
"The 'backup recovery area' command only works with SBT (tape) channels.
There is a planned fix to allow DISK
channels to be supported. The RMAN disksbt library, which emulates a SBT
library (but writes backups to disk location),
can be used as a supported workaround to backup the FRA to a disk location".
So, is anyone actually doing this? That is, backing up the FRA to disk
with the 'backup recovery area' command
as per this Metalink note?
As I see it, our options for backups, given: 1) No direct streams to tape,
and 2) /backup file system on
one node are:
1) Create the FRA, make RMAN backups to it, and try the SBT_LIBRARY option
to backup the FRA to
/backup.
2) Create the FRA, make RMAN backups to it, and then backup the backupsets
to the /backup file system,
using something like this: 'backup backupset all format '/backup/...'
3) Do not use the FRA to store RMAN backups. Only use the FRA for archived
logs, and make our RMAN
backups to /backup, similar to our 9i strategy. Not really a practical
option.
Of course, for all 3 options, if the node where /backup is attached goes
down, there might be a little problem.
Other than *fix the tape drives" (not going to happen), or "get a 3rd party
clusterware in addition to ASM"
(possible), do we have other options?
Thanks,
Jeff
Other related posts:
