能查但需注意权限、大小写和分段存储：USER_SOURCE仅显示当前用户对象，无OWNER列；关键词匹配须用UPPER()和LIKE，且考虑跨行截断；加密、TYPE非PROCEDURE或INVALID状态均影响结果。
能查，但必须注意视图权限、大小写处理和分段存储特性，否则容易漏结果或报错。
USER_SOURCE 只能查当前用户拥有的存储过程
它不显示其他用户创建的、哪怕你有执行权限的存储过程。如果目标过程属于 SCOTT 或 HR，而你登录的是 TEST 用户，USER_SOURCE 就完全看不到那些对象。
- 确认当前用户：执行
SELECT USER FROM DUAL;看实际登录身份 - 若需跨用户搜索，改用
ALL_SOURCE（需对方已授权）或DBA_SOURCE（需 DBA 权限） -
USER_SOURCE视图里没有OWNER列，所以查出来的NAME是裸名称，无法区分同名过程是否来自不同 schema
关键词匹配必须用 UPPER() + LIKE，且要容忍换行切分
USER_SOURCE 把每个存储过程按行拆成多条记录，每条 TEXT 字段最多 4000 字节，且自动截断——这意味着一个长语句或注释可能被切成两行，关键词恰好落在断点两侧时，单行 LIKE '%keyword%' 就会失效。
- 务必统一大小写：写成
UPPER(s.text) LIKE UPPER('%employee%')，避免因大小写不一致漏匹配 - 不要依赖单行完整语义：比如
'INSERT INTO EMPLOYEES'被拆成'INSERT INTO '和'EMPLOYEES'两行，单独查任一行都找不到 - 若关键词较短（如
'au'），记得排除干扰项：AND s.text NOT LIKE '%default%'这类否定条件要加在同一个WHERE子句里
查不到结果？先检查过程是否存在且未加密
如果确定过程存在但仍无返回，常见原因有三个：
- 过程已被
CREATE OR REPLACE PROCEDURE ... AUTHID DEFINER WRAPPED加密，USER_SOURCE中TEXT字段显示为乱码或空，此时无法文本搜索 -
TYPE值不是'PROCEDURE'，可能是'PACKAGE BODY'——某些逻辑实际写在包体里，得额外查AND s.type IN ('PROCEDURE', 'PACKAGE BODY') - 过程处于无效状态（
STATUS = 'INVALID'），但不影响源码存在性；可先查USER_OBJECTS确认：SELECT OBJECT_NAME, STATUS FROM USER_OBJECTS WHERE OBJECT_TYPE = 'PROCEDURE';
想定位关键词具体在哪一行？必须用 line 排序并保留上下文
只查出过程名不够，调试时往往需要看到关键词出现的上下文（比如变量声明附近、SQL 拼接位置）。这时不能只 SELECT DISTINCT s.name，得把行号和代码一起捞出来。
- 基础定位语句：
SELECT s.name, s.line, s.text FROM USER_SOURCE s WHERE UPPER(s.text) LIKE UPPER('%v_salary%') AND s.type = 'PROCEDURE' ORDER BY s.name, s.line; - 注意
line是从 1 开始的整数，但同一过程的多行不一定连续（比如中间插入空行或注释块） - 若关键词出现在动态 SQL 字符串中（如
v_sql := 'UPDATE EMP SET ...'），它只在字符串字面值里存在，不会触发对表的依赖关系，所以USER_DEPENDENCIES查不到——这时源码搜索是唯一手段
最易被忽略的一点：USER_SOURCE 不包含编译错误提示，也不反映运行时行为。即使搜到了关键词，也得人工确认它是真实逻辑的一部分，还是残留注释、测试代码或被注释掉的旧逻辑。
