远程UPDATE必须显式COMMIT，否则事务卡住：Oracle通过DBLINK执行DML后不自动提交，需立即COMMIT触发两阶段提交，否则数据不落盘、锁不释放，并可能进入in-doubt状态。
远程UPDATE必须显式COMMIT，否则事务卡住
Oracle通过DBLINK执行UPDATE、INSERT或DELETE后，**不会自动提交**，哪怕只操作远程表。本地会话看似成功，但远程数据实际未落盘，且可能阻塞其他会话——这是最常被忽略的硬性规则。
- 错误现象：
UPDATE remote_table@mylink SET status='DONE' WHERE id=1001执行后查不到变化；用SELECT * FROM remote_table@mylink WHERE id=1001仍显示旧值 - 根本原因：Oracle将该语句纳入当前会话的分布式事务上下文，等待
COMMIT触发两阶段提交（2PC） - 必须紧跟
COMMIT，不能依赖应用层自动提交（如JDBC默认auto-commit对DBLINK无效） - 若忘记
COMMIT又断开连接，事务会进入in-doubt状态，残留记录在DBA_2PC_PENDING视图中
UPDATE语句里@符号位置不能错，且不能混用本地/远程表别名
@必须紧贴在**表名或同义词名之后**，不能加在别名上。别名本身不携带数据库上下文，Oracle无法推断其指向哪个实例。
- ✅ 正确写法：
UPDATE orders@prod_link o SET o.status = 'SHIPPED' WHERE o.id = 123 - ❌ 错误写法：
UPDATE orders o@prod_link SET o.status = 'SHIPPED'...（语法报错ORA-00933） - ❌ 错误写法：
UPDATE local_orders l JOIN remote_customers@cust_link c ON l.cust_id = c.id SET l.synced = 1（跨库JOIN在UPDATE中不支持，会报ORA-02021） - 如果要关联更新，必须用子查询或MERGE，例如：
MERGE INTO local_target t USING (SELECT id, name FROM customer@cust_link) s ON (t.cust_id = s.id) WHEN MATCHED THEN UPDATE SET t.cust_name = s.name
分布式事务失败时，优先查DBA_2PC_PENDING和alert日志
当COMMIT卡住、报ORA-02054或ORA-01591时，说明某个参与节点失联或2PC协调失败。此时不能反复重试，应立即定位悬疑事务。
- 查悬疑事务：
SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, FAIL_TIME FROM DBA_2PC_PENDING - 查关联节点：
SELECT * FROM DBA_2PC_NEIGHBORS WHERE LOCAL_TRAN_ID = '10.20.360'（用报错里的ID替换） - 检查
alert.log，搜索RECO或in-doubt关键词，确认Reco进程是否尝试修复过 - 手工强制提交/回滚前，务必确认远程库已恢复可连通，否则
COMMIT FORCE 'xxx'会失败并留下更难清理的状态
性能与锁风险：远程UPDATE会持锁直到COMMIT，且网络延迟直接放大
远程表上的行锁、表锁不会在语句结束就释放，而是持续到整个分布式事务COMMIT完成。网络RTT、远程库负载、甚至防火墙超时都会拖长锁持有时间。
- 一次
UPDATE ... @link+COMMIT的实际耗时 ≈ 本地解析 + 网络往返 × 2（prepare + commit）+ 远程执行 + 网络往返 × 1（ack），比本地UPDATE慢数倍 - 避免在高并发场景下对远程热点行频繁UPDATE；考虑改用批量同步（如物化视图刷新）或异步消息
- 不要在PL/SQL循环里逐条
UPDATE @link，应改用MERGE或临时表+批量DML - 测试阶段务必用
tnsping和sqlplus user@remote_db验证链路稳定性，而非仅依赖SELECT * FROM DUAL@link
分布式事务的复杂性不在语法，而在它把本地事务的边界扩展到了网络另一端——只要有一处不可达、一个COMMIT没发出去、一次网络抖动，就可能让事务停在半路。真正难处理的从来不是怎么写，而是怎么收尾。
