SYS_CONTEXT是Oracle唯一用于读取USERENV命名空间的函数，USERENV仅为预定义命名空间而非函数；必须使用SYS_CONTEXT('USERENV','PARAMETER')格式调用，漏写命名空间或误用USERENV()均报错。
直接用 sys_context 函数查，但必须写对参数格式——sys_context('userenv', 'sessionid') 这样才有效；写成 userenv('sessionid') 会报 ora-00904: "userenv": invalid identifier，这是最常卡住的地方。
为什么 USERENV 不是函数，而 SYS_CONTEXT 才是
USERENV 是一个命名空间（namespace），不是函数名，也不是视图或包。Oracle 只提供 SYS_CONTEXT 这一个入口来读取它。所有 USERENV 下的属性，比如 'CURRENT_SCHEMA'、'IP_ADDRESS'、'ISDBA'，都必须作为第二个参数传给 SYS_CONTEXT。
常见错误现象：
- 执行
SELECT USERENV('SESSION_USER') FROM DUAL→ 报ORA-00904 - 漏写第一个参数，只写
SYS_CONTEXT('SESSION_USER')→ 报ORA-00938: not enough arguments - 把命名空间写成小写
'userenv'→ 大多数版本能自动转大写，但某些严格兼容模式下会失败
SYS_CONTEXT('USERENV', ...) 常用属性对照与注意事项
返回值全是 VARCHAR2，默认最长 256 字节，超长会被截断。必要时加第三个参数指定长度，比如 SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER', 128)。
关键属性差异说明：
-
'SESSIONID'返回的是AUDSID，不是V$SESSION.SID；前者全局唯一、实例重启不重置，后者仅当前实例内有效 -
'CURRENT_SCHEMA'可被ALTER SESSION SET CURRENT_SCHEMA = xxx动态修改，而'SESSION_USER'始终是登录用户名，不可变 -
'IP_ADDRESS'在数据库服务器直连（如 sqlplus 本地连接）时可能为空；经监听器或中间件转发后才稳定可读 -
'MODULE'和'ACTION'需要应用层主动调用DBMS_APPLICATION_INFO.SET_MODULE才有值，否则为 NULL
自定义命名空间怎么设、怎么查
如果想传业务上下文（比如租户 ID、请求 trace_id），不能往 USERENV 里塞——它只读。得先建自定义命名空间，再用 DBMS_SESSION.SET_CONTEXT 写入。
实操步骤：
- 创建上下文：
CREATE CONTEXT my_ctx USING my_pkg - 编写包体
my_pkg，在过程里调用DBMS_SESSION.SET_CONTEXT('my_ctx', 'tenant_id', 't1001') - 设置后即可查：
SELECT SYS_CONTEXT('my_ctx', 'tenant_id') FROM DUAL
注意：自定义命名空间必须由 DBA 授权访问，且 SYS_CONTEXT 查询不到未设置过的 key，返回 NULL 而非报错。
别指望 SYS_CONTEXT 返回执行计划或锁信息
它只负责“会话元数据”，不是诊断视图代理。想看 SQL 执行状态、绑定变量、行锁持有者？必须联查 V$SESSION、V$SQL、V$LOCK 等动态性能视图。比如要定位当前会话正在跑哪条 SQL，得这样写：
SELECT s.sid, s.sql_id, q.sql_text
FROM v$session s, v$sql q
WHERE s.sid = SYS_CONTEXT('USERENV', 'SID') -- ❌ 错！SID 是数字，但 SYS_CONTEXT 返回字符串
AND s.sql_id = q.sql_id;
上面写法会失败，因为 SYS_CONTEXT('USERENV', 'SID') 实际返回的是字符串型 AUDSID，而 V$SESSION.SID 是 NUMBER。真正该用的是 sys_context('USERENV','SESSIONID') 对应 V$SESSION.AUDSID 字段。
这个类型错位和命名混淆，是排查慢会话时最容易忽略的一环。
