Issue:
Why does GoldenGate report the Lag is unknown? The "Lag" command fails with "Timestamp Mismatch". Sometimes the "Info All" will also show the Lag is unknown.
How to troubleshoot the problem?
Add a user token to a test table.
e.g.,
table scott.emp, tokens (tkn-time = @DATENOW());
Next, do a dml on this table and commit.
Then, check with logdump (set: usertokens detail) to compare the record commit time (this is from redo log) and the token (from os time when extract processes the record). if former
time is later then the one from token, it may cause this 'unknown' display.
Solution Overview:
(1) Lag Command(after handling one or more records)
GGSCI > lag extract e1
Sending GETLAG request to EXTRACT E1...
Lag unknown (timestamp mismatch between source and target).
At EOF, no more records to process.
(2) "Info All"(This may happen after handling a large amount of records)
GGSCI > info all
Program Status Group Lag Time Since Chkpt
MANAGER RUNNING
EXTRACT RUNNING E1 unknown 00:00:04
(3) "showch" and date timestamp mismatch
GGSCI > info e1 showch
...
Checkpoint Lag unknown (updated 00:00:03 ago)
Log Read Checkpoint File /rdbms/oracle/ora1022i/64/oradata/ora1022a/redo01.log
2007-03-12 13:36:48 Seqno 3724, RBA 32885344
.....
GGSCI > sh date
Mon Mar 12 12:37:08 PDT 2007
Solution Details:
The first thing to check is to make sure the timezone environmental parameter is set correctly. Here are the steps to set the correct timezone TZ environmental parameter.
Example
$ > env |grep TZ
TZ=PST9PDT
$ > date
Mon Mar 12 12:40:57 PDT 2007
$ > export TZ=PST8PDT
$ > date
Mon Mar 12 13:41:08 PDT 2007
You must re-start the Manager and all other GoldenGate groups.
If the TZ environmental parameter is not the issue, then there is another condition under which the "timestamp mismatch" message may be displayed. The "timestamp mismatch" may also be displayed when the Extract or Replicat is completely caught up and a LAG
command is issued. The LAG command will try to compute the difference between current timestamp on target versus the actual timestamp of the processed record (which comes from the source). When the difference is actually a negative value, then we will display
the "timestamp mismatch" message. If these times are very close, this can be when we calculate a negative lag (target timestamp - record timestamp).
Related symptom:
If TZ difference is in another direction, the related extract and replicat may display unexpected lag. If the process is at EOF, the lag may be on and off, when on
it shows several hours (the TZ difference) lag.