Depending on the location of your GoldenGate trail files, you might have to use the convchk utility to relocate them before migrating to the Microservices Architecture. Oracle has the following restrictions for using the migration utility:
Absolute path names for trail files. Classic trail file MUST reside in
./dirdat(or a subdirectory within it). If the trail file reside in another directory, they can be moved to./dirdatand then modify the checkpoint using theconvchkutility for the Extract. Then modify the parameter for any Replicat that is affected. See convchk in the Parameters and Functions Reference for Oracle GoldenGate for Oracle GoldenGate 21c.
But what exactly does that mean, and what should you do if you fall in the restriction described above ?
Which setups are supported, and which setups are not
Oracle clearly states that trail files directly located in dirdat or a subdirectory are supported. But what about other setups ?
- If your trail files are not directly in the same file system but under a link located in
./dirdat, then you will have no problem with the migration utility.
- If your trail files are located in a completely other location that doesn’t start with
./dirdat, you will receive the following error when migrating. If you fall under this case, see the chapter about using theconvchkutility.
ERROR: Error EXTRACT EXT_MB does not have trail files in the ./dirdat subdirectory of /u01/app/oracle/product/ogg19/ and cannot be migrated.
What should you pay attention to ?
Even if your trail files are correctly set with a path relative to dirdat, there is something you should note when using the migration utility. Oracle won’t just analyze and copy the trail files. The migration utility will also target all the content within the folders registered in your extracts.
If you have a trail file in ./dirdat/subfolder, make sure you only have trail files that you want to migrate. Other files inside subfolder will also be copied, delaying the migration or worse ! Same thing with links, which could lead to infinite references and make the migration crash.
Using the convchk utility
Using the failing migration example given above, I will try to correct settings for the extract EXT_MB, defined with EXTTRAIL /u02/ogg/mb, location outside of the supported dirdat directory. We will use convchk, a binary located within OGG_HOME in a Classic Architecture setup.
[oracle@vmogg ~]$ /u01/app/oracle/product/ogg19/convchk
Usage : convchk <checkpoint_group> <trail_name> (SEQLEN_9D | SEQLEN_6D) [-force]
Choosing ./dirdat/mb as the new trail name, here is a complete example on how to relocate trail files with convchk.
[oracle@vmogg ogg19]$ ./convchk ext_mb /u01/ogg/mb TRAILPATH ./dirdat/mb
***********************************************************************
Oracle GoldenGate Checkpoint Conversion Utility for Oracle
Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054
Linux, x64, 64bit (optimized) on Oct 17 2019 15:31:11
Copyright (C) 1995, 2019, Oracle and/or its affiliates. All rights reserved.
Starting at 2025-12-29 14:40:53
***********************************************************************
Operating System Version:
Linux
Version #2 SMP Sun Sep 21 08:53:14 PDT 2025, Release 5.15.0-312.187.5.3.el8uek.x86_64
Node: vmogg
Machine: x86_64
soft limit hard limit
Address Space Size : unlimited unlimited
Heap Size : unlimited unlimited
File Size : unlimited unlimited
CPU Time : unlimited unlimited
Process id: 18078
Checkpoint for Extract group EXT_MB has been backedup to /u01/app/oracle/product/ogg19/dirchk/EXT_MB.cpe.1767019253.bak.
Checkpoint output trail file path /u01/ogg/mb has been updated to a new trail file path ./dirdat/mb for the Extract group EXT_MB.
Checkpoint conversion successful for group EXT_MB, trail file /u01/ogg/mb.
Now, move all trail files to the new location, and edit the extract parameter file so that it points to the dirdat folder.
# Moving trail files
mv /u01/ogg/mb* /u01/app/oracle/product/ogg19/dirdat
# Editing parameter file
GGSCI > edit params ext_mb
GGSCI > view params ext_mb
...
EXTTRAIL ./dirdat/mb
...
And that’s it ! After restarting the extract, you can view the report to check the new location.
GGSCI > view report ext_mb
...
2025-12-29 14:44:06 INFO OGG-01026 Rolling over remote file ./dirdat/mb000000000.
2025-12-29 14:44:06 INFO OGG-01053 Recovery completed for target file ./dirdat/mb000000001, at RBA 1345.
The extract has been properly moved to a new location supported by the migration utility. You can now stop the extract and proceed with the migration as you would do with any other extract.