Re: Backup options (including Arcserve Agent for Oracle)?

From: Paul Drake <paled_at_home.com>
Date: Sun, 10 Jun 2001 01:27:59 GMT
Message-ID: <3B22CCA2.1EBB64F@home.com>

Frank Burleigh wrote:
>
> We are buying new server hardware and converting from Sybase to Oracle
> 8i/9i in the very near future. Our environment will be Intel servers
> with Win2000 Server, Arcserve 2000 for backup, and RAIDed drives. Our
> database consists mainly of our alumni and current students. My Sybase
> backup routine is an automated (nightly) DUMP of the database to a file
> on the file system which then goes to tape via the Arcserve NT agent. I
> had to restore once--because of drive failure (no RAID on that box).
>
> My question is this: what are opinions on the best way to backup in a
> situation like ours? My initial inclination is to use the "hot"
> approach outlined in Loney's book: it is similar to what we do now and
> is fairly straightforward to implement. But without Oracle experience,
> I thought I should ask for other data points.
>
> Also, Arcserve sells an Oracle agent, but it isn't quite clear to me
> what its advantage would be over this "hot" (archivelog) method. They
> claim to work at the logical level rather than with file objects, but I
> don't immediately see what that gets me other than--maybe?--not having
> to script the backup process.
> --
> Frank Burleigh
> Indiana University School of Law
> burleigh_at_indiana.edu

Frank,

The ARCServe Oracle Agent merely executes the same thing that a scripted hot backup job would accomplish.
a bit of pseudo_code:

for each tablespace

   alter tablespace begin backup;
   for each datafile in tablespace

      host ocopy <data_file_name.dbf> to <backup_dest>;    end for
   alter tablespace end backup;
end for
alter database backup controlfile to <backup_dest>;

It will likely provide the solution that you are looking for - provided that you are not using the Oracle RMan utility.

Before going further - I'd like to ask your availability requirements. - what are the uptime requirements?

        e.g. Can you bring the database down for cold backup on sunday morning at 2 AM?
- how many transactions can you afford to lose?

        this will influence the frequency in which you want to force a log switch
- do you have staff that can perform maintenance during off-peak time windows?

        will you need more than one server such that maintenance can be performed during work hours.

In general, I would recommend the following:

weekly	logical dump (export) of database, compressed, copied to tape.
	(check the log file for reports of corrupt blocks)
weekly	cold backup of database to the filesystem, compressed, copied to
tape.
	(use the dbv.exe utility to examine the datafiles in the backup set for
corrupt blocks)
nightly	hot backup of database to the filesystem, compressed, copied to
tape. 
	(your own scripts or ARCServe Oracle agent)
	(use the dbv.exe utility to examine the datafiles in the backup set for

corrupt blocks)
nightly management of archived redo logs, copied to tape.

If possible, keep a backup set of datafiles on disk to decrease your time to recovery.
also - keep all archived redo logs on disk (in addition to copied to tape) as old as the oldest datafile in your backup set (also on disk).

with 18 GB drives being the norm on Intel-based Servers - if you have enough spindles in the system - you should have an adequate amount of space to house a backup set + archived redo logs on disk.

You mentioned that this box will have a RAID configuration. That does not assist in handling logical corruptions in the Oracle files.
- Are you planning on enabling write-back caching on your RAID controller? (risks involved)
- Are you planning on using multiple members in a redo log group on separate RAID volumes?

One week ago I had to recover a database that had write-back caching enabled by the system administrator.
The online redo logs were not mirrored - so a single failed write operating corrupted the database.

hth.

Paul Received on Sat Jun 09 2001 - 20:27:59 CDT