故障描述用户反馈，ogg未实时同步至目标，检查发现是应用进程abended，具体报错如下：
分析排查ogg日志提示很明确，存在损坏的记录使用logdump进一步查看该trail文件损坏程度，如下：
继续查看，发现全是图示损坏的记录
（参考官方文档：
How to Recover from an OGG-01028 Incompatible Record If the Trail Is Not Corrupt (文档
ID 1507462.1)
）
到这里基本已经可以判断出
4835这个
trail文件已经损坏，如果需要继续应用的话就要跳到下一个
trail文件，但是这样做会导致数据的丢失，造成不一致，最终可能需要重新初始化或者重新同步涉及到数据丢失的表。
解决思路
目标端trail文件损坏，多半是在传输过程中造成的，那么生产是否还有 trail 文件存在，如果有是否可以将生产的 trail 文件重新传输一份 。
检查生产端保留的 trail 文件，发现生产端还保留有文件，则打算将生产的 trail 重新传输 。
记录应用进程当前检查点（ 2019-05-07 17:10:44.596007 ）
那么我们将 trail 文件提前一点开始传输，如从 4831 开始传输 ， 目标端应用进程先不做变动，重启下 mgr进程，将现有的 trail文件重命名掉
生产端停止传输进程，指定传输进程到 4831 ， rba 为 0 ，开始传输，报错如下：
OGG-01496 Oracle GoldenGate Capture for Oracle, sx_dmp.prm: Failed to open target trail file ./dirdat/tz004835, at RBA 1370.
因为目标端现在文件都已经重命名，所以这边传输过去的时候找不到原来的点续传
决定删除传输进程，重建传输进程后，指定到刚才的文件开始传输
重建传输进程后，在目标端看到的 trail 文件重新从 0 开始计算
目标端已经接收到新的 trail 文件，但是当前应用进程的记录还是在 4835 这个文件，直接启动应用进程将报错，找不到 4835 文件 ，如下：
所以，需要将应用进程指定到新传过来的第一个 trail 文件，并按照时间启动应用进程
alter tzrep extseqno 0 extrba 0 alter replicat tzrep begin 2019-05-07 17:10:44.596007
启动进程后，可以正常应用 。本次目标端文件损坏，因为源端还保留有trail文件且是完好的，所以可以使用源端文件重新传输并应用的方式，避免数据丢失。
