Re: Australian trip.

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