Limitations and Requirements for Using ADG Mode

Observe the following limitations and requirements when using Extract in ADG mode.

• Extract in ADG mode will only apply redo data that has been applied to the standby database by the apply process. If Extract runs ahead of the standby database, it will wait for the standby database to catch up.

• You must explicitly specify ADG mode in your classic Extract parameter file to run extract on the standby database.

• You must specify the database user and password to connect to the ADG system because fetch and other metadata resolution occurs in the database.

• The number of redo threads in the standby logs in the standby database must match the number of nodes from the primary database.

• No new RAC instance can be added to the primary database after classic Extract has been created on the standby database. If you do add new instances, the redo data from the new thread will not be captured by classic Extract.

• Archived logs and standby redo logs accessed from the standby database will be an exact duplicate of the primary database. The size and the contents will match, including redo data, transactional data, and supplemental data. This is guaranteed by a properly configured ADG deployment.

• ADG role changes are infrequent and require user intervention in both cases.

• With a switchover, there will be an indicator in the redo log file header (end of the redo log or EOR marker) to indicate end of log stream so that classic Extract on the standby can complete the RAC coordination successfully and ship all of the committed transactions to the trail file.

• With a failover, a new incarnation is created on both the primary and the standby databases with a new incarnation ID, RESETLOG sequence number, and SCN value.

• You must connect to the primary database from GGSCI to add TRANDATA or SCHEMATRANDATA because this is done on the primary database.

• DDL triggers cannot be used on the standby database, in order to support DDL replication (except ADDTRANDATA). You must install the Oracle GoldenGate DDL package on the primary database.

• DDL ADDTRANDATA is not supported in ADG mode; you must use ADDSCHEMATRANDATA for DDL replication.

• When adding extract on the standby database, you must specify the starting position using a specific SCN value, timestamp, or log position. Relative timestamp values, such as NOW, become ambiguous and may lead to data inconsistency.

• When adding extract on the standby database, you must specify the number of threads that will include all of the relevant threads from the primary database.

• During or after failover or switchover, no thread can be added or dropped from either primary or standby databases.

• Classic Extract will only use one intervening RESETLOG operation.

• If you do not want to relocate your Oracle GoldenGate installation, then you must position it in a shared space where the Oracle GoldenGate installation directory can be accessed from both the primary and standby databases.

• If you are moving capture off of an ADG standby database to a primary database, then you must point your net alias to the primary database and you must remove the TRANLOG options.

• Only Oracle Database releases that are running with compatibility setting of 10.2 or higher (10g Release 2) are supported.

• Classic Extract does not support the DBLOGREADER option. Use ASMUSER (there is approximately a 20gb/hr read limit) or move the online and archive logs outside of the Application Security Manager (ASM) on both the primary and the standby databases.

  Note:

  The combination of MINEFROMACTIVEDG and DBLOGREADER options is not supported with Classic Extract. However, the Extract process will start without any warning or error even though this combination is used. Ensure that you do not use this combination while using classic Extract with ADG.