- The process hasn't processed any record yet
- The source system's clock is ahead of the target system's clock due to the clock imperfections or timezone differences.
When performing remote capture/delivery, it's recommended that Oracle GoldenGate's operating system (OS) clock is synchronized with the database clock and is within the same timezone.
GGSCI> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING JAGENT STOPPED EXTRACT RUNNING EXTECS1 unknown 00:00:06 EXTRACT ABENDED PMPECS1 00:00:00 01:22:07
Answer: If the extract lag value is shown as unknown, then there could be two reasons:
- The process hasn't processed any record yet.
- The source system's clock is ahead of the target system's clock due to the clock imperfections or timezone differences.
GGSCI> lag extgdrds Sending GETLAG request to EXTRACT EXTGDRDS ... Lag unknown (timestamp mismatch between source and target).
SQL> SELECT DBTIMEZONE FROM DUAL; DBTIME ------ +00:00 SQL> SELECT TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') "NOW" FROM DUAL; NOW ------------------- 05-17-2017 15:50:21
>date Wed May 17 11:50:21 EDT 2017
To show the correct lag time, you can change the time and timezone setup on the Oracle GoldenGate side. The following is an example to change the time zone GGCS virtual machine timezone to UTC:
sudo cp -p /etc/localtime ~backup_localtime_$(date +%Y%m%d_%T) sudo cp -p /etc/sysconfig/clock backup_clock_$(date +%Y%m%d_%T)
ZONE="Etc/UTC"
sudo cp –p /usr/share/zoneinfo/UTC /etc/localtime
sudo shutdown -r now
GGSCI (ip-172-30-3-169.ec2.internal) 1> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING EXTRACT RUNNING EXTGDRDS 00:00:09 00:00:05 EXTRACT ABENDED PMPGDRDS 00:00:00 00:00:16
Use lag extract, instead of info extract, get the lag time more precisely, because it directly communicates with extract to obtain the lag time rather than reading the checkpoint position in the trail.