在 Oracle ASM（自动存储管理）的世界里，访问权限的管理逻辑与标准数据库实例颇有相似之处，主要涉及 SYSDBA 和 SYSOPER 两种权限级别。然而，一个关键的区别在于，ASM 实例不包含数据字典，因此所有的身份验证工作都依赖于操作系统级别和/或 Oracle 密码文件来完成。
通常，SYSDBA 权限会通过操作系统组来授予。在 UNIX/Linux 环境中，这个组通常是 dba 组，也被称为 OSDBA 组。在 Oracle 10g 时期，dba 组的成员自动获得该节点上所有实例的 SYSDBA 权限，其中自然也包括 ASM 实例。这意味着，使用 SYSDBA 权限连接到 ASM 实例的用户，就拥有了管理系统中所有磁盘组的“超级管理员”权限。
为了让你对 ASM 实例的运作有更深入的了解，我们梳理了其关键的后台进程及其简要职责：
| 缩略词 |
描述 |
| ACFS |
跟踪集群同步服务 (CSS) 中的集群成员，并在成员变更时通知文件系统驱动。 |
| ARB 0..A |
负责 ASM 文件系统数据区的再平衡操作。 |
| ARSn |
ASM RBAL 后台进程会协调并派生出这类从属进程，用于恢复失败的 ASM 事务型操作。 |
| ASMB |
与 ASM 进程通信，管理存储并提供统计信息。 |
| B000.4 |
在 ASM 磁盘组上执行维护操作。 |
| Bnnn |
在磁盘组上执行维护操作，这类操作需要等待 GMON 相关资源。GMON 进程必须高度可用，不能被长时间阻塞。 |
| FENC |
针对使用 Oracle ASM IOServer 实例的 RDBMS 实例的防护进程。 |
| GMON |
在 ASM 磁盘组中维护磁盘伙伴关系。 |
| MARK |
在一个下线磁盘写丢失后，标记一个 ASM 分配单元 (AU) 为陈旧状态。 |
| OCFn |
维护连接到 ASM 实例进行元数据操作的连接。 |
| Onnn |
维护连接到 ASM 实例进行元数据操作的连接。 |
| RBAL |
在 ASM 实例中，协调磁盘组的再平衡活动，管理磁盘组。 |
| RMON |
管理 Oracle ASM 集群的滚动迁移过程。根据需求被派生，负责将集群转入或转出滚动迁移模式。 |
| Rnnn |
当数据库实例对 ASM 磁盘组的读取发生错误时，如果可行，ASM 会异步调度 Rnnn 子进程，通过镜像数据块来恢复错误。 |
| SCCn |
SCRB 的子进程，执行检查操作。 |
| SCRB |
在 ASM 实例中运行，协调磁盘清洗操作。 |
| SCRn |
SCRB 的子进程，执行修理操作。 |
| SCVn |
执行磁盘清洗验证操作，是 SCRB 的子进程，编号从 SCV0 到 SCV9。 |
| TEMn |
通过命名事件，模拟 ASM 磁盘 I/O 错误，用于测试。 |
| VBGn |
在 ASM 实例和操作系统卷驱动器之间进行通信。 |
| VDBG |
转发 ASM 请求，执行各种与卷相关的任务。 |
| VMBO |
维护代表 ASM 卷驱动器的集群伙伴关系。 |
| VUBG |
在 Oracle ASM 实例和（为 ACFS 使用的）ADVM 代理实例之间传递消息。 |
| Xnnn |
执行 Oracle ASM 再平衡后的清理操作，例如在再平衡结束后将已删除的磁盘除名。 |
到了 Oracle 11g 和 12c，权限模型发生了重要变化。Oracle 引入了专门用于 ASM 管理的 SYSASM 角色，并将其与操作系统中名为 OSASM 的组绑定。这一变更是为了更清晰地划分系统管理员和 数据库 DBA 的职责边界。虽然 SYSDBA 角色仍然可以连接到 ASM 实例，但它不再是最高权限。拥有 SYSDBA 的用户可以访问 V$ 视图，但不再自动拥有 ASM 实例的管理权限。
下面这张表清晰地展示了操作系统组与数据库权限级别的对应关系：
| 操作系统逻辑组 |
DBA权限级别 |
| OSOPER |
SYSOPER |
| OSDBA |
SYSDBA |
| OSASM |
SYSASM |
在 12c 版本中，Oracle 进一步细化了管理职责，新增了三个管理用户角色：SYSBACKUP、SYSDG 和 SYSKM。我们可以通过查询 v$pwfile_users 视图来查看这些权限的分配情况。
SQL> desc v$pwfile_users;
Name Null? Type
-------------------------- -------- ----------------
USERNAME VARCHAR2(30)
SYSDBA VARCHAR2(5)
SYSOPER VARCHAR2(5)
SYSASM VARCHAR2(5)
SYSBACKUP VARCHAR2(5)
SYSDG VARCHAR2(5)
SYSKM VARCHAR2(5)
CON_ID NUMBER
下面的查询展示了哪些用户从密码文件中获得了 SYSDBA、SYSOPER、SYSASM 等权限：
（图中显示，用户 SYS、CRUSER_ASM_001 和 ASMSNMP 分别被授予了不同的管理权限组合。）
ASM 实例同样支持 SYSOPER 权限，但对于一个已经配置好的系统，SYSOPER 被严格限制为只能执行基础运维所需的最少 SQL 命令。
而 SYSASM 权限则允许执行安装、卸载磁盘组以及其他核心存储管理任务。但请注意，拥有 SYSASM 权限的用户不被允许访问常规的 RDBMS 实例。SYSASM 用户可以执行的命令包括：
STARTUP / SHUTDOWNALTER DISKGROUP MOUNT / DISMOUNTALTER DISKGROUP ONLINE / OFFLINE DISKALTER DISKGROUP REBALANCEALTER DISKGROUP CHECK- 访问所有
V$ASM_* 视图
至于其他更高级的操作，例如 CREATE DISKGROUP、ADD/DROP/RESIZE DISK 等，则需要 SYSDBA 权限。SYSOPER 用户则无权执行这些命令。
最后，简单介绍下 12c 新增的三个角色：
- SYSBACKUP: 用于执行所有的备份和恢复操作。
- SYSDG: 用于处理 Data Guard 相关的配置与管理。
- SYSKM: 用于密钥管理等安全相关的操作。
通过这样清晰的权限分离，Oracle ASM 能够更好地支持大规模、多职责的 数据库 环境管理，确保存储管理的安全与高效。如果你想了解更多关于数据库架构与运维的深度讨论，欢迎来 云栈社区 与同行们一起交流。 | 
发表于 前天 02:39
|
查看: 10|
回复: 0
