Re: Manual update / replication on a live database?

> [Sybrand Bakker]
> The 'solution' of Mr. Hinsdale is *extreemly* complicated,
> and you won't have ANY downtime using a standby database.

I did not use the word "solution" in my proposed approach, so I don't understand why that word is quoted above. Recall, I wrote:

 > [John Hinsdale]
 > Knowing nothing else, though, below is one option I'd
 > consider if it were me.  ... I'm not sure an "offline"
 > incremental solution is possible, but I would not know.

I suggested one option, a choice to be accepted or rejected. And I hope I was transparent enough in expressing my ignorance of an "'offline' incremental" (i.e,. Data Guard) approach, which seems to be alternately proposed, albeit in less detail. Let's try to help ol' Chris out here. It's frustrating to have limited visibility to Chris's detailed situation, but the Usenet Code of Honor requires us to assist best we can, no?

Now that we know the database is under 1GB, I continue to see the imp/exp approach as viable -- possibly uniquely so, depending on hardware and O/S details (see below).

Actually, I'm a bit surprised to see the imp/exp approach viewed as the "complicated" one. I do this as a developer, to freshen development and test copies of my systems, precisely for its simplicity. This is for modest size (under a few gig's) databases; terabyte databases are another matter. What's so complicated about a few scripts to dump (at the source), then drop and reload (at the destination)? I've been doing this for years. Am I missing something?

I'm also surprised no one pointed out my imp/exp approach required double capacity at the destination "readonly" site for the two copies. That's for me the main cost.

> [Sybrand Bakker]
> The only thing that can go wrong is unreadable archives
> (as a result of the copy procedure) and/or not all
> archives being applied.

Other gotchas exist: we should also advise Chris that the use of Data Guard also carries with it some restrictions not incurred by the imp/exp approach: the CPU hardware (32- vs. 64-bit) and O/S software must match at the "live" site and the "readonly" site. See:

http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10823/standby.htm#72054

With the imp/exp option (I've not called it a "solution!") Chris's organization is free to run the "readonly" copy on any hardware (32-bit, 64-bit), O/S platform (Linux, Solaris, Windows) and Oracle version, largely independent of what environment is in use at the "live" site. His organization seems to be resource-limited, so I'd not be surprised to see different platforms, or at least the prospect of such, at the two sites.

Chris: if there are differences, either now or EVER, in the hardware or O/S environments at your live site vs. your "copy" site you'll need to be aware of them when considering a Data Guard option. I.e., if your environments are, or will be, sufficiently different you may not have "offline Data Guard" as an option. Do let us know how it works out. I'm curious as to what ends up working. And good luck!

          John Hinsdale Received on Wed Jan 03 2007 - 11:02:43 CST