Tags
Goldengate tunable processes are:
— Extract
— Pump
— Replicat
The processes need tuning based on the load on source and target. GG has the capability to handle 60GB per hour (as per Oracle update). In order to handle the load very well, it’s more appropriate to use multiple processes to divide and process the work load.
Ofcourse, in most of the smaller databases where redo generation is in few GB’s one extract would be fine. You can determine by gathering the stats and lag of the processes:
STATS EXTRACT/REPLICAT
SEND EXTRACT/REPLICAT
Use send command and gather required stats/info like:
CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEPOOL}
GETLAG
GETTCPSTATS
LOGSTATS
REPORT
For an Oracle database utilising ASM for Classic Extract the DBLOGREADER parameter enables extract to use a newer ASM API that is available as of Oracle 10.2.0.5, 11.2.0.2 onwards. The API uses the database server to access the redo and archive logs, instead of connecting directly to the Oracle ASM instance. When used, DBLOGREADER enables Extract to use a read size of up to 4MB in size. This is controlled with the DBLOGREADERBUFSIZE option.
Refer metalink note:
OGG How to address Extract Performance Issue When Reading Archive Logs stored in Oracle ASM (Doc ID 1363266.1)
Datapump, relies on network performance. So gather network stats, and tune network related parameter accordingly:
GETTCPSTATS
Based on the observed stats during the high load time, tune the below parameters:
TCPBUFSIZE and TCPFLUSHBYTES
You can also use COMPRESS for high transfer rates but it adds little overhead on the CPU.
Replicat:
Things to consider on target side:
— BATCHSQL
— MAXTRANSOP (Split large transactions)
— MAXSQLSTATEMENTS (speed up update process)
— GROUPTRANSOPS
It’s highly recommended to test multiple configurations and see the throughput.