We require your valuable advise on the following business issue, we are facing.
Our oracle database is in a highly-secured on local intranet.
We have a requirement to replicate oracle data base available on WAN to our internal network. Our internal security
policy does not allow two-way communication with source databases. However, source can send us the archievelogs (and
have hardware/software components which will transport the archivelogs to our internal network with SOURCE-TO-TARGET
Communication only; TARGET CANNOT CONNECT/communicate TO THE SOURCE DATABASE)
Given this constraint how can we replicate the ORACLE DATABASE available on WAN to our intranet? We have explored
various possibilities like, GOLDENGATE, PHYSICAL STANDBY, STREAMS etc. All require the connection from TARGET to
Another Option we are looking at a ORACLE logical standby. Consider the following scenario.
1. Initially, set up a LOGICAL STANDBY (TRAGET-DATABASE) at the TARGET-LOCTAION from SOURCE-DATABASE
2. At the SOURCEDATABASE set up an extra ARCHIVELOG_DESTINATION LOCATION (say in a FILESERVER located in the source side)
3. The SOURCEDATABASE copies the ARCHIVELOG to the FILESERVER.
4. Using FTP, push the ARCHIVELOG (from the above step) to a FILESERVER in the TARGET LOCATION (one-way communication ).
5. In the TARGET LOCATION, apply the ARCHIVELOG from FILESERVER in the TARGET LOCATION to TARGET_DATABASE (LOGICAL STANDBY DATABASE).
Please advise, in the above scenario, will TRAGET-DATABASE needs to communicate with SOURCE-DATABASE to do the SQL-APPLY? Will the LOGICAL STANDBY be answers to our problem?
Or Do you suggest another approach to this Problem?
You input will be very valuable.
To summaries the requirement:
1. Communication only available from OUTSIDE SSD (source_) to INSIDE (ONE WAY COMMNUCATION ONLY)
2. ORACLE @ various sources different versions (starting from 9i to 10g to 11g
3. Replicate the whole data base @ source as it is to the destination,
4. Each source DB be replicated to each separate destination db.
5. We need to capture the changes to the ORACLE DB @ the destination, so that the changes can be applied to the production systems.