能做，但必须绕开 ora-04091 和事务一致性陷阱：ora-04091 因触发器中 select 远程表被 oracle 视为“表正在变异”而报错；pragma autonomous_transaction 会导致远程操作脱离主事务；唯一可靠方案是 after 触发器中用 merge 替代先查后判，并确保远程表有主键或唯一约束。
能做，但必须绕开 ORA-04091 和事务一致性陷阱，否则一写就挂。
DB Link 触发器里为什么总报 ORA-04091？
触发器在本地事务中尝试读取远程表（比如 SELECT COUNT(*) FROM t@mylink），Oracle 会检测到“正在修改的表又被自己查”，直接抛 ORA-04091: table is mutating。这不是配置问题，是 Oracle 的事务隔离硬限制。
- 加
PRAGMA AUTONOMOUS_TRANSACTION看似能解决，但会导致远程操作脱离主事务：本地插入成功、远程失败，你收不到错误，数据就丢了 - 用
BEFORE触发器也无效——它照样要读本地行（:old/:new是可用的，但查远程表仍触发 mutating 检查） - 真正可行的路径只有：把远程 DML 放在
AFTER触发器里，且避免任何SELECT远程表的操作
同步逻辑必须放弃“先查再判”模式
你不能写 IF (SELECT COUNT(*) FROM t@link WHERE id = :new.id) > 0 THEN UPDATE ... ELSE INSERT ... ——这句在 AFTER 里也报错，因为 SELECT 远程表仍被禁止（部分版本允许，但极不稳定，不推荐）。
- 正确做法是：用
MERGE语句，一条 SQL 完成“存在即更新、不存在即插入” - 要求远程表有主键或唯一约束，否则
MERGE可能报错或行为异常 - 示例：
MERGE INTO remote_table@mylink t USING (SELECT :new.id id, :new.name name FROM DUAL) s ON (t.id = s.id) WHEN MATCHED THEN UPDATE SET t.name = s.name WHEN NOT MATCHED THEN INSERT (id, name) VALUES (s.id, s.name) - 删除操作直接
DELETE FROM remote_table@mylink WHERE id = :old.id，无需先查
权限和网络配置最容易漏掉的三件事
建好触发器却始终不生效，90% 是卡在这三处，不是代码问题。
-
CREATE DATABASE LINK用户必须有CREATE DATABASE LINK权限，且远程用户（CONNECT TO xxx那个）必须被授予对目标表的INSERT/UPDATE/DELETE权限，仅SELECT不够 -
tnsnames.ora必须放在运行触发器的数据库服务器上（不是开发机），且监听端口、SERVICE_NAME（不是SID）必须与远程库实际配置完全一致；用tnsping MYLINK能通 ≠ SQL 能连，还得sqlplus user/pass@MYLINK实测 - 防火墙必须双向放开：源库服务器 → 目标库服务器的 1521（或自定义端口），且目标库监听器
sqlnet.ora中不能设tcp.validnode_checking = yes且没加源 IP 到白名单
别忽略自治事务的副作用和替代方案
如果业务真需要“先查远程状态再决定动作”（比如同步前校验远程记录是否已被人工修改），PRAGMA AUTONOMOUS_TRANSACTION 是唯一选择，但必须配套容错机制。
- 在自治事务块内执行
SELECT+INSERT/UPDATE后，立刻COMMIT；但主事务回滚时，这部分已提交的远程变更不会回滚 - 必须在触发器里加日志表（本地），记录每次远程操作的
:new.id、操作类型、时间、是否成功，否则出问题根本无法追溯 - 更稳的替代方案是弃用触发器，改用
DBMS_SCHEDULER每 5–30 秒轮询本地表WHERE sync_flag = 'N'，处理完再更新标志位——牺牲毫秒级实时性，换来事务可控性
跨库同步最麻烦的从来不是写法，而是“远程操作不可回滚”这个事实。哪怕 MERGE 写得再漂亮，远程库挂了、网络断了、权限突然被 revoke，你的触发器都只会静默失败。上线前务必在测试环境模拟这些故障，看日志有没有捕获、告警有没有触发。
