Oracle GoldenGate: A Quick Dive into Trails, Records, Transactions, and RBAs
Hello OGG Admins!
I’d like to quickly share a draft and summary of key concepts in Oracle GoldenGate (OGG): transactions, records, trail files, and RBA.
This image illustrates how Oracle GoldenGate stores data changes inside trail files.
Each database operation, such as: INSERT, UPDATE and DELETE is captured as a single record, and multiple records are grouped into a single transaction, which is only completed when a COMMIT occurs. Even when a transaction contains multiple operations ( I / U / D ), OGG preserves and guarantees transactional integrity when writing to the trail. In other words, a single transaction may contain one or many records.
So, how is this stored in the trail file?
Each record is written sequentially and identified by an RBA (Relative Byte Address), which represents its exact position within the file.
This means that, inside a trail file, we have a sequence of records, but we must always respect the transaction boundaries they belong to. If we ignore this and arbitrarily reposition replication processes (for example, starting from a specific RBA without considering the full transaction), there is a high risk of breaking transactional integrity, and yes, this unfortunately happens more often than it should.
I recorded a video explaining this scenario in more detail here:
https://www.youtube.com/watch?v=rlPfv9CmpO4
The RBAs are essential for tracking, recovery, and restart operations, allowing OGG to resume processing precisely from a specific point.
The RBA is calculated incrementally based on the size of each record. For example, if the current position is RBA 10,235 (which also reflects the current trail file size in bytes), and a new record of 64 bytes is written, the next RBA will be 10,299, and the trail file size will grow as well. Wow, bet you didn’t know that, did you? 
Understanding the relationship between transactions, records, and RBAs is fundamental for anyone working with GoldenGate, especially when troubleshooting, tuning, or designing reliable real-time data replication architectures.
Tell me, did you like this topic?
If you’d like to learn more about topics like this, just let me know.