COMMON 和 Local 用户
无论在 CDB 和 Non-CDB 数据库中,用户都拥有一个 Schema,拥有一系列的 Schema 对象,在 CDB 中由于 PDB 的引入,用户范畴有所不同。
在 CDB 模式下,公用用户(Common User)和本地用户(Local User)两个概念被引入进来,公用用户可以在 CDB 和 PDB中同时存在,能够连接 ROOT 和 PDB 进行操作;而本地用户则只在特定的 PDB 中存在,也只能在特定的 PDB 中执行操作;在 PDB 中不能创建公用用户,而在 CDB 中(CDB$ROOT 中)同样不能创建本地用户。
在 CDB 中创建的公用用户要求以 c##或C## 开头,以下测试以常规方式命名的用户将会创建失败,符合规则的用户可以被创建:
当创建公用用户时,Oracle 会向每个 PDB 中同时创建该用户,如果 PDB 未打开,则创建工作会以任务的方式延后。以下查询显示数据库中只在容器1中存在新创建的用户:
此时打开 PDB,则数据库会自动完成之前挂起的内部创建工作:
下图描述了公用用户和本地用户的区别:
在拥有了 CREATE SESSION 权限后,公用用户能够登陆包括 Root 在内的任何 Container。公用用户一般在每个 PDB 中都存在对应的用户信息,在 PDB 中不能存在与公用用户重名的用户,如初始的 SYS 和 SYSTEM 用户都属于公用用户。也只有公用用户能够授权或被授权相应的公用角色和权限。
公用权限是指对所有 Container 都有效的系统或者对象权限,例如一个公用用户被授予了公用权限 CREATE ANY TABLEWITH ADMIN OPTION 可以将这个权限转授给其他公用用户。公用用户之外的权限被称为本地权限(Local Privilege).
公用角色是指在所有 Container 中都可见的角色,这些角色可能包含全局和本地权限。本地角色只能包含本地权限。授予公用角色的公用权限,对于具有该角色的用户在任何可以连接的 Container 中都将具有该权限。
以下是一些相关的常识性介绍:
一个公用用户在不同 Container 中的 Schema 可以不同;
本地用户只能在各自的 PDB 中进行操作,在不同 PDB 中可以存在同名的本地用户;
PDB 中的本地用户不能登陆其他 PDB 或 ROOT;
PDB 的本地用户只需要在本 PDB 内保持用户名唯一;
本地用户能否访问一个公用 Schema 中的对象取决于其拥有的具体权限;
PDB 能够通过 DB Link 访问其他的 PDB;
在 CDB、PDB 模式下,一个权限在被授权的 Container 中存在。因此,在 PDB 中授予的本地权限和角色和在 Non-CDB 中没有不同,例如,在 PDBHRPDB 中授予本地用户 HR 的 SELECT ANYTABLE 权限,仅在该 PDB 中生效。
相对而言,公用权限和角色可以跨越 Container 生效,当需要跨 Container 进行操作时,需要公用权限或角色,并且这些权限需要在现有和将来创建的 Container 中生效。
在 CDB 中,每个权限或者是在某个 Container 中的本地权限,或者是在所有Container中生效的公用权限。公用权限确保公用用户无需在不同 PDB中重复授权。
类似 CREATE ANYTABLE 的权限,其自身既不是公用权限也不是本地权限,如果一个用户通过 CONTAINER=CURRENT 方式授权,则被授权用户拥有的是本地权限;如果一个权限通过 CONTAINER=ALL 方式授权,则用户获得的是公用权限。因此,一个权限称其为本地或公用权限,完全依赖于其授权方式。
在 CDB 中,每个角色或者是基于 PDB 的本地角色,或者是对全体 PDB 生效的公用角色,所有系统提供的角色(如 DBA)都属于公用角色。
在视图 DBA_USERS 和 CDB_USERS 中都包含了一个字段 COMMON,用于标识公用用户和本地用户。
以下查询显示 SYSTEM 作为公用用户在四个容器中存在:
数据库中存在17个公用用户:
以下查询列出了数据库中的本地用户:
通过指定 CONTAINER 可以限定创建用户的类型,当使用 ALL 选项时,以下命令就创建了一个名为 APPADMIN 的公用用户:
查询 dba_users 视图,可以看到 APPADMIN 的相关用户属性:
注意,在 CDB$ROOT 中不能创建本地用户或角色:
在 PDB 中才可以创建本地用户,以下测试首先连接到 PDB(名称为 ENMO)中,连接用户具备 DBA 权限可以创建用户:
当然在 PDB 中也不允许创建公用用户:
同样在 PDB 中也不能删除公用用户:
以下 SQL 成功在 PDB 下创建了本地用户:
类似的,本地用户不能被授予公用权限或角色,以下尝试在全局授权的命令会返回明确的错误:
在 PDB 内授予本地权限之后,新创建的用户可以登陆本地 PDB 数据库:
下面来研究一下角色。在 CDB_ROLES 视图可以查询 CDB 的角色信息,以下查询可以看到由于 PDB 的引入,角色记录大大增加:
对于 DBA 公用角色来说,在每个 Container 中都存在相应的信息记录:
而对于 PDB_DBA 角色,仅在 PDB 中存在:
同用户管理类似,在 CDB$ROOT 中可以建立公用角色,但是不能创建本地角色,公用角色在每个 PDB 中都存在,同样需要以 c## 为前缀开头:
在 PDB 中,同样不能创建公用角色,仅能创建本地角色:
对于系统权限和对象权限,CDB 相应的增加了对应视图用于存储这些信息:
在 CDB 中可以像在 NON-CDB 的数据库中一样进行权限授予与回收:
COMMON 和 Local 用户的内部隔离
在技术实现上,本地用户和公用用户都存储在底层的 USER$ 字典表,该表的结构如下(内容摘录自 $ORACLE_HOME/rdbms/admin/dcore.bsq 文件):
注意以上结构中的 SPARE1 字段,该字段的注释是“用于 Schema 级别的补充记录”,那么这里补充记录的是什么内容呢?
我们再来查看一下 DBA_USERS 这个视图的内容(摘录内容自$ORACLE_HOME/rdbms/admin/cdenv.sql 文件),其中显示 COMMON 字段内容对应了“decode(bitand(u.spare1,128), 128, 'YES', 'NO')”这一运算结果:
针对在 PDB 中创建的 EYGLE 用户,我们来解析一下 CDB 和 PDB 的用户隔离,由于用户信息是存储在 USER$ 表中,以下查询显示在 PDB 中存在的用户在 CDB 中并不存在,也就是说 PDB 中的用户,仅在 PDB 自己的 SYSTEM 表空间字典表 USER$ 中存在:
首先我们跟踪一下在 PDB 中创建用户的过程:
在跟踪文件目录搜索一下创建用户的语句:
在跟踪文件中记录了创建用户的过程,密码已经被隐藏,摘录主要语句如下,注意 insert 语句将用户信息插入到 USER$ 表中:
如果我们在 CDB 级别创建一个公用用户,那么 Oracle 数据库将如何处理呢?
以下在 CDB 级别进行一次跟踪:
检查跟踪文件,可以发现存在两次 INSERT USER$ 的操作,其中一次是用户进程执行的,另外一次由并行进程执行,也就是将同样的记录插入到 PDB 中:
现在我们再创建一个新的 PDB:
打开两个 PDB:
接下来启用会话和全局的跟踪:
现在可以看到,除了会话进程插入 USER$ 之外,两个并行进程执行了向 PDB 的数据插入,这也就是 CDB 与 PDB 的用户隔离与管理: