In a busy database environment, redo data generation can increase significantly, particularly with the required supplemental logging enabled on your source tables. As we know, an Oracle database will recycle its redo logs in a round-robin fashion, switching to the next log when full. GoldenGate scans the redo logs and writes its own trail files to the dirdat subdirectory. Although the trail file data is typically a quarter the size of its equivalent redo data, if left unmanaged, the volume of files in dirdat can be significant. In the worst case scenario, filling the filesystem to 100 percent utilized. Obviously, this is not ideal, so GoldenGate has provided its own automated mechanism to purge trail files from this area.

This is achieved by configuring the PURGEOLDEXTRACTS parameter in the GoldenGate Manager parameter file as follows:

-- GoldenGate Manager parameter file
PORT 7809
PURGEOLDEXTRACTS ./dirdat/sa*, USECHECKPOINTS, MINKEEPHOURS 1

The USECHECKPOINTS option preserves the trail files in the dirdat subdirectory until the last record in a file is checkpointed. This ensures that no files are deleted that are still required for replication. Additionally, MINKEEPHOURS retains the checkpointed trail files for the specified number of hours.

Another option of the PURGEOLDEXTRACTS parameter is MINKEEPFILES that allows GoldenGate to maintain a minimum number of trail files over and above the MINKEEPHOURS specified. This particular option is rarely used in production environments.

It is important to configure trail file management on both the source and the target to ensure that adequate free space is maintained in your local and remote filesystems even at peak times.

The purging operation is written to ggserr.log as an informational message, as seen in the following code:

2015-04-30 15:16:03  INFO    OGG-00957  Oracle GoldenGate Manager for Oracle, mgr.prm:  Purged old extract file /u01/app/oracle/product/12.1.2/ogg/dirdat/rt000045, applying UseCheckPoints purge rule: Oldest Chkpt Seqno 46 > 45.