ORA-01031本质是DBLINK执行时远程用户缺表级DML权限，须在远程库显式授予INSERT/UPDATE/DELETE等具体权限，且必须手动COMMIT，不可依赖角色或本地授权。
ORA-01031 报错本质是远程用户权限不足
不是本地用户缺权限，而是 DBLINK 执行时用的是远程库里的那个账号（CONNECT TO 指定的用户），它必须对目标表有明确的 DML 权限。只给 SELECT 或 CONNECT 角色完全不够——哪怕远程用户是 DBA，只要没被显式授予 UPDATE、INSERT 等权限，写操作就会失败。
常见错误包括：
- 在本地执行
GRANT UPDATE ON remote_table TO local_user：无效，远程库根本不认这个授权 - 远程用户只被授予
SELECT ANY TABLE：该权限不包含写能力，仍会报ORA-01031 - 误以为
RESOURCE角色含写权限：它只含建表/序列等对象权限，不含跨库 DML 授权
远程端必须显式授予表级 DML 权限
权限必须在远程数据库上，以远程用户身份执行，且粒度精确到具体表：
GRANT INSERT, UPDATE, DELETE ON schema.table_name TO remote_user;- 若需批量操作多个表，逐个授权；不要依赖角色继承，DBLINK 不走角色权限链
- 使用公共 DBLINK 时，远程用户需具备
SELECT ANY TABLE+UPDATE ANY TABLE等对应 ANY 权限，但生产环境应避免，风险太高 - 密码含特殊字符（如
E0oOv0s#i$I1Ld）时，重建语句中IDENTIFIED BY后必须加双引号：IDENTIFIED BY "E0oOv0s#i$I1Ld"，否则解析失败直接卡在连接阶段
事务提交必须手动控制，且涉及 XA 协议
通过 DBLINK 执行 INSERT/UPDATE/DELETE 时，Oracle 自动启用分布式事务（XA），本地和远程两边都参与两阶段提交：
- 不能依赖
AUTOCOMMIT=TRUE：DBLINK 写操作会强制将当前 session 的AUTOCOMMIT设为FALSE，直到你显式COMMIT或ROLLBACK - 必须成对使用：
INSERT INTO remote_table@dblink ...→COMMIT；漏掉COMMIT会导致远程数据长期锁住，甚至触发 XA 超时回滚 - 如果远程库是 OceanBase Oracle 模式，还要求版本 ≥ V4.1.0，且集群节点需安装 OCI-12.2 驱动
网络与监听配置不当也会导致“看似权限问题”的假象
有些 ORA-01031 实际是连接根本没建立成功，只是错误码被掩盖了：
- 远程监听器
listener.ora中HOST仍是localhost或127.0.0.1：远程库收不到连接请求，DBLINK 尝试超时后可能返回模糊权限错误 - 远程
sqlnet.ora开启了tcp.validnode_checking = YES但未把本地 DB 服务器 IP 加入tcp.invited_nodes：连接被静默拒绝，表现类似认证失败 - 操作系统防火墙未放行 1521 端口（或远程库实际监听非默认端口）：TCP 连接不通，后续权限校验根本不会触发
GRANT 到那张表的 INSERT，以及你的 COMMIT 是不是真发到了远端。 
