oem cloud control 是 oracle rac 官方推荐的 web ui 监控方式，依赖 gv$ 视图、正确集成（主机/代理/凭据/ocr）、catclustdb.sql 执行及 dbsnmp 权限，关键入口为 cluster database home、performance hub > cluster 和 target setup > cluster health。
oracle rac 通过 oracle enterprise manager（oem）cloud control 的 web ui 监控是官方推荐且最直接的方式，不需要写脚本或连 sql*plus 就能掌握集群全局状态。关键前提是 oem 已完成与 rac 集群的正确集成——不是加个数据库目标就完事，漏掉主机、代理、凭据或 gv$ 视图支持，ui 上看到的永远是“部分数据”或“连接失败”。
为什么 OEM UI 能看到 RAC 全局视图，而普通 SQL*Plus 不能？
OEM 不是简单地查 V$SESSION 或 V$INSTANCE，它默认使用 GV$ 系列视图（如 GV$SYSSTAT、GV$LOCK、GV$WAITSTAT），这些视图底层自动聚合所有实例数据，并带 INST_ID 列标识来源节点。但前提是：
-
catclustdb.sql必须已执行（DBCA 创建数据库时默认运行；若手工建库，需 DBA 手动以SYS身份运行） - OEM agent 连接的是数据库服务名（如
orcl.example.com），而非单实例 TNS 别名（如orcl1） - 监控用户（如
dbsnmp）必须有SELECT_CATALOG_ROLE和对GV_$同义词的查询权限
OEM UI 中真正有用的 RAC 专用监控页在哪？
别在“Database Home”页反复刷刷新——那里只显示当前连接实例的局部指标。重点看这三个入口：
-
Cluster Database Home：路径为
Targets > Databases > [your_rac_db_name]，页面顶部明确标注 “Cluster Database”，这里会显示节点数、各节点 UP/DOWN 状态、OCR/Voting Disk 健康度、GCS/GES 等待时间趋势图 -
Performance Hub > Cluster：切换顶部 Tab 从 “Database” 到 “Cluster”，可对比各节点的 CPU 使用率、I/O 延迟、全局缓存块传输量（
gc cr block received/gc current block received） -
Target Setup > Cluster Health：提供 OCR 容量预警、ASM 磁盘组使用率、节点间心跳延迟（
cssdping time）等底层集群健康信号
常见 UI 显示异常及对应检查点
看到 “N/A”、“No data available” 或某节点灰显？先别怀疑 OEM 配置，按顺序验证这四点：
- 在 RAC 每个节点上执行：
crsctl check cluster -all—— 确保 CRS 运行正常，否则 OEM 根本收不到节点心跳 - 确认 OEM agent 进程是否在每个 RAC 主机上运行：
emctl status agent，且输出中包含RAC Database类型目标 - 检查
dbsnmp用户密码是否解锁并同步：ALTER USER dbsnmp IDENTIFIED BY <password> ACCOUNT UNLOCK;</password>，且该密码已在 OEM 的Named Credentials中更新 - 登录任意 RAC 实例，查
SELECT COUNT(*) FROM gv$instance;—— 若返回行数 ≠ 节点数，说明 GV$ 视图未生效或实例未注册到集群
真正容易被忽略的是：OEM 的 “Cluster Database Home” 页面依赖 CRS 的 ora.crsd 资源状态，而这个资源不归数据库控制。哪怕所有实例都 OPEN，只要 crsd 异常，UI 就会降级为单实例视图——此时 crsctl stat res -t 比任何数据库查询都管用。
