srvctl启动数据库失败主因是ASM实例未启、磁盘组未挂载或SPFILE不可用；停库不生效因默认IMMEDIATE模式不强制杀进程；状态漂移需用srvctl start instance同步OCR；配置不生效因OCR与SPFILE参数未对齐。
srvctl 启动数据库失败：ORA-01078 和 CRS-2674 常见原因
直接启动 srvctl start database -d <db_name></db_name> 报错，多数不是权限或路径问题，而是底层资源依赖没就绪。比如 asm 实例没起来、磁盘组没挂载、监听器未注册，srvctl 会静默卡在 crs 层，最终抛出 crs-2674: start of 'ora.<db_name>.db' failed</db_name>，而真正根源藏在 ora-01078: failure in processing system parameters 里——这通常意味着 spfile 找不到，或 asm 磁盘组不可用。
实操建议：
- 先确认 ASM 实例状态：
srvctl status asm -n <node_name></node_name>，再查磁盘组：sqlplus / as sysasm -c "select name,state from v$asm_diskgroup;" - 检查 SPFILE 是否在可用磁盘组中：
sqlplus / as sysdba -c "show parameter spfile"，输出路径必须能被所有节点通过 ASM 或共享文件系统访问 - 别跳过
crsctl check crs，如果 CRS 自身异常（如CRS-4638: Oracle High Availability Services is online没出现），后续所有srvctl命令都只是空转
srvctl stop database 不生效：实例仍在运行的真相
srvctl stop database -d <db_name></db_name> 返回成功，但 ps -ef | grep pmon 还能看到进程？这不是命令失效，而是默认停库模式是 IMMEDIATE，它只发 shutdown immediate 给每个实例，但不强制杀 OS 进程。如果某个实例 hang 在归档、锁等待或 RAC 全局队列同步上，PMON 可能迟迟不退出。
实操建议：
- 加
-o abort强制终止：srvctl stop database -d <db_name> -o abort</db_name>，等价于每个节点执行shutdown abort，但注意这会丢失未写入的数据缓冲区内容 - 停库前先看实例分布：
srvctl status database -d <db_name></db_name>，确认哪些节点上有实例，避免只在部分节点操作 - 停完立刻验证：
srvctl status instance -d <db_name> -i <inst_name></inst_name></db_name>，比查进程更可靠；ps看到残留进程时，优先用srvctl start instance尝试拉起，而不是手动 kill
srvctl status 输出 “Instance not running” 却有 pmon 进程
这是 RAC 最典型的“状态漂移”现象：实例进程活着，但 OCR 中记录的状态是 OFFLINE。常见于节点重启后 CRS 没自动拉起数据库，或手工用 sqlplus / as sysdba 启了实例但没走 srvctl 流程。
实操建议：
- 不要直接 kill 进程再用
srvctl start，先尝试同步状态：srvctl start instance -d <db_name> -i <inst_name></inst_name></db_name>，如果报CRS-2632: There are no more servers to try to place service，说明实例已运行但 CRS 不知情，此时用srvctl enable database -d <db_name></db_name>再重试 - OCR 状态和实际进程不一致时，
crsctl stat res -t比srvctl status更底层、更准确，重点关注ora.<db_name>.db</db_name>和ora.<db_name>.<inst_name>.inst</inst_name></db_name>的 STATE 列 - 避免混合使用手工 SQL 启停和
srvctl，RAC 环境下所有生命周期操作必须走 CRS 接口，否则状态必然脱钩
srvctl 修改数据库配置后不生效：spfile vs server parameter file
用 srvctl modify database -d <db_name> -s <start_options></start_options></db_name> 或 -y automatic 改了启动参数，重启后发现没变？问题出在 srvctl 只改 OCR 中的启动选项（如 open、mount），不碰数据库内部的 SPFILE。真正控制实例启动行为的是 SPFILE 里的 cluster_database、instance_number 等参数。
实操建议：
- 修改数据库级启动行为（比如默认启动到 mount）：
srvctl modify database -d <db_name> -s mount</db_name>，但必须配合 SPFILE 中startup mount语义一致，否则srvctl start仍会按 SPFILE 指令 open - 改 SPFILE 必须用
alter system set ... scope=spfile，且在所有实例上执行（RAC 要求所有节点看到相同参数），不能只在一个节点改 - OCR 配置和 SPFILE 参数冲突时，以 SPFILE 为准；
srvctl config database -d <db_name></db_name>显示的是 OCR 记录，show parameter显示的是运行时值，两者要人工对齐
OCR 和 SPFILE 是两套独立的状态源，RAC 管理员容易只盯一边。最麻烦的是 OCR 记录正确、SPFILE 参数错误，或者反过来——这种错位不会报错，但每次启停都会行为异常。
