Re: Backup strategy

Tom, I agree. (Well, you're the Oracle God after all! :) Nicely done in Oracle Magazine March April 2002 by the way; I enjoyed your ROWID discussion on p13, especially your analogy)

Anyhow, forgive me for feeling and being old-fashioned, but I do feel more comfortable with a full export in the schedule somewhere, even with archivelog turned on; perhaps as I become more comfortable with 9i and equivalent ways to do the same thing, that will change. With our E9000's, we were 23 1/2 x 7; during a shift change in the plant, System A (with all Oracle Services downed) would image over to System B, which hardly took any time at all) and be brought back up before the guys from the old shift got out of the showers or the incomings were done with their donuts and coffee. Archivelogging was of course used on A. Meanwhile colds were copied off of B into the IBM tape monster, as well as dumping all the compressed archived redo logs, followed by bringing B Oracle up and doing a full and incremental export off into the IBMTM.

And then System B's regular life was as a testbed for all Oracle & OA patches / upgrades and such, as well as being the victim of installs / tests/ patches of all the 3rd party s/w. Which saved our lives. So we had an image (or cold if you prefer) backup, data restoral via archivelogging, and a full export and incremental export; the image was the entire system image, UNIX, everything taken in init state s, imaged to B and somehow Tom the Amazing SA dumped B to the IBMTM with all quiescent.

It does help to have to perfectly and absolutely identically configured systems to be able to do this.

With the clustering and other "Breakproof" features of 9i, it sounds as though life will be easier. I just like my full export / incremental kit for disaster recovery where everything goes to hell and say we have to get something going on an Amdahl/Hitachi running UTS, or a DEC Alpha server, knowing that an export can be pulled in to a radically different platform and brought up (at least to the server level; connectivity, app servers, all that, in crisis mode, those aren't the issues as I see em. IE, if the entire plant including data center blows up, the essential thing is bringing up the core, have a team of auditors asking for critical summaries, cross footings, all that muck; meanwhile getting OA up and presumably an appserver for it, etc. But the plant managers and Corporate are going to want to know the status of WIP, finished goods, shipped and billables, received raw materials and cost/value thereof.... and the rest, to hand a certified consolidated report (in SQPLUS or whatever) that the auditors agree with, to the insurance people and the rest.

I just feel more comfortable with the exports in addition to archivelogging. We didn't have a sister site to have a standby set of servers and such, yet; this is what we did in the meantime.

Anyhow that's just the opinion and experiences of a threadbare country bumpkin, for whatever they are worth.

RSH. "Thomas Kyte" <tkyte_at_oracle.com> wrote in message news:a684b70253p_at_drn.newsguy.com...
> In article <a67sf5$4le$1_at_malgudi.oar.net>, "Dale says...
> >
> >We are discussing how we will backup our Oracle 8.1.7 database. We are
going
> >to be doing hot backups for the most part. I'm lobbying for a cold backup
> >once a month. I find it confusing. Oracle recommends a cold backup, and
then
> >says that hot backups should be ok? What do people with experience say?
> >What's the trade off? What are the implications of not doing a cold
backup.
> >Thanks for any information.
> >
> >
>
> In archivelog mode, there is no need to ever do a cold backup. If you
have the
> scripts to do hot, just do hot always. You never need a cold backup, you
always
> have the ability to take a hot and do a point in time recovery -- either
> complete (all data restored) or partial -- just restore upto 12 noon for
> example, skip the updates that happened after that.
>
> --
> Thomas Kyte (tkyte@us.oracle.com) http://asktom.oracle.com/
> Expert one on one Oracle, programming techniques and solutions for Oracle.
> http://www.amazon.com/exec/obidos/ASIN/1861004826/
> Opinions are mine and do not necessarily reflect those of Oracle Corp
>
Received on Sat Mar 09 2002 - 05:09:56 CST