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: Replication between two Oracles

Re: Replication between two Oracles

From: Steven Crimmins <crimmins_at_nospam.us.easyphone.com>
Date: 28 Sep 1999 12:54:05 PDT
Message-ID: <37efa2d5.16995998@news.concentric.net>


Hi,
Here are some clarifications. Thanks for the assistance!

I do not require the ability to update the tables that have been replicated. Consider them read only. I believe that this ties into option 3) below.

I don't believe that there will be conflicts that should affect the remote snapshot. The data should remain pretty consistent and should never be deleted in the master database.

I have been looking at the Snapshot functionality with refresh groups. I think that this will fulfill my requirement, however I am still interested in other possibilities that I should look into.

The Snapshot documentation mentions that it requires the distributed option within the Oracle database. I am not sure if Oracle Workgroup Server (which is what we are running on NT) includes this option or whether it is a priced add-on.

Thanks
Steve

On Mon, 27 Sep 1999 09:26:58 -0700, Pete Sharman <psharman_at_us.oracle.com> wrote:

>This is a multi-part message in MIME format.
>--------------4DD291A34DB9E2A69D200638
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Steve
>
>You have a number of options that you can choose from, but there's not
>enough information in your posting to determine which are not valid for
>you. So let me give you the list of possible options as a starting
>point:
>
>1. Leave the tables in one database and reference them from the other via
>DB links. Downside here is that if the database with the tables is
>unreachable for any reason, the database referencing the tables via the
>links won't get to them either.
>
>2. Regular scheduled export, ftp, import. Data is not in synch until the
>import, and you have to write and maintain the scripts to do this.
>
>3. Master - read only snapshot configuration. Data is only updatable on
>one site, so this may require some fancy coding to make transparent if
>users on the read-only site want to update the data on the master site.
>
>4. Master - updatable snapshot. Gets around the limitation of 3, but you
>need to investigate conflict resolution methods.
>
>5. Master - master replication. Same comment as 4.
>
>As for costing, that's something I don't keep track of (it's all free to
>me!), so contact your sales rep about that.
>
>HTH.
>
>Pete
>
>Steven Crimmins wrote:
>
>> Hi,
>> I have the following scenario and would appreciate any suggestions.
>> (I would also ask that you email responses to me.)
>>
>> We have an Oracle 8 running on NT Server and a separate Oracle 8
>> running on Solaris for x86. There will be a T1 link between the two
>> Oracle's with TCP/IP.
>>
>> There is a series of tables on the Oracle 8 Solaris that need to be
>> replicated (or perhaps the data will be shared in a different fashion)
>> to the Oracle NT.
>>
>> The rate of transactions is low. One or two tables may have less than
>> 10 transactions per minute. The remaining two or three tables usually
>> only have perhaps 100 updates that occurs in the evening.
>> (There are only about 5 tables total to "share".)
>>
>> What are my best options to keep the data in synch? I do not need
>> instantaneous updating to occur, however I would like Oracle to handle
>> the Oracle to Oracle communications if possible (hence I would not
>> change the underlying applications).
>>
>> If any suggestions are priced products (which is acceptable) please
>> let me know the relative price of the components and where they need
>> to be installed.
>>
>> Thanks
>> Steve
>
>--------------4DD291A34DB9E2A69D200638
>Content-Type: text/x-vcard; charset=us-ascii;
> name="psharman.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Description: Card for Pete Sharman
>Content-Disposition: attachment;
> filename="psharman.vcf"
>
>begin:vcard
>n:Sharman;Peter
>tel;cell:+1.650.868.9969
>tel;fax:+1.650.633.1669
>tel;work:+1.650.607.0109
>x-mozilla-html:FALSE
>url:http://eif.us.oracle.com
>org:Advanced Technology Solutions;Oracle Corporation
>adr:;;500 Oracle Parkway M/S OPL-A4019;Redwood Shores;California;94065;USA
>version:2.1
>email;internet:psharman_at_us.oracle.com
>title:Managing Principal Consultant
>note;quoted-printable:=0D=0A=0D=0A **** The statements and opinions expressed here are my **** <br>=0D=0A **** own and do not necessarily represent those of **** <br>=0D=0A **** Oracle Corporation. =20 **** <br>=0D=0A <br>=0D=0A"Controlling application developers is like herding cats." <br>=0D=0AKevin Loney, ORACLE DBA Handbook <br>=0D=0A=0D=0A"Oh no it's not! It's much harder than that!" <br>=0D=0ABruce Pihlamae, long term ORACLE DBA <br>

>x-mozilla-cpt:;26064
>fn:Pete Sharman
>end:vcard
>
>--------------4DD291A34DB9E2A69D200638--
>
Received on Tue Sep 28 1999 - 14:54:05 CDT

Original text of this message

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