PL/SQL跨Schema禁用触发器报ORA-01031权限不足如何授权

所有授权操作必须使用拥有DBA权限的账号（如SYS、SYSTEM）执行，按照权限最小化原则，优先选择以下两种方案之一，禁止直接授予过高的全局权限。

方案1：仅授予单个触发器操作权限（生产环境首选） #

该方案仅开放目标触发器的操作权限，不会影响SchemaA下其他对象，安全级别最高。
用DBA账号执行如下授权语句：

GRANT ALTER ON SchemaA.TDA_K$TriggerA TO SchemaB;

授权完成后，SchemaB下的PL/SQL代码即可正常执行触发器禁用命令：

-- 禁用触发器
EXECUTE IMMEDIATE 'ALTER TRIGGER SchemaA.TDA_K$TriggerA DISABLE';
-- 执行删除逻辑完成后，必须重新启用触发器
EXECUTE IMMEDIATE 'ALTER TRIGGER SchemaA.TDA_K$TriggerA ENABLE';

方案2：授予触发器关联表的ALTER权限 #

如果后续SchemaB需要对该触发器所属的目标表（假设表名为SchemaA.Target_Table）上的所有触发器做启停、修改操作，可以直接授予表级ALTER权限，无需逐个给触发器授权。
用DBA账号执行如下授权语句：

GRANT ALTER ON SchemaA.Target_Table TO SchemaB;

该权限开放后，SchemaB可以对这张表执行ALTER类操作，包括启停表上所有触发器、修改表结构等，权限范围大于方案1，按需选择即可。

避坑注意事项 #

• 禁止随意授予ALTER ANY TRIGGER系统权限：该权限允许账号操作数据库内所有Schema下的任意触发器，权限覆盖范围过大，老旧项目权限管控通常不严格，授予该权限极易出现误操作影响其他业务线逻辑，无明确全局操作需求时绝对不要使用。
• 必须增加异常兜底逻辑：跨Schema修改触发器+删数据的操作要做异常捕获，哪怕删除步骤报错，也要保证触发器能被恢复启用，避免触发器长期禁用导致业务数据逻辑错误，参考写法如下：

BEGIN
  -- 禁用目标触发器
  EXECUTE IMMEDIATE 'ALTER TRIGGER SchemaA.TDA_K$TriggerA DISABLE';
  BEGIN
    -- 执行目标数据删除逻辑
    DELETE FROM SchemaA.Target_Table WHERE 你的删除过滤条件;
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN
      ROLLBACK;
      -- 异常回滚后先恢复触发器状态，再抛出错误
      EXECUTE IMMEDIATEATE 'ALTER TRIGGER SchemaA.TDA_K$TriggerA ENABLE';
      RAISE;
  END;
  -- 正常流程执行完恢复触发器状态
  EXECUTE IMMEDIATE 'ALTER TRIGGER SchemaA.TDA_K$TriggerA ENABLE';
END;
/

• 动态SQL中涉及的Schema名、对象名尽量写死，不要拼接外部传入的动态参数，避免SQL注入风险。

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