sys_context('userenv', 'sessionid')返回audsid而非v$session.sid，二者类型相同但作用域不同：audsid全局唯一且重启不重置，sid仅实例内有效；userenv不是函数，必须通过sys_context调用。
oracle 里 sys_context 函数是读取会话级上下文的唯一可靠方式，userenv 是它的一个预定义命名空间，不是独立函数或视图。
为什么不能直接 SELECT USERENV('SESSIONID')？
因为 USERENV 不是函数名，也不是表名——它是 sys_context 的第一个参数。写成 SELECT USERENV('SESSIONID') FROM DUAL 会报错 ORA-00904: "USERENV": invalid identifier，这是新手最常卡住的地方。
正确姿势只有这一种：sys_context 必须带两个参数：命名空间（'USERENV'）和属性名（'SESSIONID'）。
-
sys_context('USERENV', 'SESSIONID')返回当前会话的数字 ID（注意：不是V$SESSION.SID，而是V$SESSION.AUDSID） -
sys_context('USERENV', 'SESSION_USER')返回登录用户名（非当前ALTER SESSION SET CURRENT_SCHEMA切换后的） -
sys_context('USERENV', 'CURRENT_SCHEMA')才是当前默认 schema 名 - 所有属性名必须大写，小写会返回
NULL（比如'sessionid'→NULL）
哪些 USERENV 属性在 PL/SQL 和 SQL 中行为不一致？
多数属性在 SQL 和 PL/SQL 里表现一致，但有三个关键例外：
-
'CLIENT_IDENTIFIER'：SQL 查询中始终返回设置值；但在 PL/SQL 过程内，若过程被AUTHID DEFINER定义且调用者未显式设置，可能返回空（需检查DBMS_SESSION.SET_IDENTIFIER是否被调用） -
'IP_ADDRESS'：SQL 中能正常返回客户端 IP；但在某些连接池（如 UCP）或代理后，可能为空或为代理地址——别依赖它做安全校验 -
'OS_USER'：在 Windows 上通常可读，在 Linux 上取决于 Oracle 进程启动方式，RAC 环境下可能返回 CRS 进程用户而非真实终端用户
简单验证方法：SELECT sys_context('USERENV', 'SESSIONID'), sys_context('USERENV', 'IP_ADDRESS') FROM DUAL;，对比 V$SESSION 中对应字段是否匹配。
SESSIONID 和 SID 到底是不是一回事？
不是。这是 DBA 和开发最容易混淆的点：
-
sys_context('USERENV', 'SESSIONID')返回的是AUDSID（审计会话 ID），类型为NUMBER，全局唯一，重启实例不重置 -
V$SESSION.SID是实例内会话序号，类型也是NUMBER，但只在当前实例生命周期内有效，重启后从 1 开始重排 - 二者数值通常不同，不能互换使用。例如审计日志里记录的是
AUDSID，而杀会话要用ALTER SYSTEM KILL SESSION 'sid,serial#'，这里的sid是V$SESSION.SID - 查关联：可通过
V$SESSION.AUDSID = sys_context('USERENV', 'SESSIONID')精准定位当前会话行
真正麻烦的是：有些老文档把 AUDSID 叫作 “session id”，又把 SID 叫作 “session id”，结果代码里混用导致逻辑错乱。只要记住——sys_context 给你的永远是 AUDSID，别的都得自己去 V$ 视图里查。
