Most Oracle Golden Gate installations, venture to say 80-90%, use the “Classic” capture architecture. What I want to show in this post is how to switch from “Classic” capture to “Integrated” capture.
In the Oracle Golden Gate 12c documentation, the steps provided work but there are a few things that we need to be aware of when trying to switch to integrated capture mode. The steps that are outlined here show you how to get around these missing steps.
Let’s get started!
With any replication environment, we want to identify where we are at within the replication cycle, i.e. what is the current transaction. In code 1, we see how we can do this:
GGSCI (oel.acme.com) 2> send extract ext, showtrans Sending SHOWTRANS request to EXTRACT EXT ... No transactions found Oldest redo log file necessary to restart Extract is: Redo Log Sequence Number 150, RBA 194781712.
Notice that we have no pending transactions and that the Redo Log Sequence Number is 150 with an RBA of 194781712. Now that we know where we are at with transactions, we need to ensure the correct permissions are associated with our GGATE user.
The documentation says to use DBLOGIN USERIDALIAS alias to log into the mining database. In this environment, we are not using a mining database. What we need to do is just make sure that the GGATE user has the right permissions. This can be accomplished by using SQL*Plus or SQL Developer to grant permissions. Image 1 shows how to grant the needed privileges for GGATE with the capture process.
Note: omitting the “capture” option will ensure permissions for both capture and apply processes.
With all the permissions set and knowing where we are with transactions we can now being to migrate the “Classic” extract to an “Integrated” extract. Before we can migrate the extract; always make a backup of the dir* directories in the $GG_HOME.
[oracle@oel oggcore_1]$ zip gg_directories.zip ./dir*/*
Once the backup of the dir* is made; we can proceed by logging into the database from GGSCI.
GGSCI (oel.acme.com) 3> dblogin userid ggate, password ggate Successfully logged into database.
Next, we need to stop the extract that we want to migrate to “Integrated”
GGSCI (oel.acme.com) 5> stop extract ext Sending STOP request to EXTRACT EXT ... Request processed.
Now, register that extract with the database.
GGSCI (oel.acme.com) 7> register extract ext database Extract EXT successfully registered with database at SCN 26468050.
Before the upgrade we need to verify that the extract is ready to be upgraded. This is accomplished with the INFO command.
GGSCI (oel.acme.com) 9> info extract ext upgrade ERROR: Extract EXT is not ready to be upgraded because recovery SCN 26468017 has not reached SCN 26468050.
Notice that we got an ERROR message. This is because the extract is stopped and that the extract was registered with the database with SCN 26468050. The SCN is currently at 26468017 and needs to be incremented to 26468050. How can we do this if the extract is down? It is real simple! Start the extract.
GGSCI (oel.acme.com) 15> start extract ext Sending START request to MANAGER ... EXTRACT EXT starting
Once the extract has been successfully started, we need to stop the extract again.
GGSCI (oel.acme.com) 18> stop extract ext Sending STOP request to EXTRACT EXT ... Request processed.
Now, lets check to see if the extract is ready to upgrade.
GGSCI (oel.acme.com) 19> info extract ext upgrade Extract EXT is ready to be upgraded to integrated capture.
Great! Now the extract is ready to be upgraded. Let’s upgrade it to an “Integrated” extract.
GGSCI (oel.acme.com) 20> alter extract ext upgrade integrated tranlog Extract EXT successfully upgraded to integrated capture.
Now that the extract has been upgraded, we need to try and start the extract.
GGSCI (oel.acme.com) 21> start extract ext Sending START request to MANAGER ... EXTRACT EXT starting
Once the extract has started, we can see that it has stared and all the specific information related to the extract using the INFO command.
GGSCI (oel.acme.com) 25> info extract ext, detail EXTRACT EXT Last Started 2014-04-21 12:42 Status RUNNING Checkpoint Lag 00:00:05 (updated 00:00:05 ago) Process ID 25943 Log Read Checkpoint Oracle Integrated Redo Logs 2014-04-21 12:44:04 SCN 0.26486661 (26486661) Target Extract Trails: Trail Name Seqno RBA Max MB Trail Type ./dirdat/lt 2 1449 50 EXTTRAIL Integrated Extract outbound server first scn: 0.26468050 (26468050) Extract Source Begin End Not Available 2014-04-21 12:37 2014-04-21 12:44 /oracle/app/oradata/bc11g/redo06_1.log * Initialized * 2014-04-21 12:41 /oracle/app/oradata/bc11g/redo06_1.log 2014-04-21 12:37 2014-04-21 12:41 /oracle/app/oradata/bc11g/redo06_1.log 2014-04-15 11:09 2014-04-21 12:38 /oracle/app/oradata/bc11g/redo06_1.log 2014-04-15 11:09 2014-04-15 11:09 Not Available * Initialized * 2014-04-15 11:09 Current directory /oracle/app/product/12.1.2/oggcore_1 Report file /oracle/app/product/12.1.2/oggcore_1/dirrpt/EXT.rpt Parameter file /oracle/app/product/12.1.2/oggcore_1/dirprm/EXT.prm Checkpoint file /oracle/app/product/12.1.2/oggcore_1/dirchk/EXT.cpe Process file /oracle/app/product/12.1.2/oggcore_1/dirpcs/EXT.pce Error log /oracle/app/product/12.1.2/oggcore_1/ggserr.log
With the extract running in “Integrated” mode, we want to see if there are any errors in the GGSERR.log. With the upgrade, there appears to be no real errors in the GGSERR.log; however, we will see two warnings.
OGG-01423 : references a default archive location
OGG-02045 : referring to streams_pool_size initialization parameter
These warning are interesting and bare more investigating; however, for now the extract has been upgraded to an “Integrated” extract.