oracle 19c rac中ons已弃用，不再由crs管理，真正通知服务由ora.oc4j和ora.eons承载；若遇启动失败，应先清理残留配置、进程及端口冲突，而非尝试启动ora.ons。
ons服务启动失败时先确认它是否该由CRS管理
Oracle 19c RAC 中的 ons（Oracle Notification Service）默认已**不再由 CRS 自动托管**。从 12.1 开始，ons 被 ora.oc4j（Oracle Cloud Control Java Service）替代，而 19c 进一步移除了对独立 ons 的支持。如果你在执行 crsctl start res ora.ons -init 或类似命令后看到 “resource does not exist” 或 “ONS is not managed by CRS”，这不是配置错误，而是功能已被弃用。
检查是否误启用了旧版 ons 配置
部分从 11g/12c 升级上来的环境仍残留 ons.config 文件或手动启动脚本，容易干扰 CRS 启动流程：
-
/etc/oracle/ons.config若存在且非空，需确认是否被遗留的监听器、EM Express 或旧应用依赖；若无明确用途，直接重命名备份（如mv /etc/oracle/ons.config /etc/oracle/ons.config.bak） - 检查
grid用户的 crontab 或 systemd service 是否有类似/u01/app/19.0.0/grid/opmn/bin/onsctli start的调用 —— 19c 中该路径下已无有效二进制，强行执行会失败并可能阻塞后续资源启动 - 运行
ps -ef | grep ons，若看到onsd进程残留，说明有外部进程在拉起它；用kill -9清理后检查父进程来源（常是旧版 OEM agent 或自定义监控脚本）
真正需要通知服务时应改用什么
19c RAC 中所有集群事件通知均由 ora.oc4j 和底层 ora.eons（Event Management Service）统一承载，无需单独维护 ons：
-
ora.oc4j是 CRS 默认启用的服务，状态可用crsctl stat res ora.oc4j -t查看；若为 OFFLINE，通常意味着ora.gipcd或ora.gpnpd未就绪，应优先排查这两者 - 数据库内部的事件通知（如 FAN、AQ、RAC failover）走的是
ora.eons，它由 ASM 实例自动注册，不依赖外部配置文件；只要asm_diskstring正确、ASM 实例正常，它就工作 - 应用端若硬编码依赖 ONS（比如老版本 UCP 或 WebLogic 数据源），必须升级客户端驱动或改用 Oracle Wallet + SCAN 连接方式，避免直连 ONS 端口（6200）
最易被忽略的干扰点：防火墙与端口冲突
即便你没主动启 ons，某些系统级工具（如 Ansible playbook、Zabbix agent 模块）可能尝试探测 6200 端口，触发内核拒绝或 SELinux 拒绝日志，间接导致 CRS 启动卡在 ora.crsd 阶段：
- 检查
journalctl -u ocrd -n 50或crsctl log view -category CRSD，搜索 “6200” 或 “bind: Address already in use” - 运行
ss -tuln | grep :6200，若发现非 Oracle 进程占用了该端口，需协调业务方释放 - SELinux 若处于 enforcing 模式，且未加载 Oracle 相关策略模块，
ora.oc4j启动时可能因无法绑定本地回环地址失败；临时验证可执行setenforce 0，但生产环境应使用semanage port -a -t oracle_port_t -p tcp 6200
