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: Manual update / replication on a live database?

Re: Manual update / replication on a live database?

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: 3 Jan 2007 05:22:34 -0800
Message-ID: <1167830554.691174.89240@n51g2000cwc.googlegroups.com>

tcp100 wrote:
> Oh.. And for details, I think this will work.. We're dealing only with
> about half a million rows - the database size is about 700mb. Not too
> crazy at all.
>
> Most of these are inserts, I will wager that there are no deletes save
> for the occasional development / administrative one, and few updates.
>
> I think this process will work - of course incremental would be better,
> but from what I'm hearing, copying a redo log over and restoring it
> won't meet my zero downtime requirement -- but it could meet a "low"
> downtime requirement if reasonable.. (Unfortunately that's not where I
> stand.)
>
> Thanks again for the advice...
>

The advice Mr. Hinsdale sent in doesn't make a lot of sense to me and is highly complicated and full of unrealistic client connection assumptions.

If I were you I would spend time reading the oracle concepts documentation first available at http://tahiti.oracle.com and then read up specifically on data guard.

Matt Hart has a book that might be worth looking at called Oracle Database 10g High Availability specifically for you probably the chapters on Data Guard and rman.

It might be worth your time doing some research and reading and think about hiring for at least a couple of days an oracle consultant experienced in high availability designs. While you are pursuing that work on clarifying the management expectations and business drivers for this whole esoteric setup.

If the situation ( as you already stated ) really is that the database is only 700 meg then you can probably patch something together using cd's for archive logs ( not ONLINE redo logs ... archived copies of them instead ). Kludgy and unsophisticated but perhaps workable with such a small database.

Why approach the whole situation like this in the first place with such a small database though? Received on Wed Jan 03 2007 - 07:22:34 CST

Original text of this message

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