There are three places where time zone matters: the time-based data, the lag time report, the trail file I/O time.
- The time-based data: Oracle GoldenGate extract by default uses the source database time zone to keep the record data and writes the time zone information to the trail file after the Oracle GoldenGate 12c. Oracle GoldenGate replicat by default also sets its session to the source database time zone. However, you can overwrite it to a different time zone using the SOURCETIMEZONE parameter or PRESERVETARGETTIMEZONE in replicat to set the apply session to the target time zone.
- Lag time: The checkpoint time is stored in Coordinated Universal Time (UTC). Oracle GoldenGate GGSCI commands, such as the info and send <extract/replica_group> status commands, convert to the lag time report to local timezone where GGSCI runs.
- Trail file I/O time: The trail file I/O time is stored in UTC. When looking at trail file content with Logdump utility, the time is converted to the local OS time zone running the Logdump utility.
When performing remote capture and delivery across time zones, such as the replication hub architecture shown as follows, you need to configure Oracle GoldenGate to be aware of the time zone differences between the source database and the OS running Oracle GoldenGate process (including extract and replicat).
You can choose any time zone for your replication hub. No matter where you run the GoldenGate extract and replicat processes, the timezone in data records stay intact. They are replicated in source database timezone along with the source database time zone information in the trail file. If you have a choice, then choosing the same time zone as the source database.
- Avoid using commands with "Begin Now or Begin Timestamp" but to use the SCN to start any extract. This is because the “NOW” uses the time and timezone of the local machine running the GoldenGate process.
- Use the heartbeat tables to check the lag time in general.