先讲一个高频场景：在Oracle里执行 GRANT SELECT ON seq_a TO user_b，结果却返回ORA-00942错误。很多人的第一反应是“语法写错了？”，但排除了语法问题仍然不对。问题其实卡在更基础的地方——当前用户根本看不到那个 sequence。
ORA-00942报错，原因其实很清楚：要么是 sequence 根本不存在，要么是当前用户没有权限去访问它。要理解这一点，得先搞清楚一个关键点：Oracle 里的 sequence 和表一样，属于“对象级”资源，受 owner 严格管控。你 user_b 想访问 schema_a.seq_a，除非 owner 明确给你授权，而且你在引用时必须带上 schema 前缀，写成 schema_a.seq_a。否则 Oracle 默认在当前用户自己的 schema 里搜索，搜不到当然报错。
实际工作中，经常遇到这样一种误操作：DBA 或者 schema_a 的 owner 确实执行了授权，但 user_b 查询时还是报错。原因十有八九是没写 schema 前缀——只用 seq_a.NEXTVAL 去查询，Oracle 只会去 user_b 自己的 schema 里查找，自然找不到。正确的写法应该是 SELECT schema_a.seq_a.NEXTVAL FROM DUAL。
排查时，可以按这几步进行：
- 先确认 sequence 存在且状态正常：
SELECT * FROM all_sequences WHERE sequence_owner = 'SCHEMA_A' AND sequence_name = 'SEQ_A'，status 字段必须是 VALID。 - 检查
user_b是否至少拥有CREATE SESSION权限——连数据库都连接不上，讨论授权就没有意义了。 - 授权语句必须由
schema_a（即 sequence 的 owner）或者 DBA 来执行，普通用户没有权限代劳。
GRANT SELECT ON sequence_name 报 ORA-00942？先确认对象是否存在且权限路径完整
这个场景在前面已经拆解过了。简单来说，直接执行 grant select on seq_a to user_b 报 ORA-00942，大概率不是语法问题，而是当前用户没有权限看到那个 sequence。记住，Oracle 的 sequence 是对象级资源，受 owner 控制；user_b 无法访问 schema_a.seq_a，除非被明确授权，且必须使用全限定名引用。
常见误操作是：DBA 或 schema_a 执行了授权，但 user_b 仍然查询不到——原因往往是没写 schema 前缀：SELECT schema_a.seq_a.NEXTVAL FROM DUAL 才是正确的；只写 seq_a.NEXTVAL 会触发在当前 schema 中搜索，自然找不到。
SELECT * FROM all_sequences WHERE sequence_owner = 'SCHEMA_A' AND sequence_name = 'SEQ_A'确认 sequence 存在且状态正常（status 为 VALID）- 检查
user_b是否已有CREATE SESSION权限，否则连连接都会失败 - 授权语句必须由
schema_a（owner）或 DBA 执行，普通用户不能代授
如何批量授予某 Schema 下所有 Sequence 的 SELECT 权限？
如果 schema 下有几十个 sequence，手动一条条写 GRANT SELECT ON schema_a.s1 TO user_b 确实不现实。更稳妥的做法是在 owner schema 下直接生成授权脚本：
SELECT 'GRANT SELECT ON ' || sequence_owner || '.' || sequence_name || ' TO user_b;' FROM dba_sequences WHERE sequence_owner = 'SCHEMA_A';
这里有三个注意事项：
- 必须使用
dba_sequences视图，不能用user_sequences——后者只能查询自己 schema 下的 sequence，查不到其他 schema 的。 - 不加过滤条件时，
dba_sequences会返回所有 schema 的 sequence，所以sequence_owner的值必须拼写正确且全大写，否则无法匹配。 - 执行前确认
user_b已存在，且已授予CREATE SESSION；否则授权成功，但后续用户仍然无法连接。
视图里用了 Sequence，光授视图权限不够
如果 user_b 需要查询的是一张视图，而该视图的定义中调用了 schema_a.seq_x.NEXTVAL，那么只执行 GRANT SELECT ON v_emp TO user_b 是远远不够的——视图的权限不会自动向下传递到底层对象。
必须额外补授：
GRANT SELECT ON schema_a.seq_x TO user_b- 如果视图还依赖了表、函数等其他对象，也需要一并检查并授权。可以通过
SELECT text FROM all_views WHERE owner = 'SCHEMA_A' AND view_name = 'V_EMP'查看视图的定义，找出所有依赖对象。 - 特别提醒：sequence 的
SELECT权限和表的SELECT权限是两套独立的授权体系，不能靠角色自动覆盖。
为什么不用 SELECT ANY SEQUENCE？生产环境应禁用
SELECT ANY SEQUENCE 这个权限，看起来确实省事。但代价很高——它允许用户读取数据库中所有 schema 的所有 sequence 的当前值（CURRVAL）和申请新值（NEXTVAL）。这很容易导致序列号泄露，或被恶意调用把序列号耗尽。
更关键的是，SELECT ANY SEQUENCE 属于系统权限，不支持 WITH GRANT OPTION，而且一旦授予，就无法按对象粒度单独回收。真实生产环境必须坚持“最小权限原则”：
- 只对必要的 sequence 单独授予
SELECT权限 - 避免使用
GRANT SELECT ANY SEQUENCE TO user_b - 如果临时调试需要，授权后务必及时执行
REVOKE收回
Sequence 权限经常被当成“只读附属品”而被忽略，但事实上它控制着主键生成链路。漏授或滥授，都可能导致下游应用报错甚至数据异常。
