Mining GoldenGate Error Logs for Consumption Rates of Trail Files
After resolving Oracle GoldenGate issues, a question typically asked is, "When will the process catch up?" The usual method to find out is to use the lag command; however, I was more interested to see the rate of the trail file being consumed. One method to do this is to mine ggserr.log for the GoldenGate process, e.g. replicat.prm. From the data below, replicat is consuming trail at rate of ~7m per trail. Hence, if there are 10 more trails to process then it will take ~70m to complete.
grep "replicat.prm: Switching to next trail file" ggserr.log| tail 2019-11-14 14:50:20 replicat.prm: Switching to next trail file dirdat/aa000026334 2019-11-14 14:56:42 replicat.prm: Switching to next trail file dirdat/aa000026335 2019-11-14 15:02:43 replicat.prm: Switching to next trail file dirdat/aa000026336 2019-11-14 15:08:19 replicat.prm: Switching to next trail file dirdat/aa000026337 2019-11-14 15:17:42 replicat.prm: Switching to next trail file dirdat/aa000026338 2019-11-14 15:23:46 replicat.prm: Switching to next trail file dirdat/aa000026339FYI: I have removed some non-relavant columns to make the format cleaner. I didn't capture lag information for comparison. You can do this as a comparison for future issues. Hopefully, the information is useful for your next troubleshooting efforts.
Share this
You May Also Like
These Related Stories
GoldenGate 12.2 big data adapters: part 3 - Kafka
GoldenGate 12.2 big data adapters: part 3 - Kafka
Mar 31, 2016
16
min read
GoldenGate 12.2 big data adapters: part 4 - HBASE
GoldenGate 12.2 big data adapters: part 4 - HBASE
May 11, 2016
13
min read
GoldenGate 12.2 big data adapters: part 5 - MongoDB
GoldenGate 12.2 big data adapters: part 5 - MongoDB
Sep 8, 2016
14
min read
No Comments Yet
Let us know what you think