Rodd,
Thanks for answering. But for a merge from say 1 Million row table with
1000 new rows to source table, there will be 1000 insert but rest 999,000
rows will be updated even though there is no change in the record. This will
be done every time I do the merge. Also it will not handle delete on the
source table. Delete on a source table will not be deleted from target table
using merge operation.
Thanks
Sandeep
On 9/20/05, Rodd Holman <Rodd.Holman_at_gmail.com> wrote:
>
> If you can do the db links from C to A and B why not
> create synonyms to the tables in A and B
> then do merge of the data using a package/procedure that you schedule
> by job queue or cron.
> merge table_at_a into tableC
> merge table_at_b into tableC
> You would control the data with a pull on the time line of your choosing
> from the data center.
> This would assume that you have a primary key on tableC to eliminate
> duplicate key values.
>
> Another option would be a scheduled dump of data from A and B into a
> tablespace that you export
> and transport into C. This would be more work, but doesn't require the
> dblinks if they are the problem.
>
> Rodd
>
> Sandeep Dubey wrote:
>
> > So you only help on this list when are you paid? Why are you speaking
> > about others as "WE". I am sure you must have learnt a lot from this
> > list without paying a dime to anyone. Has anyone ever made such a
> > bizzare statement to you?
> >
> > Mine is a valid business requirement. We want to pull the data
> > periodically from databases A and B and merge into C without opening
> > any security risk to C. All databases are exactly same. I will
> > appreciate if you can tell what is so onerous about it. Is this
> > something that cannot be implemented???
> >
> > Regards
> > Sandeep
> >
> >
> > On 9/20/05, *sol beach* <sol.beach_at_gmail.com
> > <mailto:sol.beach_at_gmail.com>> wrote:
> >
> > With free advice you get what you paid for it!
> >
> > We are NOT being paid to solve YOUR problems;
> >
> > especially when the requirements are onerous.
> >
> >
> >
> > On 9/20/05, *Sandeep Dubey* <dubey.sandeep_at_gmail.com
> > <mailto:dubey.sandeep_at_gmail.com>> wrote:
> >
> > Can anyone present a solution please?
> >
> > Sandeep
> >
> >
> > On 9/20/05, *Sandeep Dubey* <dubey.sandeep_at_gmail.com
> > <mailto:dubey.sandeep_at_gmail.com>> wrote:
> >
> > Yes, the databases are exactly identical - same scripts to
> > create tablespace, tables, indexes, views, whatever. We
> > are currently in 9i. Replication should be near real time
> > - 15 to 30 minutes are acceptable but not overnight.
> >
> > I can create db link from C to A or B. A and B are remote
> > databases while C is in our data center.
> > So how do I do it. Create readonly snapshots for A and B
> > separately. How do you merge in to C's main table? Or is
> > it possible to have C's table as updateable snapshot
> > which is also a table for its application?
> >
> > Sandeep
> >
> >
> > On 9/20/05, *Mark Bole* <makbo_at_pacbell.net
> > <mailto:makbo_at_pacbell.net>> wrote:
> >
> > Sandeep Dubey wrote:
> >> Hi,
> >>
> >> I have three identical databases say A, B and C.
> >
> > Identical tablespaces? Identical schemas? Identical
> > tables, keys,
> > constraints?
> >
> > I want to replicate
> >> from A and B to C. Meaning C will have its own data
> > plus the data from A
> >> and B. I can not create a db link from A or B
> > pointing to C for security
> >> reasons.
> >
> > Create dblinks in C for A and B instead.
> >
> > Also handing over the stream_admin password of C to A
> > and B to
> >> push their changes through streams is not very good
> > idea. I can not have
> >> multimaster replication as C is not sending its
> > change to A or B.
> >>
> >> Please suggest how this can be done?
> >
> > You didn't mention version. Transportable
> > tablespaces? Export/Import?
> > Log Miner?
> >
> > Is any one using streams to capture
> >> data from remote database to your data center? Seems
> > like streams push
> >> technology is a security hole.
> >
> > Any method of taking data out of one database and
> > loading it into
> > another is going to have security issues, especially
> > if you want it to
> > run unattended. Your management needs to decide what
> > level of risk they
> > will accept to achieve a certain level of benefit.
> >
> > --
> > Mark Bole
> > http://www.bincomputing.com
> > <http://www.bincomputing.com/>
> >
> >
> >
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> >
> >
> >
>
>
> --
> Rodd Holman
> Enterprise Data Systems Engineer
> LodgeNet Entertainment Corporation
> rodd.holman_at_gmail.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Sep 20 2005 - 14:26:41 CDT
