Oracle 19c跨用户Truncate表失败：已授权及同义词仍需指定schema

问题背景 #

从Oracle 11g升级到19c后，user1执行TRUNCATE TABLE user2.table_name可以成功，但直接使用已配置的私有/公共同义词TRUNCATE TABLE table_name却失败。已尝试重建同义词、撤销并重新授予ALTER权限，均未解决，而11g中无此问题。

排查与解决步骤 #

• 确认同义词有效性
  执行以下SQL检查私有同义词的指向是否正确：

  SELECT TABLE_OWNER, TABLE_NAME FROM ALL_SYNONYMS 
  WHERE SYNONYM_NAME = 'TABLE_NAME' AND OWNER = 'USER1';
  

  确保返回的TABLE_OWNER是USER2，TABLE_NAME匹配目标表，且同义词状态为VALID。若无效，重新创建：

  CREATE OR REPLACE SYNONYM user1.table_name FOR user2.table_name;
  

• 验证权限授予方式
  19c对DDL操作的权限验证更严格，角色授予的权限在DDL中可能不生效，必须直接授予ALTER TABLE权限：

  GRANT ALTER ON user2.table_name TO user1;
  

  执行以下SQL确认权限是直接授予而非通过角色：

  SELECT PRIVILEGE FROM USER_TAB_PRIVS 
  WHERE TABLE_NAME = 'TABLE_NAME' AND GRANTEE = 'USER1';
  

• 检查当前schema优先级
  19c中当前session的默认schema可能优先于同义词解析，尝试切换schema后再执行Truncate：

  ALTER SESSION SET CURRENT_SCHEMA = user2;
  TRUNCATE TABLE table_name;
  

  若成功，说明同义词解析被当前schema覆盖，可以考虑在执行Truncate时显式指定同义词所属schema：

  TRUNCATE TABLE user1.table_name;
  

• 排查对象名称大小写问题
  若表或同义词创建时使用了双引号区分大小写，执行Truncate时必须严格匹配大小写：

  TRUNCATE TABLE "table_name";
  

关键提示 #

19c在DDL操作的权限验证和对象解析逻辑上比11g更严格，即使配置了同义词，也可能因权限授予方式、同义词有效性或schema优先级导致失败。优先排查直接权限授予和同义词指向问题，这是最常见的原因。

内容的提问来源于stack exchange，提问作者vigneshwar reddy