Goldengate 12c lendo direto do Oracle Active Dataguard “ADG”

Olá a todos.

O nova release de Goldengate 12c está conseguindo ler diretamente do Active Dataguard, isso é muito bom, irá ajudar muitas empresas.

Segue abaixo como fazer essa nova configuração:

Configuring Classic Capture in Oracle Active Data Guard Only Mode
You can configure classic Extract to access both redo data and metadata in real-time to successfully replicate source database activities using Oracle Active Data Guard. This is known as Active Data Guard (ADG) mode. ADG mode enables Extract to use production logs that are shipped to a standby database as the data source. The online logs are not used as all. Oracle GoldenGate connects to the standby database to get metadata and other required data as needed.
This mode is useful in load sensitive environments where ADG is already in place or can be implemented. It can also be used as cost effective method to implement high availability using the ADG Broker role planned (switchover) and failover (unplanned) changes. In an ADG configuration, switchover and failover are considered roles. When either of the operations occur, it is considered a role change. For more information, see Oracle Data Guard Concepts and Administration and Oracle Data Guard Broker.

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.

Configuring Extract for ADG Mode
To configure Extract for ADG mode, follow these steps as part of the overall process for configuring Oracle GoldenGate, as documented in Chapter 8, “Configuring Capture in Classic Mode.”

  1. Enable supplemental logging at the table level and the database level for the tables in the primary database using the ADD SCHEMATRANDATA parameter. If necessary, create a DDL capture. (See Section 3.2, “Configuring Logging Properties”.)
  2. When Oracle GoldenGate is running on a different server from the source database, make certain that SQL*Net is configured properly to connect to a remote server, such as providing the correct entries in a TNSNAMES file. Extract must have permission to maintain a SQL*Net connection to the source database.
  3. On the standby database, use the Extract parameter TRANLOGOPTIONS with the MINEFROMACTIVEDG option. This option forces Extract to operate in ADG mode against a standby database, as determined by a value of PRIMARY or LOGICAL STANDBY in the db_role column of the v$database view.
    Other TRANLOGOPTIONS options might be required for your environment. For example, depending on the copy program that you use, you might need to use the COMPLETEARCHIVEDLOGONLY option to prevent Extract errors.
  4. On the standby database, add the Extract group by issuing the ADD EXTRACT command specifying the number of threads active on the primary database at the given SCN. The timing of the switch depends on the size of the redo logs and the volume of database activity, so there might be a limited lag between when you start Extract and when data starts being captured. This can happen in both regular and RAC database configurations.

Migrating Classic Extract To and From an ADG Database
You must have your parameter files, checkpoint files, bounded recovery files, and trail files are stored in shared storage or copied to the ADG database before attempting to migrate a classic Extract to or from an ADG database. Additionally, you must ensure that there has not been any intervening role change or Extract will be mining the same branch of redo.

Use the following steps to move to an ADG database:

  1. Edit the parameter file ext1.prm to add the following parameters:
    DBLOGIN USERID userid@ADG PASSWORD password
    TRANLOGOPTIONS MINEFROMACTIVEDG
  2. Start Extract by issuing the START EXTRACT ext1 command.

Use the following steps to move from an ADG database:

  1. Edit the parameter file ext1.prm to remove the following parameters:
    DBLOGIN USERID userid@ADG PASSWORD password
    TRANLOGOPTIONS MINEFROMACTIVEDG
  2. .Start Extract by issuing the START EXTRACT ext1 command.

Handling Role Changes In an ADG Configuration
In a role change involving a standby database, all sessions in the primary and the standby database are first disconnected including the connections used by Extract. Then both databases are shut down, then the original primary is mounted as a standby database, and the original standby is opened as the primary database.
The procedure for a role change is determined by the initial deployment of Classic Extract and the deployment relation that you want, database or role. The following table outlines the four possible role changes and is predicated on an ADG configuration comprised of two databases, prisys and stansys. The prisys system contains the primary database and the stansys system contains the standby database; prisys has two redo threads active, whereas stansys has four redo threads active.

Initial Deployment Primary (prisys) Initial Deployment ADG (stansys)
Role Related:
TRANLOGOPTIONS MINEFROMACTIVEDG
Database Related:
After Role Transition: Classic Extract to classic Extract After Role Transition: ADG to ADG
1.Edit ext1.prm to change the database system to the standby system: 1.Edit ext1.prm to change the database system to the primary system:
DBLOGIN USERID userid@stansys, PASSWORD password DBLOGIN USERID userid@prisys, PASSWORD password
2.If a failover, add TRANLOGOPTIONS USEPREVRESETLOGSID. 2.If a failover, add TRANLOGOPTIONS USEPREVRESETLOGSID.
3.Start Extract: 3.Start Extract:
START EXTRACT ext1 START EXTRACT ext1
Extract will abend once it reaches the role transition point, then it does an internal BR_RESET and moves both the I/O checkpoint and current checkpoint Extract will abend once it reaches the role transition point, then it does an internal BR_RESET and moves both the I/O checkpoint and current checkpoint to SCN s.
SCN s. 4.If failover, edit the parameter file again and remove:
4.If failover, edit the parameter file again and remove: TRANLOGOPTIONS USEPREVRESETLOGSID
TRANLOGOPTIONS USEPREVRESETLOGSID 5.Execute ALTER EXTRACT ext1 SCN #, where# is the SCN value from role switch message.
5.Execute ALTER EXTRACT ext1 SCN #, where# is the SCN value from role switch message. 6.Based on the thread counts, do one of the following:
6.Based on the thread counts, do one of the following: If the thread counts are same between the databases, then execute the START EXTRACT ext1; command.
If the thread counts are same between the databases, then execute the START EXTRACT ext1; command. or
or If thread counts are different between the databases, then execute the following commands:
If thread counts are different between the databases, then execute the following commands: DROP EXTRACT ext1
DROP EXTRACT ext1 ADD EXTRACT ext1 THREADS t BEGIN SCN s
ADD EXTRACT ext1 THREADS t BEGIN SCN s START EXTRACT ext1
START EXTRACT ext1
Initial Deployment Primary (prisys) Initial Deployment ADG (stansys)
Original Deployment:
ext1.prm ext1.prm
DBLOGIN USERID userid@prisys, PASSWORD password DBLOGIN USERID userid@stansys, PASSWORD password
TRANLOGOPTIONS MINEFROMACTIVEDG
Database Related:
After Role Transition: Classic Extract to ADG After Role Transition: ADG to classic Extract
1.Edit the ext1.prm file to add: 1.Edit ext1.prm and remove:
TRANLOGOPTIONS MINEFROMACTIVEDG TRANLOGOPTIONS MINEFROMACTIVEDG
2.If a failover, add TRANLOGOPTIONS USEPREVRESETLOGSID. 2.If a failover, add TRANLOGOPTIONS USEPREVRESETLOGSID.
3.Start Extract: 3.Start Extract:
START EXTRACT ext1 START EXTRACT ext1
Extract will abend once it reaches the role transition point, then it does an internal BR_RESET and moves both the I/O checkpoint and current checkpoint to SCN s. Extract will abend once it reaches the role transition point, then it does an internal BR_RESET and moves both the I/O checkpoint and current checkpoint to SCN s.
4.If failover, edit the parameter file again and remove: 4.If failover, edit the parameter file again and remove:
TRANLOGOPTIONS USEPREVRESETLOGSID TRANLOGOPTIONS USEPREVRESETLOGSID
5.Execute ALTER EXTRACT ext1 SCN #, where # is the SCN value from role switch message. 5.Execute ALTER EXTRACT ext1 SCN #, where # is the SCN value from role switch message.
6.Based on the thread counts, do one of the following: 6.Based on the thread counts, do one of the following:
If the thread counts are same between the databases, then execute the START EXTRACT ext1; command. If the thread counts are same between the databases, then execute the START EXTRACT ext1; command.
or or
If thread counts are different between the databases, then execute the following commands: If thread counts are different between the databases, then execute the following commands:
DROP EXTRACT ext1 DROP EXTRACT ext1
ADD EXTRACT ext1 THREADS t BEGIN SCN s ADD EXTRACT ext1 THREADS t BEGIN SCN s
START EXTRACT ext1 START EXTRACT ext1

Sobre Alexandre Pires

ORACLE OCS Goldengate Specialist, OCE RAC 10g R2, OCP 12C, 11g, 10g , 9i e 8i - Mais de 25 anos de experiência na área de TI. Participei de projetos na G&P alocado na TOK STOK, EDINFOR alocado na TV CIDADE "NET", 3CON Alocado no PÃO DE AÇUCAR, DISCOVER alocado na VIVO, BANCO IBI e TIVIT, SPC BRASIL, UOLDIVEO alocado no CARREFOUR e atualmente na ORACLE ACS atendendo os seguintes projetos: VIVO, CLARO, TIM, CIELO, CAIXA SEGUROS, MAPFRE, PORTO SEGURO, SULAMERICA, BRADESCO SEGUROS, BANCO BRADESCO, BASA, SANTANDER, CNJ, TSE, ELETROPAULO, EDP, SKY, NATURA, ODEBRESHT, NISSEI, SICREDI, CELEPAR, TAM, TIVIT, IBM, SMILES, CELEPAR, SERPRO,OKI,BANCO PAN, etc
Esse post foi publicado em GOLDENGATE e marcado , , . Guardar link permanente.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s