这确实是异构数据库复制场景里的常见痛点——依赖主键冲突来分支执行不仅效率拉胯（每次有已存在记录都会触发一次数据库错误），还容易引发重复操作的问题。我来分享几个靠谱的解决方案：

1. 用SQL Server的MERGE语句替换INSERT+UPDATE组合 #

这是最直接高效的方案，MERGE语句可以在单次执行中完成「判断存在性-执行对应操作」的逻辑，完全避免依赖主键冲突错误来分支。

你可以把原来的两条语句替换成下面的MERGE语句：

MERGE INTO YourTargetTable t
USING (SELECT :oracle_pk AS TargetId, :col_val1 AS Column1, :col_val2 AS Column2 FROM DUAL) s
ON (t.TargetId = s.TargetId)
WHEN MATCHED THEN
    UPDATE SET t.Column1 = s.Column1, t.Column2 = s.Column2
WHEN NOT MATCHED THEN
    INSERT (TargetId, Column1, Column2) VALUES (s.TargetId, s.Column1, s.Column2);

• 这个语句会先根据主键匹配目标表的记录
• 匹配到就执行UPDATE，没匹配到就执行INSERT
• 全程不需要依赖错误捕获，既提升了性能，也从根源上避免了重复操作带来的冲突问题

2. 调整JCC逻辑，提前判断目标库记录存在性 #

如果暂时无法修改语句生成逻辑，你可以在JCC的复制流程中加一步：先查询SQL Server是否存在对应主键的记录，再针对性发送INSERT或UPDATE语句。

伪代码示例：

// 假设这是JCC中处理单条变更的逻辑片段
String pkValue = getOracleChangePk();
String col1Value = getOracleChangeCol1();
String col2Value = getOracleChangeCol2();

// 先查询目标库是否存在记录
PreparedStatement checkStmt = sqlServerConn.prepareStatement("SELECT 1 FROM YourTargetTable WHERE TargetId = ?");
checkStmt.setString(1, pkValue);
ResultSet rs = checkStmt.executeQuery();
boolean recordExists = rs.next();
rs.close();
checkStmt.close();

// 根据结果发送对应语句
if (recordExists) {
    PreparedStatement updateStmt = sqlServerConn.prepareStatement("UPDATE YourTargetTable SET Column1 = ?, Column2 = ? WHERE TargetId = ?");
    updateStmt.setString(1, col1Value);
    updateStmt.setString(2, col2Value);
    updateStmt.setString(3, pkValue);
    updateStmt.executeUpdate();
    updateStmt.close();
} else {
    PreparedStatement insertStmt = sqlServerConn.prepareStatement("INSERT INTO YourTargetTable (TargetId, Column1, Column2) VALUES (?, ?, ?)");
    insertStmt.setString(1, pkValue);
    insertStmt.setString(2, col1Value);
    insertStmt.setString(3, col2Value);
    insertStmt.executeUpdate();
    insertStmt.close();
}

⚠️ 注意：这种方式在高并发场景下可能存在竞态条件（查询后到插入/更新前，其他进程可能修改了记录），建议结合事务隔离级别（比如REPEATABLE READ）或行锁来保证一致性。

3. 检查JCC的事务日志处理标记机制 #

重复执行操作也可能是因为JCC没有正确标记已处理的Oracle事务日志，导致同一条变更被重复读取和发送。你可以检查JCC的配置：

• 是否开启了事务日志的处理状态持久化
• 每次处理完变更后，是否正确更新了日志的处理进度标记
• 有没有因为异常导致处理状态回滚，引发重复消费

4. 优化错误处理逻辑（临时过渡方案） #

如果以上方案都暂时无法落地，你可以优化现有INSERT+UPDATE的错误处理逻辑：

• 确保只捕获主键冲突的特定错误码（SQL Server中主键冲突的错误码是2627），避免其他错误被误判为「记录存在」
• 在执行UPDATE前，确认INSERT确实是因为主键冲突失败，而不是其他错误

示例代码片段（错误处理部分）：

try {
    // 执行INSERT语句
    insertStmt.executeUpdate();
} catch (SQLServerException e) {
    // 只处理主键冲突错误
    if (e.getErrorCode() == 2627) {
        // 执行UPDATE语句
        updateStmt.executeUpdate();
    } else {
        // 抛出其他错误
        throw e;
    }
}

这种方式只能临时缓解问题，还是推荐用MERGE从根源解决。

内容的提问来源于stack exchange，提问作者Dmitrij Kultasev