ORA-26786报错，行键冲突列不匹配，表里数据问题远程帮你解决

ORA-26786这个错误，说白了，就是你在用Oracle数据库的某个高级复制或者数据同步功能（比如Oracle GoldenGate）时，系统在检查两边要同步的数据时，发现了一个根本性的矛盾，这个矛盾的核心在于“行键冲突列不匹配”，咱们别被这个词吓到，把它拆开揉碎了讲，其实就是“用来唯一识别一行数据的那些关键字段，在两边数据库的配置或者数据本身对不上号”。

想象一下这个场景：你有一个总公司数据库，还有一个分公司数据库，为了保证数据一致，你用工具让这两个数据库里的某张表保持实时同步，这张表里，我们假设用“员工ID”和“身份证号”这两个字段组合在一起，作为唯一标识一条员工记录的“钥匙”（这就是所谓的行键），同步工具就靠着这把“钥匙”来判断，哪条数据是新增的要去插入，哪条是已有的要去更新。

ORA-26786错误跳出来了，就像系统在对你大喊：“喂！出问题了！我拿着你给我的这把‘钥匙’（员工ID和身份证号），在目标数据库的表里，居然找不到唯一一条能对得上的记录！要么找不到，要么找到不止一条，这活我没法干了！”

为什么会出现这种“钥匙”失灵的情况呢？问题的根源通常不出在同步工具本身，而在于“表里数据问题”，根据实际经验，主要有以下几种可能，咱们一个一个说：

第一种可能，也是最常见的一种：两边表里的数据真的不一样了。 也就是来源内容里提到的“DATA INCONSISTENCY BETWEEN SOURCE AND TARGET”，总公司的数据库里，某个员工的记录，他的身份证号是正确无误的，但是呢，分公司的数据库里，可能因为之前某次手工录入错误，或者别的什么意外，同一个人对应的身份证号最后一位输错了，这样一来，当同步工具拿着总公司正确的“员工ID+正确身份证号”这把钥匙，去分公司数据库里找这条记录准备更新时，自然就找不到了，因为它只会去匹配“员工ID+错误身份证号”的记录，结果就是，系统认为源端有一条新数据需要插入，但这明明应该是更新操作，这种矛盾就会触发ORA-26786报错。

第二种可能，定义这把“钥匙”的规则本身出了问题。 也就是来源中提到的“MISMATCHED KEY COLUMNS”，虽然我们心里觉得是用“员工ID”和“身份证号”做行键，但有可能在配置同步进程的时候，不小心只在行键配置里勾选了“员工ID”，漏掉了“身份证号”，那么同步工具就会傻乎乎地只拿着“员工ID”这一把单钥匙去干活，如果在分公司数据库里，恰好有两个不同的员工，他们的“员工ID”值一样（虽然这本身也是个数据问题，但可能由于历史原因确实存在），那么工具用这把单钥匙一去匹配，一下就找到了两条记录，它立刻就懵了：“说好的一把钥匙开一把锁呢？怎么这里有两把锁看起来都能插进去？” 这种无法唯一确定目标行的情况，同样会引发ORA-26786。

第三种可能，比较隐蔽，是数据本身存在重复。 也就是“DUPLICATE DATA IN TARGET”，即使你行键配置得完全正确，比如就是“员工ID+身份证号”，但如果分公司目标表里，由于某种数据导入错误，不小心插入了两条完全一模一样的记录（即员工ID和身份证号都相同），这也会导致同步工具在用这把钥匙匹配时，一下子找到两条记录，无法决定到底该更新哪一条，于是只能报错。

知道了原因,怎么“远程帮你解决”呢？远程解决的核心思路，就是对比和修正，因为操作的人可能不在机房，需要通过命令和查询来定位问题。

解决的步骤通常是这样的：

要立刻从报错信息里找线索，ORA-26786的错误日志里通常会明确告诉你是在处理哪一张表时出的错，并且会显示出它当时使用的那个行键的具体值是多少，日志可能会记录：表名是EMPLOYEE_TABLE，冲突键值是 EMP_ID=1001, ID_CARD='110101199001011234'，这就是你调查的起点。

分别在源端数据库和目标端数据库执行查询，你需要在总公司的数据库（源端）里执行一个查询：SELECT * FROM EMPLOYEE_TABLE WHERE EMP_ID=1001 AND ID_CARD='110101199001011234'; 看看这条记录是否存在，以及它的其他字段内容是什么，立刻在分公司的数据库（目标端）里执行完全相同的查询语句，这时，你很可能就会发现问题的所在：

• 如果目标端查询结果是0条记录，那很可能就是第一种情况，数据不一致，可能是目标端这条记录的ID_CARD字段值不一样，你需要扩大查询范围，比如用SELECT * FROM EMPLOYEE_TABLE WHERE EMP_ID=1001; 看看目标端这个员工ID对应的身份证号到底是什么，从而确认差异。
• 如果目标端查询结果是2条或更多记录，那就是第三种情况，目标表存在重复数据。
• 如果目标端查询结果是1条,但你怀疑是不是行键定义有问题，那就需要去检查同步工具（如GoldenGate）的配置参数文件，找到针对这张表的配置，查看KEYCOLS这个参数的设置，确认它指定的列是否和你预期的一致（是否包含了所有必要的列）。

根据发现的问题进行修正：

• 如果是数据不一致（目标端数据错误或缺失），那么就需要手动在目标端修正这条数据，使其与源端一致，或者，在确保安全的前提下，可以尝试重新初始化同步。
• 如果是重复数据,就需要联系业务人员确认后，删除目标端的重复记录，只保留正确的一条。
• 如果是行键配置错误,那么需要停止同步进程，修改参数文件中的KEYCOLS定义，然后重启进程。

解决ORA-26786的过程，就像一个侦探破案，核心就是对比“钥匙”在源端和目标端的表现差异，找出不匹配的根源，然后对症下药进行修复，由于所有调查和修复工作都可以通过数据库命令行工具完成，因此完全具备远程操作的条件。