RAC中关键参数如cluster_database、db_files、compatible等必须全节点统一修改并重启，否则导致实例启动失败或ORA-00600；非一致性参数如_parallel_max_servers、optimizer_mode可单节点在线调整。
在Oracle RAC环境下直接用ALTER SYSTEM SET ... SCOPE=BOTH修改大多数关键参数，基本等于给集群埋雷——不是报错失败，就是节点行为不一致、实例hang住或归档中断。必须区分参数类型，按“一致性参数”和“非一致性参数”走不同路径，否则重启后一个节点起不来是常态。
哪些参数必须全节点统一修改且需重启？
这类参数写在SPFILE里，被所有实例共享读取，一旦某节点值不同，CRS会拒绝启动该实例。典型包括：
-
cluster_database：设为FALSE临时关闭RAC模式时，必须sid='*'全局生效，否则只改一个节点会导致集群状态分裂 -
db_files：控制文件硬编码的上限值，修改后所有节点重启才能加载新限制；若只改节点1的SPFILE但节点2没同步，节点2启动时会因控制文件中记录的db_files值与SPFILE冲突而报ORA-00722 -
compatible、control_files、sga_max_size：这些直接影响实例初始化流程，任意节点值不一致都会触发ORA-00600内部错误
操作前务必先用CREATE PFILE FROM SPFILE备份，并在所有节点用srvctl config database -d <db_name>确认当前SPFILE路径一致。
哪些参数可以单节点在线调整？
仅影响当前实例内存结构、不涉及控制文件或集群协调逻辑的参数，允许用sid='racdb1'指定节点单独改。常见有：
-
_gc_bypass_readers、_gc_read_mostly_locking：RAC缓存融合相关隐藏参数，关闭后能缓解gc current request等待，但必须逐个节点验证效果 -
parallel_max_servers：并行进程数，改完立刻生效，不影响其他节点资源分配 -
optimizer_mode：SQL优化器行为，仅作用于本实例解析的语句
注意：SCOPE=BOTH对这类参数实际只写入内存+SPFILE，不会广播到其他节点，所以无需停集群。但若后续执行srvctl stop/start database，所有节点会从SPFILE重新加载，此时未显式指定sid的修改就变成全局生效了。
RAC环境改参数最常踩的三个坑
很多DBA卡在“明明改了却没生效”或“改完一个节点OK，另一个起不来”，根源往往在这几个细节：
- 忘了
sid='*'或sid='racdb1'：默认ALTER SYSTEM只作用于当前连接的实例，RAC下容易误以为是全局操作 - SPFILE不在共享存储：如果SPFILE放在本地文件系统（如
/u01/oracle/dbs/spfileracdb.ora），节点2根本读不到节点1改过的值，srvctl start instance -i racdb2必然失败 - 改完没验证
gv$parameter：必须查SELECT inst_id, name, value FROM gv$parameter WHERE name = 'db_files'，确认所有inst_id返回值一致，不能只看当前实例的v$parameter
真正危险的不是参数本身，而是修改动作在RAC多实例视角下的可见性差异——同一句SQL，在节点1执行和在节点2执行，背后是两套独立的内存结构和一套共享的控制文件，这个三角关系理不清，任何参数调整都可能变成故障导火索。
