Re: 8.1.7.x, ARCHIVELOG & a NetApp Filer

From: Casey Dyke <cdyke_at_excitehome.com.au>
Date: Sun, 16 Sep 2001 02:58:37 GMT
Message-ID: <3BA4155D.E10ECA4@excitehome.com.au>

Martin Mattel wrote:

> "Raptorfan" <raptorfan_at_earthlink.net> wrote in message news:<tpq1i2atrrna26_at_corp.supernews.com>...

> > Hi. Hoping someone can help me a little. I'm the Unix admin of our site, not
> > the DBA, and I'm a little disturbed by our DBA's resistance on a few things.
> > Hope someone can offer their opinions.
> >
> > We have Oracle databases served by Alphas and sitting on a NetApp filer.
> > What I understand, we run in NOARCHIVELOG mode. Our backup strategy is
> > nightly exports of the databases which are then shoved to tape. Well, I've
> > been tasked with reviewing a purchase request for a redundant Filer with
> > NetApp's SnapMirror product. NetApp (from everything I read) suggests
> > running your databases in ARCHIVELOG mode and storing archive/redo logs on
> > their own separate volume. What I think I understand is the only redo logs
> > really needed are ones where the sequence number is greater than the
> > sequence number in any datafile. NetApp appears to reccomend something like
> > a full-DB snapshot at one time interval (4-8 hours or greater) and a
> > snapshot of the archive/redo logs at a more frequent interval (1 hour or
> > less, depedent on urgency).
> >
> > Now, my "look he's an idiot" questions:
> > * Would I REALLY have to keep all archive/redo logfiles since the last cold
> > backup? Or would maintaining logs from the previous 5-7 days in a standalone
> > snapshotted volume suffice? Keep in mind this is a principally failover
> > system, not a full-out backup system.
> > * Our DBA is more inclined to leave things alone (NOARCHIVELOG) and snapshot
> > the entire database at greater frequency. Opinions? (mine says this approach
> > sucks, but not being too Oracle wise has me grasping at the reasons).
> > * Has anyone else implemented SnapMirror? Opinions, good or bad? (email
> > unless you want to share with the group).
> > * What else should I consider?
> >
> > Any assistance anyone can provide would be appreciated. I've had this thrust
> > upon me with no Oracle background and no Filer background (the training
> > class is next month).
> >
> > -r

r,

I've not used snapmirror, but I can answer a couple of the questions.

• Assuming you switch to archivelog mode, it's good practice to keep {x} days of archive log files around, just in case. You never know which backup (or snapshot in your case) you'll need to use as your baseline to roll forward from. Typical implementations use crontab initiated shell scripts to clean up the archive log directories purging and compressing files on a regular basis according to the rules you create (ie: purge files > 10 days old, compress uncompressed files > 2 hours old ...)
• Running a database in noarchivelog mode exposes you to data loss. You'll only be able to recover to the point of the last backup. If the data is critical, running a database in noarchivelog mode would be a pretty foolish thing to do.
• Using exports as your main backup routine is a little whiffy too. If your data volume is small, it's quite common to use it to cover table drops and what not - but once you get a lot of data, you'd have to be a bit odd to want to fiddle w/imports for recovery. That takes on added weight when you consider using snapshots and snaprestore. Hot backups become quite simple (depending on volume setup) and restores likewise easy. Your class will describe these in detail (although detail ain't much as they're so simple). But, relying on exports as opposed to hot backups in archivelog mode and snapshots/snaprestores is probably not the best policy. All that said - there may be very good reasons why your dba is doing what he's doing. But I'm ... erm ... not sure what they would exactly be. :-)
• Currently, there is a volume to snapshot relationship for Netapp filers (qtrees may change this in the future ????). This means that when you snaprestore a snapshot, the entire volume will be replaced w/that snapshot. Hence, if you combine data and archived redo on the same volume - you will snaprestore your data (which is fine), but not the most recent archived redo. This means no opporunity for rollforward. Seperating the two quite obviously makes sense - likewise control files.
• The frequency with which you snapshot your database files and archive logs should depend on your recovery policy. How much time can you afford to spend rolling forward? My guess is if you're using exports, that policy is loosely defined (if at all). Perhaps the snapmirror solution is intended to quickly resolve your primary filer failure. Similar to standard Oracle standby databases, you want to ensure your recovery methodology and execution via snapmirror/snaprestore is well documented, understood and practiced. Nice to have nifty technology at hand, but obviously important to ensure it works well for you and gives you bang for your buck. I understand snapmirror costs more so its justification will depend on what you want to do w/it.

HTH, Cheers,

Casey ...

Received on Sat Sep 15 2001 - 21:58:37 CDT