Golden gate extract from multiple oracle db's on different servers

Question

Hello,
I am new to golden gate and I want to know if is it possible to extract data from an oracle database which is on a different server? Below is the server list
Linux server 1: has oracle database (11.2.0.4) (a1db) and golden gate installed (11.2.1.0.3).
Linux server 2: has oracle database (11.2.0.4) (b1db)
a1db and b1db are not clustered, these are 2 separate instances on 2 different servers.
Is it possible to capture change data on b1db from GG installed linux server 1? I am planning to use classic capture.
architecture like below, can it be done? If so what option I will be using in the extract
Thanks,
Arun

Answer 1

Here is something from my personal notes; hope this helps:
Standby or Off Host Environment
GoldenGate extracts, data pumps and replicats can all work with database environments accessed using TNS.  When one of these processes needs to work with a database environment over TNS then instead of the following USERID specification:
setenv (ORACLE_SID = “GGDB")
USERID ggsuser, PASSWORD encrypted_password_cipher_text
The following USERID specification would be used:
USERID ggsuser@GGDB, PASSWORD encrypted_password_cipher_text
When this specification is used the setenv line is not required since the process will connect over TNS.
When a data pump or replicat is running in a standby or otherwise an off host environment the USERID specification above is the only special requirement.  It is recommended that the TNS entry contains the necessary failover and service name configuration so that if or when switch over or fail over occurs, the process may continue once the environment is available again.  if the data pump is using the PASSTHRU parameter then a USERID specification is not required.  When the data pump is operating in PASSTHRU mode, it does not need a database connection to evaluate the metadata.
When a source extract is running in a standby or otherwise off host environment the USERID specification above is required as well as Archive Log Only mode.  It is recommended that the TNS entry contains the necessary failover and service name configuration so that if or when switch over or fail over occurs, the process may continue once the environment is available again.  The source extract requires a database connection in order to evaluate the metadata that occurs in the archived redo log.  Since the source extract is running in an environment separate from the source database environment it is unable to read the online redo logs.  Therefore it is required to be configured in Archive Log Only mode.  If the environment that the source extract is running in is a standby environment, then it will evaluate the archived redo logs through switchover. 
The standby or off host environment has minimal requirements. The requirements that need to be met are Oracle software availability and storage for archived redo logs.  If the database environment where GoldenGate will be running is a standby database environment then GoldenGate can utilize the required shared libraries from the standby database environment.  However if GoldenGate is being executed from a server environment does not contain a database environment, a client installation is required at a minimum.  This will provide GoldenGate with the necessary shared libraries in order to satisfy it’s dynamically linked library dependencies.  The archived redo logs must also be available for GoldenGate to read.    They can be made available using a shared storage solution or with a dedicated storage solution.  A standby database environment works well for this purpose as it is receiving archived redo logs on a regular basis.  GoldenGate is able to leverage these archived redo logs and not impose any additional infrastructure requirements in order to evaluate and capture the data changes from the source database.  In order for GoldenGate to be utilized with a standby database environment for archived redo log access, only a minimal standby database is required.  Specifically the standby database needs to be be mountable so that it can accept archived redo logs.  Since GoldenGate will connect to the primary database to evaluate the metadata contained in the archived redo logs, a complete standby database is not required.