Oracle Technical Track

Mining GoldenGate Error Logs for Consumption Rates of Trail Files

1 min read

Dec 5, 2019 12:00:00 AM

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/aa000026339

FYI: 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.

On this page

Ready to unlock value from your data?

With Pythian, you can accomplish your data transformation goals and more.

Speak with Pythian consultants now →

What We Do

Mining GoldenGate Error Logs for Consumption Rates of Trail Files

Share this

Share this

More resources

How to simplify automation: using environment variables

GoldenGate 12.2 big data adapters: part 5 - MongoDB

Oracle GoldenGate microservices architecture - first try.

Ready to unlock value from your data?