RAC中ALTER SYSTEM必须显式指定SID='*'才能批量生效，否则仅作用于当前实例；SCOPE=SPFILE修改后需全部实例重启才生效，且spfile必须位于共享存储。
alter system在RAC中必须加sid=*才能批量生效
单实例下 alter system set processes=8000 scope=spfile 就能改全库，但在rac里不加 sid 参数，默认只作用于当前连接的实例，其他节点完全不受影响。这是最常踩的坑——你以为改了全局，其实只动了一个节点。
正确写法是显式指定通配符：ALTER SYSTEM SET processes=8000 SCOPE=SPFILE SID='*'。注意单引号不能省，* 必须被包裹，否则报 ORA-00922（missing or invalid option）。
-
SID='*'表示所有实例都写入 spfile，下次启动时全部生效 - 如果只写
SID='rac1'，就只改第一个节点；漏掉某个节点，后续启动可能因参数不一致报 ORA-00093 或 ORA-01078 -
SCOPE=MEMORY不支持SID='*'，它只能作用于当前会话所在实例，RAC 中慎用
哪些参数必须重启才生效？改完别急着验证
不是所有参数改完 SCOPE=SPFILE 就算完事。像 processes、sga_max_size、pga_aggregate_limit 这类底层资源类参数，属于静态参数，修改后必须重启实例才加载。你执行完 ALTER SYSTEM ... SCOPE=SPFILE 后立刻 SHOW PARAMETER，看到的仍是旧值。
验证是否真正生效，得等重启后查 v$parameter 或 gv$parameter：
SELECT inst_id, name, value FROM gv$parameter WHERE name = 'processes';
-
pga_aggregate_limit在 12.2+ 版本有硬性下限（≥2G），设小了直接启动失败，报 ORA-00093 -
log_buffer是典型“仅SCOPE=SPFILE有效”参数，SCOPE=BOTH会报错 ORA-02095 - RAC 中各节点重启顺序无关紧要，但必须全部重启，否则参数不一致会导致集群状态异常
RAC重启不能只用startup，得用srvctl
在 RAC 环境里，手工连到某个实例执行 SHUTDOWN IMMEDIATE + STARTUP 只会启一个节点，其他节点仍运行旧配置，集群可能进入不稳定状态。必须统一用 srvctl 控制整个数据库生命周期。
- 停全部实例：
srvctl stop database -d - 启全部实例：
srvctl start database -d - 查状态确认：
srvctl status database -d，输出应显示所有实例为 “is running” - 如果只改了部分节点的 spfile，又只重启了其中几个实例，
gv$parameter里会出现不同inst_id值不一致的情况，这是严重配置漂移
spfile位置不一致会导致批量修改失效
RAC 的 spfile 必须放在共享存储（如 ASM diskgroup），所有节点指向同一个物理文件。如果误把 spfile 拷贝到本地 $ORACLE_HOME/dbs，或各节点 spfile 路径不一致（比如一个在 +DATA/.../spfile.ora，另一个在 /u01/app/oracle/dbs/spfile.ora），那 SID='*' 实际只改了你当前连接节点看到的那个文件，其他节点读的是另一份。
检查方式：
srvctl config database -d <db_unique_name> | grep Spfile</db_unique_name>
- 输出应为统一 ASM 路径，如
Spfile: +DATA//PARAMETERFILE/spfile.329.1157608177 - 若显示本地路径，说明 spfile 未正确创建在共享存储，需先用
CREATE SPFILE='+DATA/...' FROM PFILE重建 - 修改前务必确认所有节点都从同一个 spfile 启动，否则批量操作毫无意义
