oracle对象级权限必须显式授予，不存在默认继承或隐式权限；不执行grant就无法访问目标对象，哪怕用户有connect或resource角色。
oracle 对象级权限必须显式授予，不存在默认继承或隐式权限；不执行 grant 就无法访问目标对象，哪怕用户有 connect 或 resource 角色。
GRANT ON 表、视图、序列等对象的语法要点
核心结构是 GRANT privilege ON schema.object_name TO user_or_role，其中 schema 不能省略（除非是当前用户自己的对象且未启用 current_schema 设置）。
-
privilege必须是具体动作：如SELECT、INSERT、UPDATE、DELETE、EXECUTE（对过程/函数）、ALTER（对表/序列）、INDEX（对表）等，不支持ALL通配符用于非 DBA 用户（GRANT ALL ON ...需要DBA权限） - 对象名必须带 schema：例如
hr.employees，不能只写employees（否则默认解析为当前用户 schema，容易授错对象） - 目标可以是单个用户、角色或
PUBLIC；但向PUBLIC授予敏感操作（如UPDATE）属于高危行为，生产环境应避免 -
WITH GRANT OPTION允许被授权者再转授该权限，但仅限同一对象、同一权限级别；它不传递系统权限，也不自动赋予SELECT ANY TABLE这类全局权限
常见错误：明明执行了 GRANT 却仍报 ORA-00942 或 ORA-01031
典型现象是用户执行 SELECT * FROM hr.employees 报 ORA-00942: table or view does not exist，或执行 INSERT 报 ORA-01031: insufficient privileges。
- 用户没被授予
SELECT权限，而是只授了INSERT—— 对象权限按动作独立控制，INSERT不隐含SELECT - 误以为
GRANT SELECT ON employees TO user能生效，实际对象在hrschema 下，语句应为GRANT SELECT ON hr.employees TO user - 用户用 PL/SQL Developer 或 SQL*Plus 登录后未新开会话：权限变更只对新会话生效，当前会话缓存旧权限状态，需断开重连或执行
ALTER SESSION SET CURRENT_SCHEMA = hr（仅影响默认 schema 解析，不改变权限本身） - 目标对象是同义词（synonym），但
GRANT是对基表执行的；如果只给同义词授了权而没给底层表授，权限无效
列级权限与 WITH GRANT OPTION 的实际限制
Oracle 支持列级 GRANT（如 GRANT UPDATE(salary) ON hr.employees TO user），但有硬性约束：
- 只能用于
UPDATE和REFERENCES，不支持SELECT列级授权（GRANT SELECT(col1) ON t TO u语法非法） -
WITH GRANT OPTION在列级下依然有效，但被授权者只能把相同列的相同权限转授出去，不能扩大范围（例如不能把UPDATE(salary)转授为UPDATE(salary, dept_id)） - 若用户已有全表
UPDATE权限，再授列级权限无意义；反之，列级权限不会叠加出全表权限 - 视图上的列级授权，实际检查的是视图定义中对应基表列的权限，不是视图自身列
验证权限是否真正生效的最快方式
别依赖角色或文档描述，直接查数据字典确认当前用户视角下的有效权限：
- 查当前用户能访问哪些对象：
SELECT * FROM USER_TAB_PRIVS（只显示授予本用户的对象权限） - 查某用户被授予了哪些对象权限（需 DBA 权限）：
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE = 'USER_NAME' - 注意区分
DBA_TAB_PRIVS和DBA_COL_PRIVS：后者才包含列级授权记录 - 测试时务必用目标用户真实登录执行，不要在管理员会话里用
SET ROLE模拟——角色激活不影响对象权限的解析逻辑
最易被忽略的一点：权限检查发生在 SQL 解析阶段，不是执行阶段。哪怕你用动态 SQL（EXECUTE IMMEDIATE）拼出合法语句，只要当前用户在解析时没有对应对象权限，仍会立即报错，不会等到运行时才拦截。
