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@xxxxxxxxx> 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@xxxxxxxxx> wrote: > > > > Can anyone present a solution please? > > Sandeep > > > > On 9/20/05, Sandeep Dubey <dubey.sandeep@xxxxxxxxx > 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@xxxxxxxxxxx> 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 > > > > > > > > > > > > > > > > -- > > > > //www.freelists.org/webpage/oracle-l > > > > > > > > > > > > >