Oracle改SGA起不来：spfile/pfile与ORA-01078恢复指南

简介面向 Oracle 数据库运维与开发人员的应急排错文档聚焦调整 SGA 参数后实例无法正常启动这一典型故障提供从故障定位到参数恢复的处理思路适合初中级 DBA 和需要处理数据库启动异常的技术人员参考。压缩包共 1 个 docx 文件约 14KB以实操命令、步骤说明和启动结果记录为主便于随查随用。内容围绕 Linux 环境下 PFILE 与 SPFILE 的关系展开说明 SGA 参数设置不当可能造成内存分配错误与启动失败并给出三类恢复路径用 PFILE 应急启动实例、由 PFILE 重建 SPFILE、直接修正 PFILE 中的错误 SGA 参数同时强调调整前备份 SPFILE 及 dbs 目录文件附有 startup、create spfile、show parameter 等关键命令和参数查看结果帮助读者判断问题是否出在 spfile掌握参数回退、备份还原与启动验证方法并提醒调整后测试实例启动与性能表现。已有 328 人学习可作为 Oracle 内存参数调整故障的速查手册。1. 改完 SGA 起不来先别急着重装这套启动链还有救凌晨改完内存参数敲下 startup屏幕只回了一行 ORA-01078实例卡在 nomount 阶段不动了——这种 oracle 改 sga 异常八成不是数据坏了而是参数文件里两个内存值没配对或者实例压根读错了参数文件。SGA 从 396M 调到 3G看着只是改个数字实际牵动 spfile、pfile、/dev/shm、内核共享内存段和启动链五个环节哪一环没对齐数据库就停在半路。新手第一反应是重装老手知道先去 $ORACLE_HOME/dbs 看一眼再翻出 $ORACLE_BASE/admin/$ORACLE_SID/pfile 下那个带时间戳的 init.ora。这篇记录写给在 Linux 上管单实例、手上有 SYSDBA、刚动过 sga_max_size 或 sga_target 的人按现场顺序把版本、路径、命令、报错和恢复过程走一遍。2. 动手前的环境清点Linux 内存、/dev/shm 和 $ORACLE_HOME/dbs 三件套改内存参数之前先把环境摸清楚比改完再救便宜太多。这一章不看代码逻辑只看现场实例是什么版本、物理内存还剩多少、参数文件到底放在哪、当前实例吃的是 spfile 还是 pfile。把这四件事确认完后面无论改参数还是恢复都能少走一半弯路。我见过太多人上来就 ALTER SYSTEM改完才发现动的是另一台机器上的另一个实例。2.1 先把版本与内存基础信息核对清楚Oracle 的参数文件机制从 9i 到 19c 基本没变但路径和默认行为有代差。10g 时代告警日志在$ORACLE_BASE/admin/$ORACLE_SID/bdump11g 之后挪到diag/rdbms下Linux 的 spfile 在$ORACLE_HOME/dbsWindows 在%ORACLE_HOME%\database所以你在 Windows 上show parameter spfile看到的是带反斜杠的**DATABASE\SPFILEORCL.ORALinux 上则是完整路径。迁移库、换平台、克隆环境时这个差异经常让人以为 spfile 丢了。先把 shell 环境定死所有后续命令都基于它# 三个变量必须在同一个 shell 里 export否则 sqlplus 连的是别的实例 export ORACLE_SIDorcl export ORACLE_HOME/u01/app/oracle/product/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH # 确认当前身份和实例状态能不能看到 pmon决定了后面是恢复还是重装 whoami echo $ORACLE_SID $ORACLE_HOME ps -ef | grep pmon | grep -v grepORACLE_SID写错是 ORA-01078 最常见的原因没有之一。同一台机器上跑两三个实例时切窗口忘了 exportsqlplus 会老老实实去连另一个库改的参数自然落到别人身上。ps -ef | grep pmon这一行是判断实例死活的快捷方式有ora_pmon_orcl进程说明实例还在内存里只是可能没打开一个都没有说明实例已经彻底关了此时只能从参数文件重新拉起。接着看内存和共享内存# 物理内存、共享内存段、/dev/shm 三处都要看 free -m ipcs -lm df -h /dev/shmfree -m看的是物理内存余量SGA 一般不超过物理内存的 60%70%同一台机器上还跑着别的服务时要再往下压。ipcs -lm输出里的max seg size是单个共享内存段的上限SGA 超过它就会在启动时报 ORA-27102。/dev/shm是 AMMmemory_target的落脚点容器里默认只给 64M宿主机上通常是一半内存这一项不够会直接抛 ORA-00845。三处数据凑齐才谈得上“这个 SGA 值设得合不合理”。2.2 找到真正在用的 spfile 和 pfileOracle 启动时找参数文件是有顺序的Linux 下大致是$ORACLE_HOME/dbs/spfile$ORACLE_SID.ora→$ORACLE_HOME/dbs/init$ORACLE_SID.ora→ 编译时的默认位置。也就是说只要 dbs 目录下有 spfile实例就不会去看 pfile除非你在 startup 时显式指定。# dbs 目录里到底躺了几个参数文件一眼看全 ls -l $ORACLE_HOME/dbs/ | grep -E spfile|init # pfile 副本通常在 ORACLE_BASE 的管理目录下带建库时间戳 ls -l $ORACLE_BASE/admin/$ORACLE_SID/pfile/第二条命令列出来的init.ora.8282011115435这类文件是建库CREATE DATABASE时用当前参数生成的文本副本文件名后缀是生成时间。它的价值在于spfile 是二进制改坏了打不开也读不了pfile 是纯文本vi 就能看、能改、能对比。恢复现场时这份带时间戳的副本往往就是唯一一份“还记得当初参数长什么样”的证据。实例还活着的时候用 SQL 确认它在用哪个文件-- 值非空说明吃的是 spfile为空说明吃的是 pfile SHOW PARAMETER spfile; -- 顺带看一眼内存参数现状改之前先记下来 SHOW PARAMETER sga;SHOW PARAMETER spfile返回空值这一条信息量很大说明实例是从 pfile 起来的你在 SQL 里改的参数只落在内存里重启就没了。这种情况要么是 dbs 下 spfile 被删了要么是启动时用了startup pfile...要么是初始化脚本里写死了 pfile 路径。确认清楚再动手不然改半天发现改的是空气。2.3 sga_max_size 与 sga_target 的配对规则两个参数名字像作用完全不同这是最容易配错的地方参数类型能否在线生效作用sga_max_sizebig integer需重启实例生命周期内 SGA 的硬上限sga_targetbig integer可在上限内动态调整ASMM 自动管理的目标值memory_targetbig integer需重启AMM 总内存目标与 sga_target 互斥db_block_sizeinteger不可改建库时定死碰它等于重建规则不复杂但踩的人多走 ASMM 就设 sga_max_size 和 sga_target且 sga_target 不能大于 sga_max_size走 AMM 就设 memory_target 和 memory_max_target此时 sga_target、pga_aggregate_target 要归零。两套混着设启动时就会撞上 ORA-00823sga_target 大于 sga_max_size或 ORA-00844 这类参数冲突报错。常见做法是只改 sga_target 而不动 sga_max_size结果新值超过上限实例直接起不来。我一般要求两个值成对出现sga_max_size 只增不减先改上限再改目标值中间隔一次重启。这样即使目标值设错上限还在改回去的成本很低。3. 改 SGA 的标准动作SCOPE 参数、重启顺序和 OS 侧对齐参数配对搞清楚了才轮到手上有准头地改。这一章把 ALTER SYSTEM 的三个 SCOPE、重启时的观察点、以及操作系统侧共享内存段的对齐讲透。改内存这件事真正难的不是敲命令而是知道哪一步只影响内存、哪一步会写进文件、哪一步必须重启才看得见效果。3.1 ALTER SYSTEM 的三个 SCOPE 该怎么选SCOPE 决定这次修改落到哪里选错了就是“改了没生效”和“改错了回不去”两个极端-- 试探性修改只改内存不写文件重启自动回滚 ALTER SYSTEM SET sga_target 3G SCOPEMEMORY; -- 正式修改只写 spfile重启后生效适合静态参数 ALTER SYSTEM SET sga_max_size 3G SCOPESPFILE; ALTER SYSTEM SET sga_target 3G SCOPESPFILE;SCOPEMEMORY是最被低估的选项。拿不准新值会不会让实例崩先用它试一把能起来说明值合理起不来重启就恢复原样等于给自己留了后悔药。SCOPESPFILE是改静态参数唯一的选择sga_max_size 这类必须重启才生效的参数写了 MEMORY 会直接报错。SCOPEBOTH是动态参数的默认行为内存和文件一起改适合 sga_target 这种能在线伸缩的值。要注意一点SCOPESPFILE只写文件当前实例的内存里还是旧值SHOW PARAMETER看到的也可能是旧值别以为没改成功。判断标准是重启之后再查。改之前先把 spfile 备份一份成本几秒钟# 整个 dbs 目录打包比只备份 spfile 更保险 tar czf /backup/oracle_dbs_$(date %Y%m%d%H%M).tar.gz $ORACLE_HOME/dbs/这个动作在后面的恢复里是第三条路spfile 被改坏、pfile 也找不到时把 dbs 目录解回去实例立刻恢复原状。备份时带上时间戳别覆盖上一次的出问题时能往前翻两三个版本。3.2 重启顺序shutdown immediate 到 startup 的观察点改完 spfile 必须重启才生效而重启本身就是一次验证。顺序和观察点如下-- 干净关闭别用 abortabort 之后实例恢复会让判断变复杂 SHUTDOWN IMMEDIATE; -- 正常启动观察 SGA 分配值是否与设置一致 STARTUP;SHUTDOWN IMMEDIATE之后如果卡住不动先去看告警日志尾部通常是某个会话在回滚大事务不是参数问题。启动阶段真正要盯的是输出里的Total System Global Area这一行它等于 sga_max_size 对应的字节数612368384 bytes 约等于 584M415236096 bytes 约等于 396M。这个数字和你设的值对不上说明实例读的不是你以为的那个参数文件。启动到 mount 阶段就停住报 ORA-01078 或 ORA-00823说明参数文件本身有问题数据文件还没被碰过此时最安全直接用 pfile 兜底即可。启动能到 open 但业务连上来报 ORA-04031说明 SGA 总量够但 shared pool 分小了属于参数分配问题不是启动链问题两者别混为一谈。如果只是想确认新参数能不能用不想影响生产可以在 mount 阶段就停-- 只到 mount能验证参数文件是否可解析、SGA 是否能分配 STARTUP MOUNT; SHOW PARAMETER sga;mount 成功基本就说明内存参数没问题剩下的是数据文件和控制文件的一致性跟 SGA 无关。3.3 内存参数和内核共享内存段的对齐数据库层参数改对了操作系统不给内存一样起不来。SGA 在 Linux 上落地为一块共享内存段受内核参数约束# 单段上限SGA 必须小于它 cat /proc/sys/kernel/shmmax # 系统级共享内存总量上限同时跑多个实例时要一起算 cat /proc/sys/kernel/shmall ipcs -m老系统上shmmax默认只有物理内存的一半甚至更小SGA 一调大就报 ORA-27102: out of memory。改法是写进/etc/sysctl.conf然后sysctl -p生效。RHEL 7 以后默认值通常足够大反而是容器环境里的/dev/shm更容易出问题df -h /dev/shm只有 64M 的话AMM 启动必报 ORA-00845要么调大挂载参数要么退回 ASMM。还有一处容易漏同一台机器上跑两个实例各自的 SGA 加起来不能超过物理内存ipcs -m里能看到每块共享内存段的实际大小和属主。改完参数重启前先算一遍总和比启动失败后再回退省事得多。4. 启动异常应急恢复用 pfile 把实例拉起来的完整流程前面都是预防这一章是救火。场景很典型改完 SGAstartup 报错实例起不来业务在等。这时候要做的不是分析 spfile 里哪一位错了而是先用文本参数文件把实例拉起来让业务先通再回头修 spfile。整个过程十分钟以内能走完。4.1 startup pfile 的执行与输出逐行读法第一步永远是确认当前 shell 指向的是故障实例然后直接指定 pfile 路径启动# 环境变量必须在这一个 shell 里同时生效 export ORACLE_SIDorcl export ORACLE_HOME/u01/app/oracle/product/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH # 登录注意是 / as sysdba不要在此时连监听 sqlplus / as sysdba-- 路径写全别用相对路径单引号里不能有 shell 变量 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 例程已经启动说明参数文件能被解析、内存能分配spfile 这一环的问题被绕过了Total System Global Area 612368384 bytes约 584M是这份 pfile 里 sga_max_size 对应的实际值数据库装载完毕说明控制文件没问题数据库已经打开说明数据文件和 redo 都正常。四行连起来等于把故障范围缩小到“spfile 里的内存参数写坏了”这一件事上跟数据无关可以放心修。提示路径里的oracle_install、SID是模板占位实际要用$ORACLE_BASE/admin/$ORACLE_SID/pfile/下的真实文件名后缀那串数字每次建库都不同。4.2 create spfile from pfile 重建参数文件实例起来之后用这份可用的 pfile 反向生成一个新的 spfile把坏掉的二进制文件替换掉-- 显式指定输出路径避免生成到默认位置之外 CREATE SPFILE/u01/app/oracle/product/dbhome_1/dbs/spfileorcl.ora FROM PFILE/u01/app/oracle/admin/orcl/pfile/init.ora.8282011115435;这条命令的逻辑是读文本参数文件按 Oracle 内部格式写出二进制 spfile默认写到$ORACLE_HOME/dbs/spfile$ORACLE_SID.ora。显式写路径的好处是不会覆盖错文件尤其是在 dbs 目录下已经有多个 spfile 残留的时候。注意单引号里不能写$ORACLE_HOME这种 shell 变量SQL 不认写了会报文件不存在。执行成功返回“文件已创建”。此时当前实例还在用 pfile 跑着新 spfile 要下次启动才接管SHUTDOWN IMMEDIATE; STARTUP; SHOW PARAMETER spfile;SHOW PARAMETER spfile这次应该返回完整路径说明实例已经切回 spfile。再看内存SHOW PARAMETER sga;返回sga_max_size 396M、sga_target 396M跟 pfile 里的值一致也跟启动输出里的 415236096 bytes约 396M对得上。这一步对得上参数文件这条链就算修好了。4.3 从 mount 到 open确认 spfile 已经接管稳妥一点的做法是分两段启动中间插一次参数确认-- 先到 mount验证 spfile 解析正常、SGA 能分配 STARTUP MOUNT; SHOW PARAMETER spfile; SHOW PARAMETER sga; -- 确认无误再打开 ALTER DATABASE OPEN;分两段的价值在于如果 spfile 里还有别的坏参数会停在 mount 阶段报错此时数据文件未被写入回退成本极低。直接STARTUP一路冲过去万一在 open 阶段崩回滚和排查都更麻烦。如果重建出来的 spfile 参数仍然不对说明 pfile 本身也被改过那就回到第二条路直接vi编辑init.ora.8282011115435把 sga_max_size、sga_target 改成成对且合理的值保存后再CREATE SPFILE ... FROM PFILE...重建一次。文本文件改错了最多是启动失败不会像二进制 spfile 那样连读都读不出来。5. 避坑与排查SGA 改完起不来的五个血泪现场下面五条是这类故障里出现频率最高的按“现象 → 原因 → 解决”记遇到了直接对号入座不用从头分析。5.1 现象startup 报 ORA-01078 加 LRM-00109原因实例找不到参数文件。要么ORACLE_SID没 export 对要么 dbs 下的 spfile 被误删或改名要么启动脚本里 pfile 路径写错了一个字符。解决先echo $ORACLE_SID和ls -l $ORACLE_HOME/dbs/两件事各做一遍确认 SID 和文件都在。文件确实没了就用STARTUP PFILE...从管理目录下的 init.ora 副本拉起再用CREATE SPFILE重建。别急着重装数据文件跟参数文件是两回事。5.2 现象ORA-00823sga_target 大于 sga_max_size原因两个参数只改了一个。常见于只执行了ALTER SYSTEM SET sga_target3G SCOPESPFILE忘了 sga_max_size 还停在 396M。解决用 pfile 启动后在文本文件里把 sga_max_size 调到不小于 sga_target或者把 sga_target 降回上限以内重建 spfile。以后改这两个值一律成对写中间隔一次重启。5.3 现象ORA-00845MEMORY_TARGET not supported on this system原因用了 AMM但/dev/shm空间小于 memory_target。容器环境默认 64M宿主机上一般是一半物理内存。解决df -h /dev/shm确认大小能改挂载就改/etc/fstab里的 size 参数再 remount改不了就把 memory_target 归零退回 sga_max_size sga_target 的 ASMM 模式这条路对共享内存的要求低得多。5.4 现象参数改了重启后SHOW PARAMETER还是旧值原因三种可能——用了SCOPEMEMORY没写文件改的是 pfile 而实例吃的是 spfile机器上有多个ORACLE_HOMEsqlplus 连的是另一套。解决依次执行SHOW PARAMETER spfile确认当前参数文件路径、which sqlplus确认二进制来源、ALTER SYSTEM SET ... SCOPESPFILE重改一次再重启。三件事排完基本都能定位。5.5 现象ORA-27102 out of memory或启动到一半被系统 kill原因SGA 超过物理内存或内核shmmax上限也可能是同机其他实例已经占掉大块共享内存。解决ipcs -m看当前共享内存段总和cat /proc/sys/kernel/shmmax看单段上限把 SGA 降到物理内存 60% 左右必要时调大内核参数并sysctl -p。这类报错跟数据无关降参数重启即可恢复。6. 验证跑通三条 SQL 加两步重启确认参数真的落地修好不算完确认它“下次还能起来”才算完。我习惯用三步验证全部通过才把工单关掉。第一步参数层面对齐-- 参数值、是否可动态修改、当前生效的 spfile 路径一次看全 SELECT name, value, issys_modifiable FROM v$parameter WHERE name IN (spfile,sga_max_size,sga_target,memory_target); -- 实例实际能用的最大 SGA和参数值必须一致 SELECT name, bytes/1024/1024 AS mb FROM v$sgainfo WHERE name Maximum SGA Size;第二步操作系统层面对齐# 共享内存段大小应该和 SGA 总量接近 ipcs -m # 告警日志尾部不应有 ORA- 开头的内存类报错 tail -50 $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/alert_orcl.log第三步最关键连续两次干净重启确认参数不回退。# 两次重启都过说明 spfile 真的写进去了不是内存里的临时值 sqlplus -s / as sysdba EOF shutdown immediate startup show parameter sga_max_size shutdown immediate startup show parameter sga_max_size EOF一次重启可能骗人——实例可能还在用 pfile 或内存里的旧值。两次之后值仍然一致才说明 spfile 被正确读取。这一步花两分钟能省掉下一次凌晨被叫起来的时间。从那以后我每次改 SGA都强制走一遍固定流程先把$ORACLE_HOME/dbs整个目录 tar 一份带时间戳的备份SHOW PARAMETER spfile记下当前路径两个内存参数成对写进SCOPESPFILE重启后连查两次。翻车过的人都懂参数文件这东西后悔药只能提前准备。希望帮到你。本文还有配套的精品资源点击获取