一次 ALTER SYSTEM，埋下一个重启雷：Oracle 内存参数与 SPFILE 的真相
你有没有遇到过这种情况：明明刚刚 ALTER SYSTEM 改过参数，数据库也“正常跑着”，可一重启，配置却悄无声息地回到了旧值？
这并不是 Oracle 在“抽风”，而是很多 DBA 长期忽略的一个关键机制：内存参数 ≠ SPFILE 参数。
在 Oracle 中，你看到的参数值，未必是真正会陪数据库走到下一次启动的配置。
一次 SCOPE=MEMORY，可能只是临时止血；一次 SCOPE=SPFILE，可能已经为下次重启埋下伏笔。
本文通过一套可复现实验，完整拆解：
Oracle 为什么会同时维护两套参数
ALTER SYSTEM 的三种 SCOPE 到底差在哪
如何精准识别“参数已分道扬镳”的风险点
DBA 在生产环境中最容易踩的 3 个坑
如果你负责过生产库，这篇文章一定值得读完并收藏。
01
核心概念：两套独立的“配置清单”
要理解不一致性，首先必须明白 Oracle 实例启动和运行时依赖两套配置：
内存中的参数 (Instance Parameters)
- 作用
这是当前正在运行的数据库实例实际使用的参数值。
它们决定了实例的行为，如允许的最大会话数、每个会话能打开的游标数等。
- 生命周期
这些值存在于内存中，是易失的。
一旦数据库实例关闭（SHUTDOWN），这些内存中的设置就会全部丢失。
SPFILE 中的参数 (Server Parameter File)
- 作用
这是当前正在运行的数据库实例实际使用的参数值。
它们决定了实例的行为，如允许的最大会话数、每个会话能打开的游标数等。
- 生命周期
这些值存在于内存中，是易失的。
一旦数据库实例关闭（SHUTDOWN），这些内存中的设置就会全部丢失。
一个简单的比喻
- 内存参数
就像你正在编辑的一份 Word 文档，你所做的任何修改都会立即生效并显示在屏幕上。
- SPFILE
就像你保存在硬盘上的那个 Word 文件。
只有当你点击“保存”按钮，屏幕上的修改才会被写入文件。
如果你不保存就关闭了文档，所有修改都会丢失。
不一致性就发生在你修改了屏幕上的文档，却没有点击“保存”的时候。
02
罪魁祸首：ALTER SYSTEM 命令
的 SCOPE 子句
导致内存与 SPFILE 参数不一致的唯一直接操作，就是在使用 ALTER SYSTEM SET ... 命令时，指定了特定的 SCOPE（作用域）子句。
ALTER SYSTEM 命令有三个 SCOPE 选项，它们的行为截然不同：
1
SCOPE=MEMORY：只改内存，不改文件
（最常见的原因）
这是导致“内存值与 SPFILE 值不一致”的最主要、最常见的操作。
操作命令
ALTER SYSTEM SET open_cursors = 500 SCOPE=MEMORY;结果
内存中的值变为 500，但 SPFILE 中的值不变。
重启后此修改会丢失。
2
SCOPE=SPFILE：只改文件，不改内存
这种操作同样会造成不一致，但方向相反。
操作命令
ALTER SYSTEM SET sessions = 600 SCOPE=SPFILE;结果
SPFILE 中的值变为 600，但当前内存中的值不变。
修改将在重启后生效。
3
SCOPE=BOTH：同时修改，保持一致
这是最常规、最能保持一致性的操作，通常用于动态参数的永久性变更。
操作命令
ALTER SYSTEM SET open_cursors = 400 SCOPE=BOTH;结果
内存和 SPFILE 中的值都变为 400。
修改立即生效且永久保留。
注意
对于动态参数，SCOPE=BOTH 是默认行为。
如果你在修改动态参数时省略 SCOPE 子句，其效果等同于 SCOPE=BOTH。
03
实验剧场：一步步观察参数的
“分道扬镳”
现在，让我们通过一个完整的实验来亲眼见证这一切是如何发生的。
我们将使用动态参数 open_cursors。
1
第 0 步：实验准备 - 查看初始状态
首先，连接到数据库，查看 open_cursors 参数的当前值，并确认内存与 SPFILE 是一致的。
格式化后的查询
SET LINESIZE 200 COLUMN parameter FORMAT A30 COLUMN memory_value FORMAT A20 COLUMN spfile_value FORMAT A20 SELECT p.name AS parameter, p.value AS memory_value, sp.value AS spfile_value FROM v$parameter p JOIN v$spparameter sp ON p.name = sp.name WHERE p.name = 'open_cursors';假设初始输出为
PARAMETER MEMORY_VALUE SPFILE_VALUE ------------------------------ -------------------- -------------------- open_cursors 1000 1000结论
初始状态下，内存与 SPFILE 的值都是 1000，完全一致。
2
第 1 步：制造不一致 - 使用
SCOPE=MEMORY
我们模拟一次紧急调整，只修改内存中的值。
ALTER SYSTEM SET open_cursors = 500 SCOPE=MEMORY; System altered. SQL>立即检查状态（再次执行上面的格式化查询）：
输出变为
PARAMETER MEMORY_VALUE SPFILE_VALUE ------------------------------ -------------------- -------------------- open_cursors 500 1000结论
不一致性产生了！
内存中的值立即变成了 500，但 SPFILE 的值依然是 1000。
当前实例的行为已经改变（允许更多游标），但这个改变是“暂时的”。
3
第 2 步：验证“重启失效”
现在，我们重启数据库，看看会发生什么。
SHUTDOWN IMMEDIATE; STARTUP;重启后再次检查状态（再次执行上面的格式化查询）：
输出恢复为
PARAMETER MEMORY_VALUE SPFILE_VALUE ------------------------------ -------------------- -------------------- open_cursors 1000 1000结论
SCOPE=MEMORY 的修改在重启后丢失了！ 实例在启动时读取了 SPFILE 中的旧值 1000，并用它初始化了内存参数。参数的一致性又恢复了。
4
第 3 步：制造另一种不一致 - 使用
SCOPE=SPFILE
这次，我们模拟一次计划性变更，只修改 SPFILE。
ALTER SYSTEM SET open_cursors = 400 SCOPE=SPFILE; System altered. SQL>立即检查状态（再次执行上面的格式化查询）
输出变为
PARAMETER MEMORY_VALUE SPFILE_VALUE ------------------------------ -------------------- -------------------- open_cursors 400 1000结论
另一种不一致性产生了！
当前内存值仍然是 1000，实例的行为没有改变。
但 SPFILE 已经被“预修改”为 400，为下次重启做好了准备。
5
第 4 步：验证“重启生效”
我们再次重启数据库。
SHUTDOWN IMMEDIATE; STARTUP;重启后再次检查状态（再次执行上面的格式化查询）：
输出变为
PARAMETER MEMORY_VALUE SPFILE_VALUE ------------------------------ -------------------- -------------------- open_cursors 400 400结论
SCOPE=SPFILE 的修改在重启后生效了！ 实例在启动时读取了 SPFILE 中的新值 400，并用它初始化了内存。
现在，内存和 SPFILE 再次达到了一致，并且是新的永久配置。
04
如何检测参数不一致性？
通过上面的实验，我们知道对比 V$PARAMETER 和 V$SPPARAMETER 是关键。
以下 SQL 脚本可以找出所有不一致的参数。
格式化后的查询
SET LINESIZE 200 COLUMN parameter FORMAT A30 COLUMN memory_value FORMAT A20 COLUMN spfile_value FORMAT A20 COLUMN ismodified FORMAT A10 SELECT p.name AS parameter, p.value AS memory_value, sp.value AS spfile_value, p.ismodified FROM v$parameter p JOIN v$spparameter sp ON p.name = sp.name WHERE p.value <> sp.value;<> 是 != 的标准 SQL 等价形式。
如果这个查询返回了记录，就说明你的数据库存在参数不一致的情况。
ismodified 列如果为 MODIFIED，也明确表示该参数在内存中被修改过。
输出示例
PARAMETER MEMORY_VALUE SPFILE_VALUE ISMODIFIED ------------------------------ -------------------- -------------------- ---------- open_cursors 1000 400 FALSE05
如何解决参数不一致性？
一旦发现不一致，根据你的意图，有以下几种解决方法：
1
如果你希望内存中的值成为永久配置
方法A（推荐）
针对不一致的参数，重新执行 ALTER SYSTEM，但使用 SCOPE=SPFILE 将当前内存值写入 SPFILE。
-- 承接实验第1步，内存是500，SPFILE是300 ALTER SYSTEM SET open_cursors = 500 SCOPE=SPFILE;方法B（全局覆盖）
从当前内存状态创建一个新的 SPFILE。
CREATE SPFILE FROM MEMORY;警告
这个命令会用内存中的所有参数值覆盖 SPFILE，请确保你了解所有内存中的临时修改。
2
如果你希望恢复到 SPFILE 中的原始配置
最简单、最彻底的方法就是重启数据库实例。
重启后，实例会重新读取 SPFILE，所有内存中的临时修改都会被丢弃。
3
如果你想撤销 SPFILE 中的修改
（在它生效前）
如果之前使用了 SCOPE=SPFILE 修改了一个参数，但现在后悔了，可以在重启前再次使用 SCOPE=SPFILE 将其改回旧值，或者使用 RESET 命令。
-- 承接实验第3步，内存是300，SPFILE是400 ALTER SYSTEM RESET open_cursors SCOPE=SPFILE;写在最后
Oracle 参数不一致，从来不是 Bug，而是设计选择。
ALTER SYSTEM 提供的 SCOPE 灵活性，本质上是为了让 DBA 在应急处置、灰度验证、永久变更之间自由切换。
但自由，永远伴随着责任。
真正成熟的 DBA，往往具备三种习惯：
1）每一次改参数，先想清楚：这是临时止血，还是长期方案？
2）定期比对 V$PARAMETER 与 V$SPPARAMETER，不让“隐形配置”潜伏
3）在生产环境，尽量避免“只改内存却不留痕”的操作
记住一句话：数据库真正的配置，不在你刚改完的那一刻，而在下一次 STARTUP 之后。
原文链接：https://mp.weixin.qq.com/s/gUmSGK46rj6GtQljV4zcxA