先检查show parameter spfile是否为空或spfile路径是否存在，若spfile参数过大导致ora-27102/ora-04031，则用create pfile from spfile导出并调小sga_max_size等值，再startup pfile启动后重建spfile。
oracle数据库因共享内存设置不当无法启动，本质是sga请求超出了操作系统能分配的共享内存上限。修复核心不是“改回原值”，而是绕过损坏的spfile，用pfile临时启动，再重建spfile。
ORA-27102 / ORA-04031 报错时怎么快速确认是SPFILE参数问题
看到 ORA-27102: out of memory 或 ORA-04031: unable to allocate ... shared pool，先别急着改参数。直接检查当前实例是否在用SPFILE：
- 执行
show parameter spfile—— 如果返回空值，说明没加载SPFILE，可能根本没找到它 - 去默认路径找文件：
$ORACLE_HOME/dbs/spfile$ORACLE_SID.ora（Linux）或%ORACLE_HOME%\database\spfile%ORACLE_SID%.ora（Windows） - 如果SPFILE存在但启动失败，大概率是里面某个参数（如
sga_max_size、memory_target）设得太大，超出了系统限制
没有initSID.ora怎么办：从SPFILE生成PFILE的实操路径
很多环境根本没有文本初始化文件（initSID.ora），但SPFILE还在。这时必须从SPFILE导出可编辑的PFILE：
- 用另一个正常运行的Oracle实例（同版本），或本机已启动的其他实例，执行：
create pfile='/tmp/initorcl.ora' from spfile; - 如果连其他实例都没有，且当前实例连不上，就只能靠备份或重装——但多数情况下，SPFILE本身没损坏，只是参数错，所以导出后手动编辑即可
- 导出的PFILE里会包含所有显式设置的参数，重点检查：
sga_max_size、sga_target、memory_target、shared_pool_size，把它们调低到安全值（比如先设为512M）
Linux下/dev/shm不足导致ORA-00845的硬性修复步骤
ORA-00845: MEMORY_TARGET not supported on this system 不是Oracle配置错了，是Linux没给够共享内存空间：
- 运行
df -h | grep shm，看/dev/shm当前大小 —— 如果小于sga_max_size，就必须扩容 - 临时生效：
sudo mount -o remount,size=2G /dev/shm - 永久生效：编辑
/etc/fstab，加一行：tmpfs /dev/shm tmpfs defaults,size=2G 0 0，然后sudo mount -o remount /dev/shm - 注意：
size值必须 ≥sga_max_size（单位一致），否则重启后仍报错
kernel.shmall 设置过小引发ORA-27102的验证与调整
kernel.shmall 是系统级共享内存页总数，单位是“页”，不是字节。设小了会导致即使物理内存充足，Oracle也申请不到连续页：
- 查当前值：
cat /proc/sys/kernel/shmall - 计算所需值：假设你设了
sga_max_size=8G，Linux页大小通常是4096（用getconf PAGE_SIZE确认），那么shmall ≥ 8*1024*1024*1024 / 4096 = 2097152 - 临时调大：
sudo sysctl -w kernel.shmall=4194304 - 永久生效：写入
/etc/sysctl.conf，再sysctl -p - 这个值不是越大越好，要留余量给其他进程和OS自身使用
真正容易被忽略的是：sga_max_size 和 memory_target 的数值必须同时满足操作系统内核限制（shmmax、shmall、/dev/shm 大小）和物理内存余量。光改Oracle参数没用，三者缺一不可。
