Re: Manual update / replication on a live database?

tcp100 wrote:
> Ok folks. Let me see if I can explain this in no uncertain terms.
>
> Hiring is not a possibility. Changing the requirements is not a
> possibility. Man, I wish I could do both.
>
> I'm not going to get too deep into this, because, well, I cannot..
> However I imagine most of you folks work in private industry, where
> things such as hardware and human resources are somewhat "flexible".
>
> If you couldn't tell by my crypticness already, we're talking about
> dealing with a bureaucratic, governmental situation here.
>
> There is no headroom, there is no ability to bend rules or hire people,
> at least without a good year of red tape. Budgets are set, hardware is
> allocated, security policies are in place. It would take acts and laws
> to change them. So again, hiring an expert to analyze the situation
> isn't an option, nor is installing connectivity or bending the uptime
> rules. We're trying to get a remote 24/7, yet unconnected office
> running with some semblance of currentness under these unfortunate
> constraints.
>
> So, with that out of the way, I appreciate the help that has been
> given; I realize that at an outside glance, folks are saying "why in
> the world would you do things this way??" Trust me, we were scratching
> our heads pretty hard when we got this requirement.
>
> Regardless, Mr. Hinsdale's option is complete, from what I see - and
> will keep us up. In the interrim, "complex" as it may be, it makes
> sense for the situation. The only thing that I'd really like to know
> is if there's a way to do this incrementally, since right now the
> database size is able to be handled, but I'm guessing that it -could-
> grow unwieldy for this at some point soon; this is a relatively new
> database.

Ok earlier you said it is a small database about 700 meg. Now you are hinting that it could become a large database?

You don't want to be handling schema level imports and exports on a large database ... they quickly become unwieldy.

>
> John, I understand what you've explained about the hardware match. You
> make a good point - I cannot guarantee hardware will match on either
> side, so it sounds like the Dataguard idea, although it looks more
> straighforward, is not as simple of an option, actually, once that's
> considered.
>
> However -- and I'm not sure how this would work out - I was considering
> perhaps running both sides in a VMWare VM or Solaris Container, which
> would at least give me some environment configuration freedom, pending
> that the processors on both machines were relatively the same; so that
> could be a work-around there.
>
> I'm definitely going to start doing some research on the Dataguard and
> other possibilities, unfortunately time constraints are tough, which is
> what brought me here. If anything, I'm looking for an interrim
> solution.
>
> hpuxrac, what do you find unrealistic in Mr. Hinsdale's approach? I'm
> not asking out of criticism, I'd actually like to know, since to me it
> makes sense and seems do-able; the only thing of any concern is the
> schema "switch" for a few seconds - which I think could be scripted to
> be relatively painless.

Many applications would not be able to cope with "finding the data" for awhile in one schema then later on switching and finding the data in another schema. Using synonyms is one possibility to help reduce that burden.

If you go that route you are going to have to do a lot of work to make sure that it is very well tested.

What's the possibility that there are multiple schema's involved in the application(s) with dependencies between them?

When you are doing the schema switching you are taking downtime. This is already violating what you had said earlier had to be a 24/7 type of continuous availability.

What is most unrealistic is that this sounds like a kludged up approach to a problem that oracle has already addressed via standby databases data guard etc.

Why re-invent the wheel? You are already buying into some limited downtime already by thinking this alternative may be somewhat viable.

Then again if it's a government contract there's some motivation for consultants to kludge up something that takes continuing contract hours to support and maintain.

>
> Again, if there's an easier option, I'm definitely still open to it --
> but please try and ignore the oddness of the requirements; I know
> they're weird, but they're inflexible. That's why I came here for some
> help.
Received on Wed Jan 03 2007 - 12:18:16 CST