I have two database instances on the same server :
instance A - server X
instance B- server X
Instance A is a part of the golden gate replication, with one manager program (MGR) and one extract program (EXT1).
If i want to include instance B in a golden gate replication do i need to install another golden gate instance and to configure a new manager process or it's enough to configure a new extract process (EXT2) which extracts data from instance B on the existing golden gate configuration ?
I am assuming when you say database instance, you mean Oracle instance.
The Manager doesn't make a database connection; the Extract does. Normally the Extract will know which instance to connect to based on the environment variables that are passed to it, but you can direct the Extract to another instance by using the SETENV parameter in the Extract parameter file to set the ORACLE_HOME and ORACLE_SID. For example:
setenv (ORACLE_HOME = /oracle/product/database/1020)
setenv (ORACLE_SID = "pxc01d")
So yes, you can direct a second Extract in the same GoldenGate instance to connect to a different Oracle instance. Note that the GoldenGate build would need to be for the correct database version for both Extracts (such as 10g, 11g, etc.)
It would be better to use separate instances of GoldenGate for the two databases. Do you want a problem with one to crash replication with the other? No.
Bad information in prior post - The manager *can* make a database connection - what is the USERID parameter for in the manager parameter file? See the Reference guide. Plus the admin guide.
Recommended Manager parameters
The following parameters are optional, but recommended, for the Manager process. For
more information about these and additional Manager parameters, see the Oracle
GoldenGate Windows and UNIX Reference Guide.
● AUTOSTART: Starts Extract and Replicat processes when Manager starts. This
parameter is required in a cluster configuration, and is useful when Oracle GoldenGate
activities must begin immediately at system startup. (Requires Manager to be part of
the startup routine.) You can use multiple AUTOSTART statements in the same
● AUTORESTART: Starts Extract and Replicat processes again after abnormal termination.
This parameter is required in a cluster configuration, but is also useful in any
configuration to ensure continued processing.
● PURGEOLDEXTRACTS: Purges trail files when Oracle GoldenGate is finished processing
them. Without PURGEOLDEXTRACTS, no purging is performed and trail files can consume
significant disk space. For best results, use PURGEOLDEXTRACTS as a Manager parameter,
not as an Extract or Replicat parameter.
● STARTUPVALIDATIONDELAY | STARTUPVALIDATIONDELAYCSECS: Sets a delay time after which
Manager validates the run status of a process. Startup validation makes Oracle
GoldenGate users aware of processes that fail before they can generate an error
message or process report.
● USERID: Required if using Oracle GoldenGate DDL support.
Thank you for that correction, you are right, the Manager can make a database connection, and does so to perform DDL maintenance activity such as PURGEDDLHISTORY and PURGEMARKERHISTORY. The Extract does not inherit that database connection from the Manager though, and two Extracts could still connect to two different source instances.
I'm not sure I understand how a problem with one instance would crash replication with the other. Could you explain that a little more?
If a common process (manager) crashes, replication stops on both sources. If an extract error propagates up to crashing the common manager, as another possibility. If one group needs to be updated and the other one does not. If the Oracle version (library) changes on one and not the other because one of the databases gets upgraded, and the other does not.
If a common process (manager) crashes, replication stops on both sources. --> Actually, if the Manager stops, it does not affect the Extract processing. It does mean that if an Extract failed, Manager would not be there to restart it, and Manager would not be there to report lag.
If an extract error propagates up to crashing the common manager, as another possibility. --> Can't think of an Extract error that would affect Manager processing.
If one group needs to be updated and the other one does not. If the Oracle version (library) changes on one and not the other because one of the databases gets upgraded, and the other does not. --> Absolutely correct. They might need to be split if the DB version diverged, and any OGG upgrade would affect both Extracts. Definitely a consideration.
There are definitely pros and cons either way. If both Extracts are in one environment, you would only have one OGG environment to manage and maintain. But if you have them separate, you decouple them which gives you flexibility in other ways in terms of upgrades and environment settings specific to each Extract.