GRANT role_name TO user_name 语法完全正确，是Oracle授予角色的唯一标准语法；漏掉TO或顺序错误会报ORA-00995；执行前需确保授予者有GRANT ANY ROLE权限、角色与用户均已存在。
GRANT role_name TO user_name 语法是否正确
完全正确，这是 oracle 授予角色的唯一标准语法。不能写成 grant to user_name role_name 或漏掉 to 关键字，否则报错 ora-00995: missing or invalid keyword。
执行前必须确保：
- 当前连接用户拥有 GRANT ANY ROLE 权限（通常是 SYS 或 SYSTEM）
- 角色已存在（可通过 SELECT * FROM dba_roles WHERE role = 'CONNECT'; 验证）
- 用户已存在（SELECT username FROM dba_users WHERE username = 'ZHANGSAN';）
CONNECT 和 RESOURCE 角色能不能直接授给普通开发用户
能，但要清楚它们的实际能力边界：
-
CONNECT在 10g+ 版本中已简化为仅含CREATE SESSION，不再包含建表等权限；旧文档说它含SELECT等操作，是过时描述 -
RESOURCE包含CREATE TABLE、CREATE SEQUENCE、CREATE PROCEDURE等，但不含CREATE VIEW或CREATE SYNONYM（需单独授） - 两者都不含
UNLIMITED TABLESPACE—— 这在 Oracle 12c+ 是显式分离的，不授会导致建表时报ORA-01950: no privileges on tablespace
所以稳妥做法是：GRANT CONNECT, RESOURCE TO zhangsan; 后紧跟 GRANT UNLIMITED TABLESPACE TO zhangsan;
DBA 角色能不能用 GRANT DBA TO user_name 授予
可以执行，但有强约束和风险：
- 语句本身合法：
GRANT DBA TO zhangsan;不报语法错 - 但执行者必须有
GRANT ANY ROLE，且目标用户不能是SYS、SYSTEM等预定义管理账户（会报ORA-01994: GRANT failed: password file missing or disabled） - 云环境如 AWS RDS、Oracle ADB 会直接拦截该语句，返回
ORA-01031: insufficient privileges，即使你用主账号登录也不行 -
DBA是角色，不是系统权限；用户登录后默认不一定启用，需检查DEFAULT ROLE设置，或手动执行SET ROLE DBA;
生产环境应避免直接授 DBA。真需要部分管理能力，建议复制其权限子集新建受限角色，例如去掉 DROP ANY TABLE、ALTER DATABASE 等高危项。
授完角色后用户还是连不上或建不了表，常见原因
不是授权没生效，而是遗漏了关键前提：
- 用户被锁定了：
ALTER USER zhangsan ACCOUNT UNLOCK;（新建用户默认未解锁） - 密码过期或复杂度不满足策略：
SELECT account_status, expiry_date FROM dba_users WHERE username = 'ZHANGSAN'; - 没授
CREATE SESSION—— 即使授了CONNECT，若该角色被显式设为NONE或DEFAULT ROLE中排除，仍无法登录 - 表空间 quota 为 0：
SELECT username, bytes/1024/1024 mb_used FROM dba_ts_quotas WHERE username = 'ZHANGSAN';，需用ALTER USER zhangsan QUOTA UNLIMITED ON users;
最易忽略的是：角色授了，但用户当前 session 未重连 —— 权限变更对已存在的连接不生效，必须重新 conn zhangsan/password 才能验证。
