This content has been marked as final. Show 6 replies
GoldenGate has a forum over here:
The purging will take place after both conditions have been met:
At least 2 days have passed
No other process needs the trail (with respect to checkpoints)
Given that more than 2 days have passed, I would check for checkpoint dependency.
From the Troubleshooting guide:
✔Are you using PURGEOLDEXTRACTS to manage the trail?● If not, add PURGEOLDEXTRACTS to the Manager parameter file to prevent old files from
● If you are using PURGEOLDEXTRACTS, make certain that the Manager user has the
authority to purge trail files, and make certain that the PURGEOLDEXTRACTS options are
used correctly. See the Oracle GoldenGate Windows and UNIX Reference Guide.
✔ Is there an obsolete Replicat group that is linked to the trail?
● A trail file will not be purged if another process has a checkpoint in it. Delete the
obsolete group with the DELETE REPLICAT command, so that the checkpoint records are
● If a checkpoint table is being used for the group, log into the database with the DBLOGIN
command first, so that the checkpoint will be removed from the table.
DBLOGIN [TARGETDB <dsn>,] [USERID <user>, PASSWORD <pw>]
DELETE REPLICAT <group>>
Are you using a data pump? If not (but you should as a best practice), then why the purgeoldextracts for the manager on the source? Also, the path there is app1 versus app on the target, in case that is the difference (i.e., check the path on the target for where the manager is supposed to be looking).
Steven, thank you for your post.
I found the error. I forgot to restart mgr after adding this:
Once I restarted mgr all trail files older than 2 days were deleted in seconds.
Appreciate your help.
Sorry, assumed that was running to begin with, or that if a change was made, it was stopped/re-started to pick up the change.
There is a manager refresh command that can be used.
It can be used in place of manager re-start .
Can you please post the manager refresh command?
The GGSCI REFRESH MANAGER command enables you to change any Manager parameter except the port number without stopping and restarting the Manager process.
If you have previously put in a manager parameter and now remove it from the parameter file, the REFRESH MANAGER command WILL NOT revert back the missing parameter to its default value. This does not apply to the PORT parameter.
It is recommended that instead of using the REFRESH MANAGER command, one should STOP and START the manager process. This will ensure that the manager parameter file reflects the actual manager environment.
This command is now dropped from the Version 11g Oracle GoldenGate documentation.