Re: HELP! Transferring data between instances of Oracle

Thanks for the response Jim. BTW, your assumption was correct, the external db is straightforward. In fact, it is configured identical to the internal db at the moment.

"Barbara Kennedy" <barbken_at_teleport.com> wrote in message news:p59s5.10864$3U2.302693_at_nntp3.onemain.com...
> A lot of work.
> You could create some additional tables on the internal db and some
 triggers
> that would log the changes to the additional tables. Then you could write
 a
> process that would generate the dml statements to a file that youcould
 then
> apply externally. I am assuming that the external db does not have
 changes
> 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 Sun Sep 03 2000 - 02:51:41 CEST