Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: easiest way to backup&recover Oracle?

Re: easiest way to backup&recover Oracle?

From: Howard Rogers <aldeburgh_at_bigpond.com>
Date: Wed, 16 Apr 2003 17:46:43 +1000
Message-ID: <SI7na.15442$1s1.244454@newsfeeds.bigpond.com>

"Grant" <canuck_tech_at_yahoo.com> wrote in message news:5868625b.0304152221.6f260b5f_at_posting.google.com...
> Hi Howard,
>
> Thanks for your reply. I should have provided more details of my
> specific situation instead of just saying the "easiest" solution. We
> are going to have a rather large database on unix. Based on my
> reading of the oracle doc, it strongly suggests that you use a
> catalog, which means that I need another database, on another server.
> argh.

Not necessary in 9i. Size of database has nothing to do with. If you have rather peculiar or massive backup requirements (ie, something like : we have to keep backups for 7 years for tax purposes; or we have 53 databases to backup), then a catalog is probably the best bet... but if its a single database, and you're in control of what's kept for how long, then the catalog is strictly not needed, and Oracle's recommendation these days is not to bother with one, except in the case of extremely complex backup requirements.

But even then: a catalog is not complicated or terribly big. It's just a simple two tablespace-database. So even if a catalog *is* needed, a simply knock-up database on a Windows PC will suffice for the purpose. Regular exports will do to protect the catalog. It's not a massive beast... about 200MB all up.

>Plus your simple backup doesn't include archive logs,

It does, actually.

>or the
> shell scripts (I'm unix, not Windoz) or any of the other options that
> are necessary (eg. allocating more then one channel for our large db.)

Er, it does, actually. OK, OK... you have to issue, once, a 'configure channel device type disk...' statement to set the number of channels. But it's definitely a set and forget job, and all 'backup database' commands thereafter pick up the setting automatically.

> As for going straight to disk, it won't be practical for us to go to
> the server disk to hold the backups given the size of our database.
> That means we are going to be stuck with tape.. god forbid if we have
> to recover from tape.. GROAN. I was hoping there was something else
> that I wasn't aware of yet.

Well, RMAN will do it to tape, too, provided you configure something like Legato. Which allegedly isn't that hard to do.

>
> So let me re-phrase.. what is the easiest backup and recovery solution
> given some of the items I mention above?
>
> Thanks again! :-)

Strangely enough, it's still RMAN. There's no scripts, just one-off configuration of channel-specific stuff. There's no catalog database unless you truly want one, and even then a peanut-size one on a PC will do duty. It will do it to tape without too much fuss. It's compressible (empty blocks don't get backed up; incremental backups mean only changed blocks get backed up), and your backup times will plummet accordingly.

Anyway: I'm seriously not trying to flog you a dead horse, but keep it in mind. I can think of nothing simpler to configure, that works as advertised, and has extremely minimal overhead requirements.

Not to mention the *enormous* selling point that if a 16GB datafile gets corrupted, you can restore and recover the 90K of corrupted blocks, whilst the rest of the datafile stays online and useable.

Regards
HJR Received on Wed Apr 16 2003 - 02:46:43 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US