CentOS 7安装Oracle 11g全指南：从环境准备到故障排查-开发者社区

这几年只要一提到“CentOS 7 下安装使用 Oracle 11g”，我就想起自己第一次在一台生产服务器上装这套组合时的场景。网上老教程一大堆，但很多都是针对 RHEL 5/6 年代的，直接照搬到 CentOS 7 上，十有八九会卡在依赖包缺失、内核参数没配、runInstaller 秒退这类问题上。官方支持列表里其实也没有“CentOS 7”这个组合的大名，但社区里到处都在用它跑老项目、跑测试环境，所以这事的复杂度多半不是 Oracle 本身，而是操作系统那一层。

这篇文章不是复读官方文档，而是把我在实际机器上从零装到能用的完整过程拿出来讲一遍：版本怎么选、依赖包怎么补、响应文件怎么填、监听和建库怎么做、以及最容易让人想砸键盘的那几个报错到底怎么排查。适合两类人看：一类是第一次在 CentOS 7 上装 11g 的运维同学，另一类是手头有老项目、被“Oracle 迁移”这事推着走的开发。我尽量把每一步的原因也讲清楚，不光是给命令。

1. 装 11g 前必须先想清楚的几件事：版本、兼容性与磁盘规划

1.1 这一对组合最大的麻烦是系统识别问题，不是 Oracle 本身

CentOS 7 的内核是 3.10，glibc 是 2.17，Oracle 11g 的安装程序本身只是个很老的工具，它对操作系统的识别主要看/etc/redhat-release和内核版本这类信息。11g 早期版本（尤其是 11.2.0.1）在 CentOS 7 上跑 runInstaller 时，经常直接卡在“操作系统版本检查不通过”这一步，要么提示必须是 redhat-3、redhat-4、redhat-5、redhat-6，要么虽然能往后走，却在后续各种报错，比如兼容库崩溃、编译 mod 失败等等。

相比之下，11.2.0.4 是 11g 的最终补丁版本，对较新的内核和 glibc 的兼容性好得多。虽然它官方认证的是 RHEL 6/7 系列，但 CentOS 7 作为 RHEL 的兼容发行版，在实践中跑 11.2.0.4 基本是社区验证过的主流路线。所以如果你要在 CentOS 7 上装 11g，我的建议很直接：不要纠结，直接选 linux x86-64 的 11.2.0.4 安装包。除非你手上有极其特殊的项目约束必须用 11.2.0.1，否则不要给自己找罪受。

另一个需要先确认的是架构。现在装 11g 基本都是 64 位系统，你可以在服务器上跑一个uname -m确认是 x86_64。如果手头还是 32 位系统，后面能找到的安装包和补丁都非常少，属于不推荐碰的路线。

1.2 磁盘和内存规划：装到一半空间不够才是真绝望

Oracle 的安装包解压后体积膨胀很厉害，这个很多人第一次容易预估错。我按自己的踩坑经验给个参考：安装包 zip 本身约 1.2GB，解压出来的 database 目录大约有 5~6GB，ORACLE_HOME 安装完成后还要占掉 4~5GB，这还没算数据文件、控制文件、在线日志和归档目录。所以如果你打算把数据库放进/u01下，这个分区最好直接规划成 30GB 以上，保守一点给 50GB 也不算浪费。很多人在装到一半弹出“磁盘空间不足”时才发现根分区只有 10GB，那就非常被动了。

内存方面，Oracle 11g 的最低要求是 1GB，但实际跑起来，2GB 的机器也只是勉强能开机，做个测试都要小心翼翼。我个人的经验是一台干净的虚拟机至少给 2 核 4GB，内存分配按 11g 的经典建议：内存 1~2GB 时 swap 设为内存的 1.5~2 倍，内存 2GB 以上时 swap 至少和内存一样大，或者按官方表格调整。如果你手头机器紧张，至少保证 swap 不能缺，否则后面启动实例跑几个查询就 OOM。

1.3 账号与目录结构：先把安装姿势摆正

安装 Oracle 不能直接用 root 跑，官方也明确要求用普通用户来做。业界惯例是创建一个叫oracle的用户，并把它归到oinstall和dba两个组里。目录结构上，通常把基础目录命名为/u01/app/oracle，这样后面 ORACLE_HOME 就是/u01/app/oracle/product/11.2.0/dbhome_1，ORACLE_BASE 是/u01/app/oracle。这套命名虽然看起来冗长，但它是官方文档和绝大多数教程的默认路径，用它能省掉不少因为路径不匹配带来的参数问题。

我在实际安装中还养成一个习惯：把安装包解压到一个独立的地方，比如/home/oracle/install，而不要解压到/tmp。因为/tmp在重启后可能被清掉，而且很多服务器/tmp分区很小，解压到一半直接撑爆。这些都是小细节，但往往就是这些小细节决定了一次安装能不能一把过。

2. 环境准备的关键环节：依赖包、内核参数与限制文件一个都不能少

2.1 依赖包清单：照着装，别自己“精简”

Oracle 11g 对系统库的依赖非常细碎，少一个libaio、少一个ksh，安装过程都会花式报错。CentOS 7 的默认源里大部分包都有，我一般直接一条命令装齐：

yum -y install binutils compat-libcap1 compat-libstdc++-33 \ elfutils-libelf elfutils-libelf-devel gcc gcc-c++ \ glibc glibc-common glibc-devel glibc-headers \ ksh libaio libaio-devel libgcc libstdc++ libstdc++-devel \ libXp libXtst make sysstat unixODBC unixODBC-devel \ libX11 libXau libXi libXext libXt

其中compat-libstdc++-33是网上问得最多的一个包，CentOS 7 的默认 base 源里其实是有的，只是很多教程提到它时总让人有一种“它很难装”的错觉。如果在某些精简源里确实找不到，可以用yum provides去查一下哪个源提供，或者先跳过——只要 64 位包齐了，11.2.0.4 的安装检查往往也能过。

很多人拿到老教程，会看到一长串 i686 结尾的 32 位兼容库。这主要是 RHEL 5/6 时代的安装器在图形检查时会强制要求的。CentOS 7 上如果纯粹跑静默安装，我实测是不需要故意额外装那一整套 32 位库的，把上面列表里的 64 位包装好就够了。当然，如果你的运行环境里还有 32 位应用需要一起跑，那另当别论。

2.2 内核参数：每一个值的背后都有原因

内核参数是安装 11g 的老生常谈，但很多人只是照着抄，改完了也不知道为什么要改。我挑几个重点说：

kernel.shmmax：单块共享内存段的最大字节数。Oracle 的 SGA 就是靠共享内存实现的，这个值如果小于你要给 SGA 分配的大小，实例启动直接失败。常见设置是把物理内存的 70%~80% 作为 shmmax。比如 4GB 内存的虚拟机，我一般设为 3212836864（约 3GB）。
kernel.shmall：共享内存页总数。可以简单理解成“总共允许多少共享内存”，通常设为略大于 shmmax 除以页大小（一页一般是 4096 字节）。
kernel.sem：四个数字依次是信号量参数，11g 对并发进程和信号量的需求很高，不调大，后面起多进程应用时容易报资源不足。
fs.aio-max-nr：异步 IO 请求上限，Oracle 的异步 IO 特性靠它，默认 65536 偏小，一般要调到 1048576。

我常用的完整配置如下：

# /etc/sysctl.conf kernel.sem = 250 320000 100 128 kernel.shmall = 1073741824 kernel.shmmax = 3212836864 kernel.shmmni = 4096 fs.aio-max-nr = 1048576 fs.file-max = 6815744 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576

写完以后执行sysctl -p让它生效，再用sysctl -a | grep kernel.sem这类命令确认一下。很多人改完不验证，等到最后实例起不来才回头查，浪费时间。

2.3 文件描述符和栈大小限制：不配置好，安装通过也白扯

Oracle 用户作为一个普通用户，默认的文件描述符限制、进程数限制往往不够数据库服务器使用。这部分配置写在/etc/security/limits.conf里：

oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768

nofile是文件描述符数量，数据库要同时打开大量数据文件和日志文件，不调大很容易在运行中出现“too many open files”。nproc是进程数限制，11g 的进程模型会生成很多后台进程。stack是栈大小，官方要求 oracle 用户栈上限不小于 10240KB。改完之后必须重新登录 oracle 用户才会生效，这又是一个常见坑。

另外，如果你的系统启用了大页内存（HugePages），还要考虑给 oracle 用户加 memlock 限制：

oracle soft memlock unlimited oracle hard memlock unlimited

没有这一条，后面启动实例时极容易碰到 ORA-27125，这个错误我在第 5 章会专门展开。

2.4 创建用户、目录，并配置好登录环境

用户和目录的创建命令比较固定，但要注意顺序：

groupadd oinstall groupadd dba useradd -g oinstall -G dba oracle mkdir -p /u01/app/oracle chown -R oracle:oinstall /u01 chmod -R 775 /u01

安装文件解压后，建议连同数据库软件目录一起chown -R oracle:oinstall，避免安装过程中因为文件 owner 问题读不了。我见过有人把安装包解压到 root 的主目录下，切换到 oracle 后连解压目录都进不去，这种低级问题最不值得。

环境变量在安装前可以先配好，也可以在装完软件后再配。我习惯先配，因为静默安装过程中有些脚本会读取 ORACLE_HOME 和 ORACLE_BASE。配置写在/home/oracle/.bash_profile：

export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 export ORACLE_SID=orcl export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH export NLS_LANG=AMERICAN_AMERICA.AL32UTF8

注意这里NLS_LANG的字符集要和后面建库时选定的字符集一致，否则客户端连接后显示中文乱码的概率极高。很多做国内业务的人喜欢用 ZHS16GBK，这个要看项目实际的数据编码，没有绝对的标准答案，但环境变量和数据库字符集必须对应上。

3. 响应文件驱动的静默安装：步骤、参数说明与中途退出排查

3.1 为什么推荐静默安装而不是图形界面

很多老教程会让你用图形方式跑 runInstaller，但 CentOS 7 服务器往往没有桌面环境，就算装了 X 转发，网络不好的时候画界面也是一卡一卡。静默安装只需要准备一个响应文件，把参数都填好，程序会按照响应文件的内容一路执行到底，整个过程输出也能重定向到日志里，非常适合作业化、批量化的部署。

如果你确实想用图形界面，也不是不行，前提是服务器装了 X Window，或者你能通过 X11 转发的方式打开远端图形窗口。但对大多数无桌面服务器来说，静默安装才是更合情合理的主流方案。我第一次装的时候就是因为不想折腾图形界面而选择静默，结果一路顺利，反而比照着图形界面截图点来点去省心。

3.2 db_install.rsp 的关键参数怎么填

Oracle 11g 的安装包解压后，响应文件模板在database/response/目录下，常用的安装软件响应文件是db_install.rsp。建议先复制一份到/home/oracle/下再修改，因为模板文件 owner 可能不是 oracle，直接改容易遇到权限问题。

需要重点关注的参数如下：

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v11_2_0 oracle.install.option=INSTALL_DB_SWONLY ORACLE_HOSTNAME=your-hostname UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/u01/app/oraInventory SELECTED_LANGUAGES=en,zh_CN ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 ORACLE_BASE=/u01/app/oracle oracle.install.db.InstallEdition=EE oracle.install.db.DBA_GROUP=dba oracle.install.db.OPER_GROUP=dba oracle.install.db.CLUSTER_NODES= oracle.install.db.isRACInstall=false oracle.install.db.isRACOneInstall=false DECLINE_SECURITY_UPDATES=true SECURITY_UPDATES_VIA_MYORACLESUPPORT=false

oracle.install.option=INSTALL_DB_SWONLY表示只装数据库软件，不建库，建库放到后面用 dbca 单独做。这样分步操作的好处是每一步的日志和验证都更清晰，也方便以后对同一套软件再建多个实例。DECLINE_SECURITY_UPDATES和SECURITY_UPDATES_VIA_MYORACLESUPPORT是拒绝在线安全更新，因为内网服务器通常连不上 Oracle 的更新服务，不设成 true 会在检查阶段一直报错。

3.3 安装指令与常见的“秒退”问题

确认好响应文件后，切到 oracle 用户，进入解压后的 database 目录，执行：

./runInstaller -silent -responseFile /home/oracle/db_install.rsp

如果一切正常，终端会一直输出安装进度，最后提示你以 root 身份去执行两个脚本。如果中途秒退，多半是响应文件路径不对、ORACLE_HOME 目录非空、或者某些必填参数缺了。这时别慌，先看日志：

tail -n 100 /u01/app/oraInventory/logs/installActions2024-xx-xx_xx-xx-xx.log

日志里会明确写出是哪个检查项失败、哪条配置不合法。最常见的几种：填写的 ORACLE_HOME 目录已经存在并且里面有旧文件；响应文件里主机名和实际不一致；或者前面依赖包没装全，导致安装器在“操作系统包检测”环节直接退出。遇到这类情况，修正对应问题后重跑即可，已经写入的安装残留一般不会影响第二次执行。

3.4 补跑 root.sh 和 orainstRoot.sh：漏一步都不算装完

静默安装结束时，终端会提示需要以 root 身份分别执行两个脚本。一个是orainstRoot.sh，它位于/u01/app/oraInventory，作用是设置 inventory 目录的所有者和组；另一个是root.sh，位于 ORACLE_HOME 下，作用是设置 oracle 二进制文件的 owner、setuid 等权限。

这两个脚本不跑，数据库软件虽然装了，但后面启动监听可能权限失败，sqlplus 连本实例也可能报各种奇奇怪怪的错误。我第一次就是忘了跑 root.sh，结果 oracle 用户连sqlplus / as sysdba都进不去，排查半天才反应过来。跑完脚本后正常会有几行输出，确认没有 ERROR 字样即可进入下一步。

4. 监听配置、建库与命令行启动的完整流程

4.1 用 netca 静默配好监听，再验证端口

数据库软件装完后，首先要配置监听器。监听是客户端连接数据库的“前门”，没它什么都连不上。静默安装不会自动配监听，你可以用数据库自带的 netca 工具来生成：

$ORACLE_HOME/bin/netca -silent -responsefile $ORACLE_HOME/network/response/netca.rsp

默认响应文件会创建一个名为 LISTENER 的监听器，监听端口 1521。执行完以后，用lsnrctl status查看监听状态。正常会显示监听处于运行中，端口为 1521。如果看到的是“连接失败”或“listener is not running”，那就要进一步检查端口是否被占用：

netstat -tlnp | grep 1521

CentOS 7 上比较多见的是 1521 端口没被占用，但防火墙没有放行这个端口，导致外部访问不通。这时候要么临时关掉 firewalld，要么更规范一点加规则：

firewall-cmd --permanent --add-port=1521/tcp firewall-cmd --reload

4.2 用 dbca 静默建库：字符集和密码是两大易错点

建库推荐用 dbca 的静默模式，不依赖图形界面。命令模板如下：

$ORACLE_HOME/bin/dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname orcl -sid orcl \ -characterSet AL32UTF8 \ -sysPassword <SYS密码> \ -systemPassword <SYSTEM密码> \ -emConfiguration NONE \ -memoryPercentage 40 \ -datafileDestination /u01/app/oracle/oradata \ -recoveryAreaDestination /u01/app/oracle/fast_recovery_area

General_Purpose.dbc是通用模板，对绝大多数场景都适用。字符集选择一定要慎重，一旦建库定了，后面再改字符集非常麻烦。国内环境里常见两种选择：ZHS16GBK和AL32UTF8。如果你的业务数据以中文为主、历史库也是 GBK，那优先 ZHS16GBK；如果未来有国际化需求或者想统一 UTF-8，那就 AL32UTF8。千万不要建库时选了 utf8，客户端环境变量却设成 gbk，两边不一致真能让人查一整天乱码问题。

-emConfiguration NONE表示不配置 Oracle Enterprise Manager。在这个轻量化部署场景下，EM 不是必需，关掉还能省一点内存和时间；以后要监控性能，直接用命令行和简单脚本就够了。

4.3 sqlplus 启动、关闭与连接测试的完整姿势

建库完成后，实例应该已经自动起来了。后续如果重启服务器，需要手动启动时，核心命令就三条：

lsnrctl start sqlplus / as sysdba startup

sqlplus / as sysdba用的是操作系统认证，oracle 用户无需密码即可登录 sysdba。注意执行 sqlplus 时必须在 oracle 用户环境下，同时 ORACLE_SID 要设对。如果发现lsnrctl或sqlplus命令找不到，说明 PATH 没配好，或者你还没有重新登录让.bash_profile生效。此时可以直接用完整路径：

/u01/app/oracle/product/11.2.0/dbhome_1/bin/sqlplus / as sysdba

实例启动成功后，可以在 sqlplus 里执行几条简单 SQL 验证数据库可用：

select name, open_mode from v$database; select tablespace_name from dba_tablespaces;

再回到操作系统层面，用lsnrctl status看监听状态，正常情况下输出中会有orcl这个服务名注册进去。如果你的客户端在另一台机器上，连接字符串里主机 IP、端口、服务名三者必须对得上，测试命令可以用：

sqlplus system/<密码>@//<服务器IP>:1521/orcl

能连上并且执行查询，这整套安装才算真正落地。

5. 启动阶段最容易遇到的三个错误：我的排查链路和修复过程

5.1 ORA-27125：共享内存段匹配问题，先查大页和 memlock

这个错误我在 CentOS 7 上加过好几次班。报错内容大致是：

ORA-27125: unable to create shared memory segment Linux-x86_64 Error: 1: Operation not permitted

第一次遇到时，我第一反应是内核参数 shmmax 没设好，反复调大调小都没用。后来查资料才发现问题经常出在系统大页内存配置和 oracle 用户的 memlock 限制上。CentOS 7 默认透明大页是开启状态，如果数据库优先使用共享内存大页，而 oracle 用户没有 memlock unlimited，那么即使系统内存充足，内核也不允许创建这么大段的共享内存。

排查链路是这样的：

先查看/proc/meminfo里的HugePages_Total和HugePages_Free，如果 HugePages_Total 大于 0，说明系统有被配置的大页；
确认/etc/security/limits.conf里有没有给 oracle 用户设 memlock；
检查/dev/shm的大小，如果/dev/shm很小而 SGA 分配得很大，也会出现在共享内存上创建失败的报错。

修复方案就是在 limits.conf 中为 oracle 用户增加 memlock unlimited 并重新登录，或者调整实例的 SGA 大小让它不超出共享内存实际可用容量。如果你是虚拟机测试环境，更省事的做法是直接把启动脚本里的 SGA 调小，先保证实例能起，再逐步往大了试。

5.2 ORA-12514：监听不认服务，别急着查配置，先看注册信息

ORA-12514 的完整报错是 “listener does not currently know of service requested in connect descriptor”。本质上就是客户端连到监听器，但监听器并不知道你要连的那个服务名。

它常见的触发点有三个。第一，数据库实例根本没启动，服务当然不会注册上去；第二，实例启动了，但动态注册还没完成，刚 startup 时立刻去连接就容易报这个错，等几秒再连就好；第三，客户端用的连接串里服务名写错了，和监听器实际注册的服务名不一致。

我的排查习惯是先在服务器本地执行：

lsnrctl status

看输出里有没有类似Service "orcl" has 1 instance(s)这样的注册行。如果没有，到 sqlplus 里执行：

alter system register;

让它立即重新注册。如果还是没有，再去检查监听配置文件listener.ora里的主机地址配置，是不是只监听了某个指定的 IP 而不是全部地址。随后别忘了确认防火墙对 1521 端口是否放行，很多时候本地 lsnrctl status 正常，但跨机器访问就超时，问题就出在这一层。

5.3 sqlplus: command not found：多半不是没装，是环境变量丢了

sqlplus 命令找不到，是安装完成后最常见的“伪故障”。Oracle 都装了，命令也在$ORACLE_HOME/bin下，但你就是执行不了。原因往往只有一个：当前 shell 没有加载 oracle 的环境变量。

这里有个很多人忽略的细节：su oracle和su - oracle效果完全不同。su oracle保留了 root 的环境变量，不会加载 oracle 用户自己的.bash_profile；只有su - oracle才会模拟完整的登录过程，读取用户配置文件。如果你发现执行 sqlplus 报 command not found，先看一下自己是不是用了没有减号的 su。

另外，如果确认换了登录方式还是不行，就打开/home/oracle/.bash_profile再检查一遍 PATH 和环境变量格式有没有写错。这个文件修改后，要么重新登录，要么手动执行source ~/.bash_profile，马上就能用。

5.4 其他不该踩的坑：root.sh 权限问题、ORA-01078 和透明大页

除了上面三个典型问题，还有几个低频但值得记一笔的。

root.sh没执行时，表现为 oracle 二进制文件权限不对，启动实例可能有“permission denied”，甚至sqlplus / as sysdba直接退出。遇到这种问题，回去确认 root.sh 的执行输出即可。

ORA-01078 “failure in processing system parameters”则多半是参数文件不匹配，比如 SPFILE 引用了不存在的路径，或者 pfile 里某参数值过大。比如 SGA 大小超过了前面 shmmax 的设置，实例就无法分配内存。解决思路是先用startup pfile=...限制参数启动，再逐步调整、生成新的 spfile。

透明大页（Transparent Huge Pages）这种问题更隐蔽，不会直接让你安装失败，但会让数据库运行时的性能忽高忽低，尤其某些高并发语句容易有莫名的长等待。Oracle 官方建议关闭透明大页，CentOS 7 上可以通过修改内核启动参数或运行时设置来关闭。这个属于安装后优化层面，如果只是搭个学习环境可以先不管，生产环境建议认真处理。

6. 起来之后别急着走：日常维护和备份的实操细节

6.1 开机自启：用 systemd 管理监听和实例

数据库装好不是终点，服务器一重启，一切都要能自己回来才是可用的状态。Oracle 11g 传统的自启方式是修改/etc/oratab，把实例条目最后一栏改为 Y：

orcl:/u01/app/oracle/product/11.2.0/dbhome_1:Y

然后再写一个/etc/init.d/dbora脚本，用 service 的方式拉起监听和实例。CentOS 7 虽然还兼容 sysvinit 脚本，但我更推荐直接用 systemd unit 来管理。写一个简单的服务文件：

[Unit] Description=Oracle Database 11g After=network.target [Service] Type=forking ExecStart=/usr/local/bin/dbora start ExecStop=/usr/local/bin/dbora stop RemainAfterExit=yes User=oracle Group=oinstall [Install] WantedBy=multi-user.target

关键点在于dbora脚本内部要正确调用lsnrctl start、sqlplus startup，并且退出码要准确，否则 systemd 会一直认为服务启动失败。我个人习惯把监听和实例的启动日志分别写到/home/oracle/scripts/log/下，方便每次系统重启后查看是不是真的正常起来了。

6.2 备份策略：逻辑备份 expdp/impdp 加冷备份兜底

“使用 Oracle”绕不开备份。11g 最常用的逻辑备份工具是 expdp/impdp，它能在数据库运行期间做逻辑导出，导出一个 dmp 文件。使用前通常要建一个目录对象：

create directory expdir as '/u01/backup'; grant read, write on directory expdir to system;

然后执行导出：

expdp system/<密码>@orcl schemas=scott directory=expdir \ dumpfile=scott.dmp logfile=scott_exp.log

导入就是反过来：

impdp system/<密码>@orcl schemas=scott directory=expdir \ dumpfile=scott.dmp logfile=scott_imp.log

逻辑备份适合做定期逻辑归档、迁移表结构等场景，但如果数据量很大，全量 expdp 会比较慢。另一种更朴素的冷备份方案是：实例完全关闭后，直接复制数据文件、控制文件、redo 日志到备份盘，需要恢复时把文件复制回去再启动。冷备份简单直观，但要求停机窗口，而且复制过程中文件必须一致。对我个人而言，生产环境至少会把冷备份和 expdp 两者结合：每周一次冷备兜底，每天一次增量或逻辑导出，这样才能睡得踏实。

6.3 内存参数与基础性能调整：别被 AMM 带偏

11g 默认启用自动内存管理（AMM），也就是 memory_target 参数，由数据库自己动态调整 SGA 和 PGA。这在开发和演示环境确实方便，但在配置不高、又要跑老项目的服务器上，自动管理有时候会把内存换来换去，反而引发不稳定。更建议的做法是关闭 AMM，手动设定 SGA_TARGET 和 PGA_AGGREGATE_TARGET：

alter system set memory_target=0 scope=both; alter system set sga_target=1500M scope=both; alter system set pga_aggregate_target=500M scope=both;

设定原则是 SGA 和 PGA 加起来的峰值不要超过物理内存减掉系统自身开销后的容量。比如 4GB 内存，我通常给 SGA 1.5GB、PGA 512MB，剩下留给操作系统和进程开销。设置完可以重启实例验证一次，再观察v$pgastat和v$sga两个视图确认分配情况。数据库性能优化是一条长路，但把内存基线定清楚，是避免一部分“突发性能问题”的最基础工作。

最后再说一个很实际的经验：Oracle 11g 这套环境，建议把整个安装过程按顺序写成自己的脚本和记录文档，因为下次在另一台机器上部署时，很多命令和参数可以直接复用，能少花大半天时间。虚拟机练手的话，记得先给 2 核 4GB 以上配置，并把/u01独立分区给足，否则后面做实验调参数、建数据、导备份都会处处碰壁。老软件没有那么可怕，把依赖、权限和内存这几件事按部就班处理好，CentOS 7 上跑 Oracle 11g 完全可以稳定工作很久。