不能在存储过程中直接使用DBMS_SESSION.SET_CURRENT_SCHEMA，因其属会话级操作且被Oracle禁止在PL/SQL单元内执行；应改用AUTHID CURRENT_USER配合显式schema前缀或经DBMS_ASSERT校验的动态SQL。
DBMS_SESSION.SET_CURRENT_SCHEMA 能不能在存储过程中用
不能直接用。DBMS_SESSION.SET_CURRENT_SCHEMA 是一个会话级变更，但 Oracle 明确禁止在存储过程、函数、触发器等 PL/SQL 单元内部执行该过程——调用会立即报错 ORA-01031: insufficient privileges 或 ORA-06550 / PLS-00201，即使你有 ALTER SESSION 权限也不行。
根本原因在于：PL/SQL 执行时处于定义者权限（definer’s rights）上下文，而 SET CURRENT_SCHEMA 属于会话控制类操作，必须由调用者（caller）显式发起，不能被封装进可重用的 PL/SQL 逻辑中。
替代方案：用 AUTHID CURRENT_USER + 显式 schema 前缀
真正可行的做法是绕过“切换”这个动作，改用权限和命名方式适配多 schema 场景：
- 把存储过程声明为
AUTHID CURRENT_USER（即调用者权限），这样过程内所有未加 schema 前缀的对象引用，会自动解析为调用者的默认 schema - 对跨 schema 访问的对象，始终使用
schema_name.object_name显式写法，比如scott.emp、hr.departments - 确保调用用户对目标 schema 下对象有对应权限（
SELECT、EXECUTE等），而不是依赖 current_schema 隐式授权
如果真需要动态 schema 绑定，只能靠绑定变量 + 动态 SQL
当 schema 名在运行时才确定（比如参数传入），且必须避免硬编码前缀，唯一出路是动态 SQL：
- 用
EXECUTE IMMEDIATE拼接完整语句，例如：'SELECT * FROM ' || p_schema || '.employees WHERE dept_id = :1' - 注意：这要求调用用户对
p_schema下所有涉及对象都有直接权限，不能靠 role 授予（role 在动态 SQL 中不生效） - 必须校验
p_schema输入，防止 SQL 注入；建议用DBMS_ASSERT.SQL_OBJECT_NAME过滤 - 性能上不如静态 SQL，且无法被共享池有效复用执行计划
容易被忽略的关键点
很多人卡在“为什么我给了 ALTER SESSION 权限还是不行”，其实问题不在权限，而在 Oracle 的 PL/SQL 安全模型本身：它把会话控制权牢牢保留在客户端层。哪怕你在 SQL*Plus 里先 ALTER SESSION SET CURRENT_SCHEMA=HR，再调用一个访问 employees 的存储过程，过程内部仍按定义者 schema 解析（除非它是 AUTHID CURRENT_USER）。这种行为不是 bug，是设计使然——避免嵌套调用导致会话状态不可控。
