Re: Manual update / replication on a live database?

John K. Hinsdale wrote:
> > [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).

The OP already noted that the size may increase well beyond this stated size in a different reply in this thread. The OP doesn't seem to be able to predict a limiting maximum size at this time.

>
> 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?

It works well for development projects and to refresh test systems. Trying to leverage it into the receiving end of "what might or might not be" a production database has complications. See my replies in other posts in this thread.

>
> 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:

Varies based on what type of standby is implemented etc but yes there are valid considerations.

>
> 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.

Doesn't seem to be enough evidence to make that kind of conclusion so far to me at least.

>
> 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 - 13:17:41 CST