Re: What is the best way to replicate few tables between 2 Oracle 10g severs ?

From: <stevedhoward_at_gmail.com>
Date: Fri, 17 Apr 2009 13:36:00 -0700 (PDT)
Message-ID: <4a92f4aa-e2fc-477c-9e77-4010aa37c6d1_at_b16g2000yqb.googlegroups.com>



On Apr 17, 12:13 pm, Michael Austin <maus..._at_firstdbasource.com> wrote:
> stevedhow..._at_gmail.com wrote:
> > On Apr 16, 2:50 am, Veeru71 <m_ad..._at_hotmail.com> wrote:
> >> We need to replicate (1-way)  a bunch of  tables from Server-A to
> >> Server-B in close to real-time.
> >> Server-B is located in a foreign country.
>
> >> Apporx. # of tables to be replicated : 50   (size : 50 GB)
> >> Approx amount of data that gets replicated (changed data) per day :
> >> 100 MB
> >> Oarcle Versions : 10g, Solaris
>
> >> Constraints (due to some security reasons):
> >> - Server-B SHOULD NOT have any DB-Links to connect to Server-A
> >> - No UserId/Password of Server-A should be used anywhere in scripts/
> >> code/config files, etc   on Server-B.
>
> >> What is the best way to achieve this ? Initially we thought of using
> >> Matreialized Views,  but because of the above constraint, it may not
> >> be feasible.
>
> >> Do you think Oracle Streams would work ?  Would it be an over-kill ?
> >> Any other options ?
>
> >> Thanks for your help.
>
> > For the amount of data you are talking about (100MB per day), you can
> > probably get away with just triggers on the DB A tables that insert
> > into DB B.
>
> > The streams option always bothers me, personally.  We used it to
> > migrate a fairly large database last year on what was then 10.2.0.3
> > from AIX single node to Linux RAC, and we had all kinds of weird
> > issues, about 20 one-offs to apply, you name it.  We were beginners
> > with streams, so I'm sure we were inefficient in how we set it up, but
> > I wouldn't call it "easy" to configure, especially with database that
> > generate a lot of redo.
>
> > YMMV,
>
> > Steve
>
> With the security requirement of near real-time (not yet quantified
> here) no pwd in config files and no dblinks, you are going to be
> hard-pressed to find any solution that does not require a pwd for
> authentication. Configuring some sort of SSL with public key exchange
> might be of some help (Streams can do SSL - just not sure where exactly
> the pwd/key is authenticated - and have not had to do this just yet).

Agreed. In this case though, the OP said server B couldn't connect to A, but not vice - versa (although it may have the same restrictions, but they weren't stated). Received on Fri Apr 17 2009 - 15:36:00 CDT

Original text of this message