Forum Stats

  • 3,874,832 Users
  • 2,266,778 Discussions


Goldengate Lag

user8610659 Member Posts: 83 Blue Ribbon
edited Apr 9, 2011 5:48PM in GoldenGate
Dear All,

I am stuck in a unique problem. I have installed OGG 11g in HPUX-11.3. We are replicating 80 tables from Production to DR site(distance around 1500 kms). We have successfully configured OGG and replication is done in 4 - 8 seconds ( result is varying). This is not acceptable since client requires max 3 to 4 seconds LAG.

Following is the configuration:

1. 80 tables are divided among 5 groups of extraction, data pump and replicat groups.

2. This bifurcation is done basis on primary - foreign key relation and on basis of frequency of transaction.

3. Some tables contain greater than 30 columns which are accesses at high rate( 1 has 96 columns - its main table for every transaction). There are both insert and update operation on these tables.

4. The Network bandwidth is 300 MBPS.

5. I tried using the @RANGE function to split the rows/columns for the tables but its of no use.

6. I tried online replication technique in which we dont use the Data Pump process. Here the data is not stored locally. It is sent directly to DR site where the REPLICAT process transfers the data to DB. Even though LAG was 4 to 7 secs

7. Initially I felt this may be due to large number of columns. Hence I created a dummy table ( with 3 columns including a primary key columns and entered some dummy data) and performed replication of this table. Here too the LAG varied from 3-7 seconds.

8. I tried every trick in OGG manuals right from FLUSHCSECS to TCPFLUSHBYTES to @RANGE (For parallel extract process) to CACHEMGR to BATCHSQL, the LAG was still varying from 4 to 8 secs.

9. I created a single extract, pump and replicat group. Even then result varied from 4 to 8 secs

10. The transaction is 60000 per day. Future rate will be 10 Lakh transaction per day.


1. I am unable to understand why the LAG is varying. I cant pinpoint the source of LAG. Is it the way i have configure, or network or disk speed.

2. When using Data Pump process following is output of LAG * command:

delay from ext5 - 0 secs---->this is extraction process. result varies to 0-2 secs

delay for edumpm5 2 secs --->data pump process. this result sometimes varies to 3 or 4 secs

delay for repc5 --> 5 secs ---> replicat process. result varies from 3 to 8 secs

3. Is there any way that we can find out the exact lag for each process (other than OGG commands)?

4. Do we require any kind of tuning to DB?

Please guide me to resolve this issue


  • stevencallan
    stevencallan Member Posts: 3,459
    Well, there are two places you have some control over.

    First, tune the network connection used by the data pump. Increase the bandwidth, send larger packets, find out what your txn times are. Tools like ping, tracert, to name a couple. You can see some details about this in Oracle maximum availability architecture whitepapers, plus there is a note or two on MOS related to tuning the network. With the tools shown there, you can figure out what your max rate over your network is. If you can't do any better, that is the show stopper. Get a faster connection.

    Second, you don't have any control over what is being DML'd and getting into extract. But, you do have some control over how data is DML'd in the target. Do you have a lot of indexes? Is most of the DML insert related? You can disable indexes, use direct path insert (the append hint), things like that. Of course, there is the issue of whether or not some of those indexes are needed by users for queries, so testing is required.
  • user8610659
    user8610659 Member Posts: 83 Blue Ribbon
    One more thing I have forgotten to add is currently the scenario is ACTIVE-PASSIVE. After a month, it will in ACTIVE-ACTIVE mode. So indexes options is bit challenging. Also there are mainly insert operation and for each insert operation, there is 1 or more update operation on the same table.
    I feel that can this be issue of slower disc?
  • stevencallan
    stevencallan Member Posts: 3,459
    Feel how? There is no feel, there is knowing. Run an AWR report on your databases and see what the avg read/write IO times are for tablespace and files. If those are high (> 10ms), start tuning the IO system.
  • user8610659
    user8610659 Member Posts: 83 Blue Ribbon
    Dear Steve,

    We checked the IO times for tablespace, it is normal.
This discussion has been closed.