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: Angie <angie_kong_at_hotmail.com>
Date: Thu, 17 Apr 2003 07:43:03 GMT
Message-ID: <bWsna.26470$Zx.9548@nwrddc01.gnilink.net>


Btw, do try restoring on a regular basis. I really believe tapes are evil and they will mysteriously stop working just when you've got a disaster and the only copy of data left is in that tape. :-)

"Howard Rogers" <aldeburgh_at_bigpond.com> wrote in message news:SI7na.15442$1s1.244454_at_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 Thu Apr 17 2003 - 02:43:03 CDT

Original text of this message

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