Oracle SGA调参起不来：pfile与spfile应急恢复指南

简介：这份文档面向 Oracle 数据库运维与开发人员，聚焦 SGA 参数调整后实例无法正常启动的应急排查场景，适合需要快速定位内存参数错误、恢复数据库可启动状态并补强故障处理思路的读者参考。压缩包共 1 个 docx 文件，大小约 14KB，围绕启动异常成因、基于 pfile 的应急启动与 spfile 重建、pfile 参数修正以及 spfile 备份恢复等路径展开，并提示调整前备份、调整后验证启动与性能等注意事项。文档将三类恢复思路与风险提醒并列呈现，便于在变更回退、日常巡检和面试复习中快速查阅，理解 SGA 参数、启动文件与实例状态之间的关联。已有 328 人学习，可作为轻量排错参考，帮助读者建立从现象判断、原因定位到恢复验证的完整框架。

1. 一次 SGA 调参把库卡在 nomount 阶段：先弄清 spfile 与 pfile 的分工

某开发者在测试库把sga_max_size从 396M 调到 2G，alter system set ... scope=spfile执行完，shutdown immediate之后startup敲下去，屏幕只剩一行ORA-01078和一串LRM开头的报错，实例连 mount 都到不了。这就是很典型的 oracle 改 sga 异常：参数文件里的内存值超过了操作系统能给的上限，而 spfile 是二进制，没法用 vi 打开把那一行删掉，于是“改错了回不去”变成了死循环。真正能救场的，是实例目录里那份带时间戳的 pfile 文本副本。下面按“参数怎么生效 → 三条恢复路线 → 现场坑 → 变更前检查单”的顺序拆开讲，手上正压着一台起不来的库、又不想重建实例的人可以直接照着走。

2. SGA 改错后为什么起不来：内存分配的层级与参数文件加载顺序

2.1 SGA 的几块内存和 sga_max_size、sga_target 的硬约束

SGA 在实例启动时一次性向操作系统申请连续共享内存，内部切成四块：Fixed Size（实例和线程的固定开销）、Variable Size（shared pool、large pool、java pool 等共享池类组件）、Database Buffers（数据块缓存）、Redo Buffers（日志缓冲）。show sga或startup输出里Total System Global Area就是这四块之和，后面四个字节数一一对应。参数调整改的就是这个总和以及它的分配比例。

约束关系是层层向下的。开了 AMM（自动内存管理）时memory_target是总闸，sga_target只能在其中占一部分；只开 ASMM（自动共享内存管理）时sga_target是闸门，各组件自动分配；全部手工设的话，db_cache_size、shared_pool_size这些直接决定各块大小。无论哪种模式，SGA 的上限都被sga_max_size卡死，而sga_max_size又是静态参数，只能scope=spfile后重启生效——这就是改错的代价特别大的原因：生效点在重启那一刻，一旦重启失败，你连改回来的机会都没有。

理解这张表最关键的一句：sga_max_size决定了共享内存段申请多大，而共享内存段申请失败，实例会在 nomount 之前就退出。所以这类故障的表现永远不是“库能起但慢”，而是“根本起不来”。

2.2 启动三个阶段与参数文件的查找顺序

实例启动分三步：nomount（读参数文件、分配 SGA、启动后台进程）、mount（读控制文件）、open（打开数据文件和重做日志）。参数文件在第一步之前就要读完，SGA 也在第一步分配，所以任何内存参数错误都卡在 nomount，报错出现在startup的第一屏。

不带参数执行startup时，Oracle 按固定顺序在$ORACLE_HOME/dbs下找参数文件：先找spfile$ORACLE_SID.ora，再找spfile.ora，最后找init$ORACLE_SID.ora。找到 spfile 就用 spfile，找不到才退到 pfile。startup pfile='完整路径'是唯一能强制跳过 spfile 的入口，这也是应急恢复的核心动作。

spfile 是二进制格式，只能由实例自己读写；pfile 是纯文本，一行一个参数=值，可以用任何编辑器改。两者可以互相转换：create spfile from pfile='...'把文本烧成二进制，create pfile='...' from spfile把二进制导出成文本。这套双向通道就是三条恢复路线能成立的基础。

2.3 报错文本对照：不同错误码指向不同层

现场第一件事不是急着敲命令，而是看懂报错落在哪一层。带LRM前缀的是参数文件读取层的问题，带ORA-008xx的是参数值本身不合法，带ORA-271xx的是操作系统层面共享内存分配失败。

看到ORA-27102就去查操作系统，看到ORA-00823就去对齐两个参数，看到ORA-01078先别怀疑参数值，八成是文件根本没找到。分清这三类，能省掉大量盲目试错。

3. 应急启动的第一条路：用 pfile 拉起实例再反向生成 spfile

3.1 先定位 pfile，确认哪份文件能对上现在的内存

动手之前先把环境变量钉死。多实例机器上最常见的翻车不是参数错，而是ORACLE_SID指向了另一个库，所有操作都做在隔壁实例上了。

# 当前会话认的是哪个实例，后面所有路径都以它为准 echo $ORACLE_SID # ORACLE_HOME 是否指向出问题的那套软件目录 echo $ORACLE_HOME # 参数文件默认都放在这里，先看看 spfile 和 init 文件在不在 ls -l $ORACLE_HOME/dbs | grep -i -E "spfile|init" # 建库时留档的 pfile 副本（带时间戳的这份是应急入口） ls -lt $ORACLE_BASE/admin/$ORACLE_SID/pfile/ | head

$ORACLE_HOME/dbs是参数文件、密码文件、实例锁文件的集中地，ls结果里应该能看到spfileORCL.ora这种命名。$ORACLE_BASE/admin/$ORACLE_SID/pfile/下那份init.ora.8282011115435是建库工具当年留下的文本快照，文件名后缀就是一串时间戳，同一实例可能有好几份，按修改时间排序取最近的那份。这里有个前提：11g 及更早版本建库时基本都会留这份副本，12c 之后部分环境不再自动生成，那就只能靠create pfile from spfile提前导出，或者走 5.1 里说的兜底手段。

找到文件后先别急着启动，用grep把内存相关行过一遍，心里有个数：

# 只看内存相关参数，确认这份 pfile 里的值是老的还是新的 grep -n -i -E "sga_max_size|sga_target|memory_target|memory_max_target|pga_aggregate" \ $ORACLE_BASE/admin/$ORACLE_SID/pfile/init.ora.8282011115435

这一步的意义在于预判。如果 pfile 里的sga_max_size还是 396M，那用它启动一定能成功，但起来之后 SGA 也是 396M，跟你原本想调的 2G 不是一回事——这是后面 5.1 第一条坑的伏笔。

3.2 startup pfile 的完整操作与输出解读

用本地协议登录，绕开监听，少一个故障变量。sqlplus / as sysdba走的是操作系统认证，不依赖listener.ora和tnsnames.ora，实例起不来时这是唯一稳的入口。

-- 本地认证登录，不经过监听 sqlplus / as sysdba -- 指定文本参数文件启动，强制跳过出问题的 spfile SQL> startup pfile='/u01/app/oracle/admin/ORCL/pfile/init.ora.8282011115435';

正常情况会看到这样的输出：

ORACLE 例程已经启动。 Total System Global Area 612368384 bytes Fixed Size 1250428 bytes Variable Size 167775108 bytes Database Buffers 436207616 bytes Redo Buffers 7135232 bytes 数据库装载完毕。 数据库已经打开。

逐行读这份输出：ORACLE 例程已经启动说明 nomount 过了，共享内存段申请成功、后台进程起来了；数据库装载完毕说明控制文件读到了，control_files参数没问题；数据库已经打开说明数据文件和重做日志都在线。四块内存的字节数加起来正好等于 Total，612368384 bytes 换算下来约 584M。

这里必须停一下做对照：之前show parameter sga看到的是 396M，现在用 pfile 起来是 584M。两个数不一致，恰恰证明这份 pfile 是更早时间点的快照，跟当前 spfile 里的值不是一套。能起来不等于修好了，只是拿到了一个能操作的实例。

3.3 create spfile from pfile 的顺序：先建再关，还是先关再建

拿到活着的实例之后，把 pfile 烧成 spfile，让下次startup能走默认路径。命令本身很短，坑在顺序和覆盖。

-- 覆盖前先把原来的 spfile 挪走，别问，问就是血泪经验 -- 这一步在操作系统层面做，见 4.2 -- 用指定 pfile 生成 spfile，不写目标路径就落在 $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora SQL> create spfile from pfile='/u01/app/oracle/admin/ORCL/pfile/init.ora.8282011115435'; 文件已创建。 -- 关闭实例，让新 spfile 在下次启动时生效 SQL> shutdown immediate; 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 -- 这次不带参数，走默认查找顺序，能起来说明 spfile 已经接管 SQL> startup;

create spfile from pfile在实例 open 状态下执行是允许的，写文件这个动作本身不依赖实例状态；但更保守的做法是先shutdown immediate，再startup nomount pfile='...'，在 nomount 状态下创建，减少还在跑的会话对参数的干扰。两种都能成，差别在于 open 状态下创建会覆盖现有 spfile，而现有 spfile 可能还被正在运行的实例引用——虽然 Oracle 对这种情况有处理，但变更窗口里少一个不确定因素总是好的。

命令里两个路径参数要分清：from pfile=后面跟的是源文本文件，必须写绝对路径；不写=后面的目标名时，输出固定落在$ORACLE_HOME/dbs/spfile$ORACLE_SID.ora，也就是默认查找顺序里的第一位。如果只想生成到临时位置做比对，可以写成create spfile='/tmp/spfile_test.ora' from pfile='...'，不会动到生产文件。

3.4 三连验证：spfile 是否接管、SGA 实际多大、参数从哪来

启动成功不等于收工，三件事必须确认。

-- 第一连：返回空值说明还在用 pfile，返回路径说明 spfile 已接管 SQL> show parameter spfile; NAME TYPE VALUE ----------- ----------- ------------------------------ spfile string /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileORCL.ora -- 第二连：实际生效的 SGA 值，跟你的目标值对不对得上 SQL> show parameter sga; NAME TYPE VALUE ----------------- ------------ ------------------------------ lock_sga boolean FALSE pre_page_sga boolean FALSE sga_max_size big integer 396M sga_target big integer 396M -- 第三连：从参数源头看，哪些值是 spfile 里明确写死的 SQL> select name, value, isspecified 2 from v$spparameter 3 where name in ('sga_max_size','sga_target','memory_target','memory_max_target');

第一连是判断“现在到底在用哪个参数文件”，show parameter spfile返回空就说明实例是从 pfile 起来的，这时候重启一次会退回原状，必须做 3.3 的转换。第二连看实际值，396M 说明从 pfile 继承的是老配置，如果业务需要 2G，现在得在sga_max_size允许的范围内重新设。第三连最关键，v$spparameter里的isspecified列是TRUE表示这个参数在 spfile 里有显式记录，FALSE表示用的是默认值——排查“改了没生效”时，先看这一列比反复重启有用得多。

4. 另外两条路：直接改 pfile 参数与 spfile 备份回滚

4.1 手工编辑 init.ora：改哪几行、改完怎么核对

如果手上有可用的 pfile，但里面的内存值本身就是错的（比如memory_target设成了物理内存的两倍），那就别急着转换，先把文本改对。

# 改之前先留一份，改废了还能退回来 cd $ORACLE_BASE/admin/$ORACLE_SID/pfile cp init.ora.8282011115435 init.ora.8282011115435.bak # 定位所有内存相关行，记下行号 grep -n -i -E "sga_max_size|sga_target|memory_target|memory_max_target|pga_aggregate_target" \ init.ora.8282011115435 # 用 vi 改，形如 *.sga_max_size=800M，单位可以写 M/G，也可以写字节数 vi init.ora.8282011115435

pfile 里的参数行两种写法都合法：带*.前缀的表示对所有实例生效，不带前缀的表示只对当前实例生效，单实例环境两者等价。值可以写800M、2G这种带单位的形式，也可以写纯字节数。改完之后不要直接startup，先用grep复核一遍，确认没有手滑写成8G或者漏掉单位。

哪几行该改，取决于当前是哪种内存管理模式：

注释用#，把整行注释掉等于让这个参数走默认值，这比删掉更安全，回滚时把#去掉就行。改完保存，再走 3.2 的startup pfile=验证，能起来再走 3.3 烧成 spfile。

一个容易忽略的点：pfile 里如果同时存在memory_target和sga_target，且sga_target大于memory_target，实例同样起不来。手工编辑时最容易只改一个忘了另一个，改完用一条命令把两者摆在一起看：

# 把两个互斥参数并排打印，肉眼比对大小关系 grep -i -E "memory_target|sga_target|sga_max_size" init.ora.8282011115435 | sort

4.2 spfile 备份与恢复：dbs 目录里到底该备份哪些文件

第三条路是事前功夫：改参数之前把$ORACLE_HOME/dbs整个目录备一份，出问题原样贴回去。这条路恢复最快，代价是要有先见之明。

# 变更前整目录打包，时间戳进文件名，方便回溯 tar -czf /backup/dbs_$(date +%Y%m%d%H%M).tar.gz -C $ORACLE_HOME dbs # 只想备参数文件的话，至少这三个 cp $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora /backup/spfile${ORACLE_SID}.ora.bak cp $ORACLE_HOME/dbs/init$ORACLE_SID.ora /backup/init${ORACLE_SID}.ora.bak 2>/dev/null ls -l $ORACLE_HOME/dbs/

dbs目录里值得关注的文件有几类：spfile$ORACLE_SID.ora是二进制参数文件，核心中的核心；init$ORACLE_SID.ora是可选的文本参数文件，很多环境根本没有；orapw$ORACLE_SID是密码文件，重装实例后经常忘了它导致远程登录失败；lk$ORACLE_SID是实例锁文件，实例异常退出后可能残留，正常关闭时会自动清理；hc_$ORACLE_SID.dat跟健康检查有关，一般不用管。整目录打包最省事，也避开了“以为备全了其实漏了一个”的情况。

恢复时有个硬前提：实例必须处于关闭状态，否则文件被进程占用，cp覆盖过去也没用，下次启动读的还是内存里的旧句柄。

# 先确认实例真的关了，输出里不应该有 ORACLE 进程 ps -ef | grep -i ora_ | grep -v grep # 把备份的 spfile 贴回原位 cp /backup/spfileORCL.ora.bak $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora # 权限和属主必须对，否则实例读不到文件，报的还是 ORA-01078 chown oracle:oinstall $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora chmod 640 $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora # 不指定 pfile 启动，验证是否回到变更前的状态 sqlplus / as sysdba SQL> startup;

权限这一条是纯粹的运维细节，但现场翻车率极高：用 root 拷过去的文件属主是 root，Oracle 读不了，报错还是ORA-01078，看着跟参数错误一模一样，很容易往错误方向排查。ls -l看一眼属主是oracle:oinstall、权限是640，能省半小时。

4.3 三条路怎么选：恢复时间与代价对照

三条路不是备选关系，是不同时间点的不同手段。事前有备份走第三条最快，事中能起来走第一条最稳，起来但参数本身错走第二条最直接。

真实场景里通常是组合拳：先用第一条把库拉起来止血，再用第二条在 pfile 里改成目标值，重新烧一遍 spfile，最后补一份备份给下次用。单纯依赖任何一条都有短板——只靠 pfile 会一直跑在旧参数上，只靠备份则要求你事前真的备了。

5. 排查与避坑：五条从现场捡回来的记录

5.1 五个典型故障的现象、原因与处置

第一条：pfile 起是起来了，但 SGA 明显比预期小。

现象是startup pfile=一切正常，show parameter sga却显示 396M，业务反馈性能没有任何改善。原因是那份带时间戳的 pfile 是建库时的快照，里面的sga_max_size还是当年的老值，用它启动等于把内存配置退回了原点。处置办法是先看 3.1 的grep结果确认目标值，在 pfile 里把sga_max_size和sga_target改到需要的大小，再执行create spfile from pfile；如果只是想临时提一点，也可以在sga_max_size范围内用alter system set sga_target=... scope=both动态调，但那改不了上限。

第二条：转换完 spfile、重启还是失败。

现象是create spfile from pfile显示文件已创建，shutdown之后startup依旧报错。原因是 pfile 里除了内存参数，还有别的坏值没被注意到，比如memory_target大于/dev/shm，或者control_files指向了不存在的路径。处置办法是不要急着 open，先用startup nomount pfile='...'分段验证——能到 nomount 说明内存参数过关，卡在 mount 就是控制文件的问题，一层层往上排。同时用grep -v "^#"把 pfile 里所有生效行打出来逐条看，比盯着报错猜快得多。

第三条：报ORA-00845: MEMORY_TARGET not supported on this system。

现象是只要 pfile 里带memory_target就起不来，注释掉就能起。原因是这台机器的/dev/shm太小，AMM 需要在这个 tmpfs 上映射共享内存，空间不够直接拒绝。处置办法是先df -h /dev/shm看实际大小，需要扩的话改/etc/fstab里 tmpfs 那行的size=参数，重新挂载后生效；不想动系统的，直接把memory_target和memory_max_target注释掉，退回 ASMM 用sga_target管，功能上没损失，只是少了自动在 SGA 和 PGA 之间调配的灵活性。

第四条：报ORA-27102: out of memory或ORA-27123。

现象是 SGA 调大之后实例完全起不来，报错落在ORA-271xx段。原因通常有两个：一是内核shmmax/shmall限制了单个共享内存段的上限，SGA 超过就申请不到；二是开了大页（HugePages），但vm.nr_hugepages预留的页数覆盖不了新的 SGA，实例发现大页不够又不愿意退回普通页，直接失败。处置办法是cat /proc/meminfo | grep -i huge看HugePages_Total和HugePages_Free，按SGA / 大页单页大小算出需要的页数，改vm.nr_hugepages后sysctl -p生效；同时确认use_large_pages的取值，设成only时大页不够就一定失败，设成auto会好一些。

第五条：手里根本没有可用的 pfile。

现象是admin/$ORACLE_SID/pfile目录是空的或者压根不存在，dbs下只有一个坏掉的 spfile，第三条路的备份也没有。原因是建库时没留副本，或者历史上清理过目录。处置办法分两级：软办法是用strings $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora把二进制里的可读片段捞出来，能拼出大部分参数名和值，虽然格式乱但足够当参考；硬办法是手写一份最小 pfile，只保留db_name、instance_name、control_files、sga_max_size、sga_target、db_block_size、compatible、undo_tablespace这几项，其余全走默认值，先让实例能到 mount，再逐步补齐。这条路能救回来，但过程很磨人，所以更该做的是平时就用create pfile定期导出一份文本快照。

5.2 恢复之后的复核清单

库起来了不等于事情结束，参数是否真的落到了 spfile、下次冷启动会不会再翻车，得逐项确认。

-- 1. 确认 spfile 已被接管，VALUE 不为空 SQL> show parameter spfile; -- 2. 确认实际 SGA 大小与目标一致 SQL> show parameter sga; -- 3. 逐条核对 spfile 里显式记录的参数，isspecified=TRUE 的才是写死的 SQL> select name, value from v$spparameter 2 where isspecified='TRUE' 3 and name in ('sga_max_size','sga_target','memory_target','memory_max_target','pga_aggregate_target'); -- 4. 看当前实例真正在用的值，和上一步对比 SQL> select component, current_size/1024/1024 as mb 2 from v$sga_dynamic_components 3 where current_size > 0 4 order by mb desc;

第三步和第四步的差别值得说清楚：v$spparameter反映的是“参数文件里写了什么”，v$sga_dynamic_components反映的是“实例现在实际分配了多少”，两者不一致说明有组件在动态调整，或者参数没生效。恢复操作做完，这两组数应该能对上，对不上就说明 spfile 转换那一步有问题，需要回头重来。

还有一件必做的事：把这次恢复用的 pfile 复制一份到备份目录，改名带上日期，别指望下次还能在admin目录里找到它。

# 恢复用的 pfile 单独留档，别跟建库时的快照混在一起 cp $ORACLE_BASE/admin/$ORACLE_SID/pfile/init.ora.8282011115435 \ /backup/pfile_${ORACLE_SID}_$(date +%Y%m%d).ora

6. 让下一次不靠运气：把 SGA 变更做成一页可回滚的检查单

这套流程走过几次之后，我把它压成了一张变更前必须过一遍的检查单。核心思路是：所有 SGA 变更都当成“可能起不来”的操作来对待，提前把退路铺好，而不是等报错了再找 pfile。

第 2 步那个导出动作我强烈建议常态化，不要只在变更前做。一条命令就能拿到当前 spfile 的完整文本副本：

-- 把二进制 spfile 导出成可读文本，文件名带日期，随时可比对 SQL> create pfile='/backup/pfile_ORCL_20240612.ora' from spfile; 文件已创建。

导出的文件可以直接用diff跟变更后的版本比对，哪几个参数动了、动了多少，一目了然。这比翻审计日志快，也比凭记忆靠谱。日常可以挂在定时任务里，每天导一份，保留最近若干份，磁盘占用可以忽略不计。

最后一个技巧跟验证有关。很多人改完参数只做一次startup就收工，但真正的风险在“下次冷启动”——当前实例可能还带着动态调整的余量，冷启动才会暴露参数文件的真实状态。所以变更之后至少做一次完整的shutdown immediate加startup，并且用show parameter spfile确认走的是 spfile 而不是残留的 pfile。如果条件允许，再模拟一次异常关闭（shutdown abort）后启动，看实例能不能正常做崩溃恢复，这一步能提前发现重做日志和 undo 相关的隐患。

从那以后我每次动sga_max_size之前，都会强制走一遍导出 pfile、打包 dbs、核对物理内存这三步，哪怕只是把 396M 改成 400M。吃过一次起不来的亏就知道，那几分钟的准备时间，换的是不用在半夜盯着ORA-27102猜是内核参数还是大页数量。希望帮到你。

本文还有配套的精品资源，点击获取