ORA-53035报错说映射文档的行没找到，远程修复怎么搞呢？

ORA-53035这个错误，根据甲骨文官方支持文档（ID 2908075.1）的解释，核心问题是出在Oracle GoldenGate的复制进程上，就是GoldenGate在目标数据库上，试图根据你源数据库传过来的数据变化（比如更新一条记录），去目标数据库里找到对应的那条记录来应用这个变化时，找不到了，它手里拿着一张“地图”（映射文档），按图索骥，结果发现那个位置是空的，于是就抛出了“映射文档的行没找不到”（Mapped document row not found）这个错误。

这个错误本身通常不是一个独立的故障点，它更像是一个“症状”，告诉你数据同步的链条在某个环节断掉了，远程修复的关键，就在于像侦探一样，顺着这个症状去找到根本原因，由于是远程操作，你无法直接接触到服务器硬件，所有操作都依赖于命令行工具、日志文件和数据库连接，以下是详细的排查和修复思路,完全基于远程可执行的方式。

第一步：立刻检查进程状态和详细报错日志

远程操作的第一件事就是确认现场，你需要登录到目标端的GoldenGate管理命令行（GGSCI），首先用INFO ALL命令看看所有的抽取（Extract）、投递（Data Pump）和复制（Replicat）进程是什么状态，那个报53035错误的复制进程，状态很可能是ABENDED（异常终止）。

找到这个进程后，最关键的一步是查看它的详细报告文件，命令是VIEW REPORT <进程名>，比如VIEW REPORT REP01，你要在这个报告里，不仅仅是找到ORA-53035这一行错误代码，更要紧的是看错误发生之前的日志，GoldenGate通常会记录下它当时正在尝试操作的那条SQL语句，把这句SQL语句完整地复制下来，它会告诉你它想在哪个表（TABLE）上，根据哪些条件（WHERE 子句）去找那条“丢失”的行,这是后续所有排查的基石。

第二步：基于SQL语句，在目标端数据库进行验证

你手上有了一条具体的SQL语句，打开目标数据库的SQL命令行（比如用SQL*Plus或SQL Developer连接上去），直接执行这条SQL语句，结果大概率是查询返回0行记录,这就证实了GoldenGate为什么报错。

你要开始找“为什么这条记录在目标端不见了”，原因可能有很多种,需要逐一排查：

1. 检查初始数据加载是否一致：这是最常见的原因之一，可能从一开始，源库和目标库的这张表的数据就不是完全同步的，你可以远程查询一下源库和目标库的这张表，对比一下数据量（SELECT COUNT(*) FROM 表名）是否大致相同，如果目标库明显少了很多数据，那很可能是在之前做全量数据初始化时就没有做完整,或者中途失败了。
2. 检查是否有绕过GoldenGate的直接操作：这是另一个极其常见的原因，有没有人在目标数据库上直接手动执行过DELETE或UPDATE语句，动了这张表的数据？或者，目标库上是否有其他的作业、触发器，在GoldenGate不知情的情况下修改或删除了数据？这种“后台”操作是GoldenGate同步失败的主要杀手,你需要询问团队或检查数据库作业记录来确认。
3. 检查复制进程的参数文件：远程查看复制进程的配置文件，命令是VIEW PARAMS <进程名>，重点检查MAP语句的配置，是不是设置了错误的过滤条件（WHERE子句），导致有些记录本来应该被复制过来但却被过滤掉了？或者MAP语句里用了COLMAP进行列映射，但映射规则写错了,导致依据错误的条件去目标表查找？
4. 检查主键或唯一约束：确保源表和目标表都有定义明确且一致的主键或唯一约束，GoldenGate在复制更新和删除操作时，严重依赖于主键来定位记录，如果目标表缺少主键，或者主键字段的值被意外修改,GoldenGate就会找不到记录。

第三步：根据找到的根本原因进行远程修复

找到原因后,修复方案就明确了：

• 如果是初始数据不一致：你需要重新初始化这张表的数据，远程操作的方法是：先在目标端停止复制进程，然后使用数据库工具（如Oracle的Data Pump）从源库导出这张表的数据，传输到目标端服务器，再导入到目标数据库，导入后，需要告知GoldenGate从这个数据一致的时间点开始重新同步，这就需要通过GGSCI命令ALTER REPLICAT <进程名> SKIP_TRANSACTION <开始SCN>来跳过已经处理过但可能出错的老数据，从一个新的起点开始，这个起点SCN需要根据数据导出的时间点来确定，操作比较精细,最好参考更详细的Oracle文档。
• 如果是人为误操作：修复起来相对简单，严格禁止任何直接在目标库对同步表的手动操作，对于已经丢失的少量数据，可以从源库查询出来，手动插入到目标库补全，补全后，同样可以使用SKIP_TRANSACTION命令让复制进程跳过报错的那个事务,继续后续的同步。
• 如果是参数配置错误：那就直接远程修改复制进程的参数文件（先用EDIT PARAMS <进程名>修改），修正错误的WHERE过滤条件或COLMAP列映射，修改保存后,重启复制进程即可。
• 处理完成与重启进程：无论采用哪种修复方法，在修复操作执行完毕后，都需要在GGSCI中重启复制进程，先使用START <进程名>启动进程，然后再用INFO <进程名>检查其状态是否变为RUNNING，并再次VIEW REPORT <进程名>查看最新的报告，确认53035错误不再出现,同步正常进行。

远程修复的特别注意事项

远程操作最大的风险是“看不见摸不着”，所以每一步都要格外谨慎，在对目标数据库执行任何修复性的SQL语句（如补插数据）之前，只要条件允许，最好先远程做一个表数据的备份（例如使用CREATE TABLE 表名_backup AS SELECT * FROM 表名），这样万一操作失误，还有回滚的余地，整个排查和修复过程，保持清晰的记录，这样如果问题复杂,也方便寻求更专业的支持。