dbi Blog

When automating your GoldenGate deployments, or tearing down a test environment, handling trail files is important. In fact, deleting an extract or a replicat does not delete the trail files it was writing to or reading from. It leaves the trail resource itself behind too, causing confusion (or worse) later.

Indeed, a fresh extract writing to the same trail name/path keeps appending after the old sequence numbers instead of restarting at 000000000. A fresh replicat starts reading from 000000000 by default. If you don’t remove the trail files when re-creating an extract and replicat pair, the extract will do its job. However, the new replicat has no way to tell leftover files apart from new ones. It will read whatever is still sitting in 000000000 and onward as if it were live data.

The adminclient does have a command for this, PURGE EXTTRAIL, but it only works once nothing is using the trail anymore:

OGG (http://vmogg:7810 ogg_test_01) 3> purge exttrail PDB1/aa

Error: Cannot purge trail 'PDB1/aa', the trail is in use by EXTRACT 'EOGG375'

From the adminclient, you need to delete the extract first. Then, PURGE EXTTRAIL removes every sequence file and the trail resource:

OGG (http://vmogg:7810 ogg_test_01) 2> purge exttrail PDB1/aa
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000000'. Purge rule: Purging all files for trail 'PDB1/aa'.
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000001'. Purge rule: Purging all files for trail 'PDB1/aa'.
[...]
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000035'. Purge rule: Purging all files for trail 'PDB1/aa'.

So from an interactive session, PURGE EXTTRAIL is the easy way. But when automating, the REST API is often easier to handle, so let’s see how it should be done with it.

Deleting a trail

Calling the DELETE /services/{version}/trails/{trail} endpoint seems like a good call. Let’s try this first, on a trail still attached to a stopped (but not deleted) extract, using the delete_trail method of the oggrestapi Python package:

from oggrestapi import OGGRestAPI

client = OGGRestAPI(
    url="http://vmogg:7810",
    username="ogg",
    password="ogg"
)

client.delete_trail(trail="aa", path_query="PDB1")

RuntimeError: ERROR (code 400) - http://vmogg:7810/services/v2/trails/aa: Unable to delete trail resource 'PDB1/aa' because there are processes using it.

This is expected: a trail still referenced by a process cannot be deleted. Delete the extract, then retry:

RuntimeError: ERROR (code 500) - http://vmogg:7810/services/v2/trails/aa: There was a problem updating the Administration Service resources.

On a non-empty trail, once the process that was using it is gone, this call still fails with an OGG-30375 error (code 500) and a generic There was a problem updating the Administration Service resources.

To delete a trail with the GoldenGate REST API, you must first empty the trail sequence. Once the trail sequence is empty, the trail resource is automatically deleted. The method delete_trail_sequence_collection(), mapping DELETE /services/{version}/trails/{trail}/sequences, does this in one call: it takes a sequence range, first and last, as named keyword arguments:

result = client.delete_trail_sequence_collection(
    trail="aa",
    path="PDB1",
    first=0,
    last=999999999
)
[(m["code"], m["title"]) for m in result["messages"]]

[('OGG-30282', "Using actual highest sequence number '000000001' instead of last sequence number '999999999' specified in the request for trail 'PDB1/aa'."), ('OGG-30277', "Successfully deleted '2' of '2' trail sequences for trail 'PDB1/aa'."), ('OGG-30282', "Using actual highest sequence number '000000001' instead of last sequence number '999999999' specified in the request for trail 'PDB1/aa'."), ('OGG-30277', "Successfully deleted '2' of '2' trail sequences for trail 'PDB1/aa'.")]

An oversized value for last is a safe way to delete “everything”. Both first and last are required: omitting either one fails with an OGG-12104 error (no “from first to the end” shortcut).

Background operations of `PURGE EXTTRAIL`

PURGE EXTTRAIL from the adminclient does not call this endpoint. Tracing its requests through restapi.log shows it calling the generic command endpoint instead, POST /services/{version}/commands/execute, equivalent of the execute_command method, with a purge command:

data = {
    "name": "purge",
    "purgeType": "trails",
    "trails": [{"name": "aa", "path": "PDB1"}],
    "useCheckpoints": False,
    "keep": [{"type": "min", "units": "files", "value": 0}],
}

result = client.execute_command(data=data)
[(m["code"], m["title"]) for m in result["messages"]]

[('OGG-00957', "Purged old extract file 'PDB1/aa000000000'. Purge rule: Purging all files for trail 'PDB1/aa'."), ('OGG-00957', "Purged old extract file 'PDB1/aa000000001'. Purge rule: Purging all files for trail 'PDB1/aa'.")]

keep with value: 0 means “keep zero files”, or purge everything. It has the same end result as delete_trail_sequence_collection(), but with one OGG-00957 message per file instead of the range-clamp/success pair.

Whether it’s from the adminclient or with the REST API, the procedure to delete trail files is the same: make sure processes are deleted before deleting their trail files, and delete them one by one or with a purge command.

Post Views: 10