必须先授予 create session 权限才能登录数据库，否则后续授权无效；create view 权限仅允许建视图，还需单独授予基表 select 权限，且需指定 schema 名；权限生效需重新连接，oceanbase oracle 模式同理。
必须先有 CREATE SESSION 权限才能登录
没有 CREATE SESSION，用户连数据库都进不去，后续所有授权都是空谈。常见错误是创建完用户就直接授 CREATE VIEW，结果一连接就报 ORA-01045: user ... is not granted CREATE SESSION privilege。
实操建议：
- 用
GRANT CREATE SESSION TO username;作为第一步，且必须由具备该权限的用户（如SYS或SYSTEM）执行 - 如果用户仍无法登录，检查是否被
ACCOUNT LOCK—— 创建时加了ACCOUNT LOCK或后续被手动锁定，需用ALTER USER username ACCOUNT UNLOCK; - Oracle 不会自动刷新已存在的连接会话，新授的
CREATE SESSION对已断开再重连才生效
CREATE VIEW 权限只允许建视图，不等于能查基表
授了 CREATE VIEW，用户可以执行 CREATE VIEW v AS SELECT ...，但只要视图定义里涉及其他用户的表或视图，就会报 ORA-00942: table or view does not exist 或 ORA-01031: insufficient privileges —— 因为缺的是基表上的 SELECT 权限，不是建视图的权限。
实操建议：
- 对每个基表/视图，单独执行
GRANT SELECT ON schema_name.object_name TO username; - 不能省略 schema 名（如
SCOTT.EMP），否则默认指向当前用户 schema，而基表通常不在当前用户下 - 如果基表属于同个用户（比如自己建的表），则只需
GRANT SELECT ON my_table TO username;，无需 schema 前缀 - 注意：
WITH GRANT OPTION不推荐随意加，它允许被授权者继续转授，容易失控
视图创建失败时，优先查 OBJECT PRIVILEGE 而非 SYSTEM PRIVILEGE
错误信息里出现 ORA-01031，不代表系统权限不够，大概率是对象权限缺失。例如用户有 CREATE VIEW，但试图基于 HR.DEPARTMENTS 建视图，却没被授予 SELECT on that object —— 此时 GRANT CREATE VIEW 再多也没用。
实操建议：
- 运行
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE = 'USERNAME' AND TABLE_NAME IN ('DEPARTMENTS', 'EMPLOYEES');确认具体缺哪个对象的哪个权限 - 避免用
GRANT ALL ON ...，尤其对生产表；最小化只给SELECT即可 - 如果基表很多且分散，考虑建角色统一管理：
CREATE ROLE view_reader; GRANT SELECT ON hr.departments TO view_reader; ... GRANT view_reader TO username;
OceanBase Oracle 模式下，权限生效需重新连接
在 OceanBase 的 Oracle 兼容模式中，即使执行了 GRANT SELECT ON emp_view TO test;，当前连接 session 里依然看不到新权限，CREATE VIEW 仍会失败 —— 这和 Oracle 原生行为一致，但容易被忽略。
实操建议：
- 每次执行
GRANT后，务必让目标用户退出并重新连接（DISCONNECT+CONNECT） - 不要依赖
ALTER SESSION SET CURRENT_SCHEMA来绕过 schema 限定 —— 它不改变权限校验的 owner 上下文 - OceanBase V4.3.5 中，
GRANT OPTION和WITH ADMIN OPTION行为与 Oracle 严格对齐，但角色继承链更敏感，建议少嵌套角色
权限链条比看上去长：从登录、到读基表、再到建视图，每一步都卡在具体对象上，而不是笼统的“有没有权限”。最容易漏的是基表的 SELECT，而不是 CREATE VIEW 本身。
