Re: HELP! Transferring data between instances of Oracle

From: Barbara Kennedy <barbken_at_teleport.com>
Date: Sat, 2 Sep 2000 08:35:06 -0700
Message-ID: <p59s5.10864$3U2.302693_at_nntp3.onemain.com>


A lot of work.
[Quoted] You could create some additional tables on the internal db and some triggers [Quoted] that would log the changes to the additional tables. Then you could write a [Quoted] process that would generate the dml statements to a file that youcould then [Quoted] apply externally. I am assuming that the external db does not have changes [Quoted] that would make applying this log difficult. You could use the dbms_jobs utility to have it automatically create the dml log files.(using the dbms_ package that does writes to disk.)
Jim
"joe martins" <joemartnNOSPAM_at_bellatlantic.net> wrote in message news:rW%r5.4085$0q2.116566_at_typhoon2.ba-dsg.net...
> Hello everyone!
>
> I'm hoping you might have some ideas on how I might approach a problem
 that
> I'm currently trying to resolve.
>
> Here's the deal:
>
> I have one instance of Oracle running on a production server inside our
 new
> firewall. This database contains metadata that is accessed by JSPs
 running
> on an app server. The JSPs are used to serve up pages to users on our
> intranet.
>
> Recently a second app server, a web server and a second instance of Oracle
> were implemented outside of the firewall with plans to host a new web
 site.
> The public web site would be delivered via JSP/servlets running on the
> external instance of the app server.
>
>
>
> I am trying to figure out the best way to transfer data from the internal
> instance of Oracle to the instance up on the web. The catch is that I
 want
> to use my existing Inktomi deployment capability for all of my content
> (audio, video and graphics files as well as the db metadata) The Inktomi
> product provides bulk file transfers between one or more points (but not
 DB
> data transfers).
>
> I was thinking I should use export to dump metadata into a data file.
 Then
> use Inktomi to transfer the file to the external server, then invoke a web
> server side process to import the metadata into the external instance of
 the
> db. I should mention that the schema of the external instance of the DB
 is
> identical to the schema of the internal instance.
>
> Assume the following:
>
> 1. there will be no direct connectivity or accessibility between the two
 db
> instances (for things such as a dblink or replication)
> 2. I may want to update some or all of the metadata residing in the tables
> of the external instance of Oracle as well as insert new metadata.
> 3. updates will be published from the internal servers to the external
> servers quite frequently using Inktomi's deployment tools....on either an
> preset interval or on demand.
> 4. the amount of content residing on the external server would be in the
> neighborhood of several hundred thousand records and files.
> 5. the average amount of content published to the external server and db
> would in the neighborhood of 10-20,000+ records and files.
> 6. Speed of an update, though important, is not my topmost priority.
> Rock-solid reliability and ease of implementation is.
>
> I need a solution that will enable me to:
>
> 1. roll the web db back to a previous state (for instance, roll back to
> before the last update, before the last three updates, etc...)
> 2. scale to multiple external web servers and external instances of Oracle
> where Inktomi could still be used to deploy the db metadata and files to
> each server from the centralized internal production server.
>
> I thought about wiping the web db tables clean between updates and
> populating them with fresh data from the internal db each time. Basically
> like synching the tables. Certainly something to consider but I am hoping
> that you might have a better approach that I could try. I appreciate any
> help that you may provide. Thanks for taking the time to read my post.
 If
> you would need further detail to formulate a response let me know and I
 will
> try my best to provide the missing information.
>
> I look forward to your responses.
>
> Joe
>
>
Received on Sat Sep 02 2000 - 17:35:06 CEST

Original text of this message