Re: Replication question

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