Re: Australian trip.

Guy G wrote:
>
> wizofoz2k_at_yahoo.com.au (Nuno Souto) wrote in message news:<73e20c6c.0305071358.4c587c7b_at_posting.google.com>...
> > ggallagher_at_espeed.com (Guy G) wrote in message news:<470e4f07.0305070927.6a95712b_at_posting.google.com>...
> >
> > > - Your datafiles total 345 GB
> > > - You have 170 GB of disk available for backups
> > > - Tape backup is not an option
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Praying is always an option...
> >
> > Failing that, you could look at using compression?
> > Oracle data files usually compress more than 50:1.
> >
> >
> > > - Your redo logs switch 5-6 times per hour; size is 200MB
> >
> >
> > Definitely compression will be needed!
> >
> >
> > > - Database must be online 24 X 7, or close to it
> >
> > Cool. Another exercise in fitting
> > large animals through eyes of needles?
> >
> >
> > Cheers
> > Nuno Souto
> > wizofoz2k_at_yahoo.com.au.nospam
>
> Thanks, Nuno. I forgot to mention that this is 8.1.7.4, if that
> matters. Used to be 8.1.7.0 until one of the instances went south
> with rollback segment block corruption (I was in day 3 of my first
> Oracle class at the time) - that's when the voice crying in the
> wilderness began to get a hearing. After the two weeks it took to
> recover the data (no backups). The Oracle Trousers division
> thankfully was not involved.
>
> I'm only getting 2:1 or at best 3:1 compression on the datafile backup
> pieces - we're actually using a fair amount of the allocated space.
> Redo is a little better - about 5:1.
>
> I actually do have a strategy of sorts - for one instance only (NOT
> the one that crashed, of course) - tablespace backups (RMAN) of two
> out of six user tablespaces, each twice per week. I arrived at this
> through trial and (much) error, finding that more frequent backups
> would fill the backup directory - at some point it is necessary to
> write a 36 GB file and compress it (another 17 GB), and this kills
> everything. Oh yeah, and it might be nice to have the recovery
> catalog on a different piece of hardware ...
>
> Of course, this "strategy" stinks, which is why I asked that *trick*
> question - I don't think there *is* a good strategy given the
> constraints, but I'm still a bit wet behind the ears, so ...
>
> I did lay out three options to the folks with the checkbooks - keep
> using RMAN and attach lots of disk to the server ($$ for disk), keep
> using RMAN and back up directly to tape (possibly $$ to enhance the
> tape backup infrastructure), or purchase SQL-Backtrack (third-party
> tools are not my first choice for various reasons, but the combination
> of on-the-fly compression and avoidance of begin/end backup and all it
> entails make this an intriguing possibility in this specific case - of
> course, this costs $$, too). I've asked in all cases for sufficient
> space to keep 2 complete backupsets online - need to keep the first
> until the second is done - and one of the great things about RMAN is
> the way it makes restore/recovery a no-brainer if everything is where
> RMAN thinks it is. Maybe I'm asking too much - after all, I don't pay
> the bills, I just have to get things fixed yesterday when they break
> today. Anyway, why complain? Where else can I have this much fun and
> get paid, too?
>
> Thanks again
>
> - GG

Without being too cynical, I honestly believe if you need the disk space for rman backups, rather than fork out megabucks on server-based disk, just go out and grab:

1. bottom of the range PC, install linux
2. stuff a few 320G IDE drives into it
3. nfs the space out to your real server during backup times

and voila! you've got a terabyte of disk for a small dollars. Sure its probably slow, unreliable, but you could workaround some of these issues by copying each backup to different disks, or just using it as staging area before copying to tape etc...

Its not fancy or optimal, but it can be used effectively

hth
connor

-- 
=========================
Connor McDonald
http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue"