Linux 下 Oracle 11gR2 安装避坑：从前置检查到建库排错

简介：Linux 环境下 Oracle 11gR2 单机部署的图解文档，面向前期准备容易踩坑的运维人员与数据库新手，覆盖依赖包检查、环境变量配置、图形界面分辨率异常等常见障碍。内容按实际操作顺序推进：从 package 检查、oracle 用户与 oinstall/dba 组创建、ORACLE_HOME 等变量设置，到 runInstaller 的分辨率调整与双盘解压提示，再到单机安装类型、企业版组件、Inventory 目录与 OS 组名的填写，以及安装检查日志的判读、root 执行脚本、netca 配置监听、dbca 建库时 ORACLE_SID 与 UTF-8 字符集的选择，均配界面截图逐步说明。压缩包内含 1 个 doc 文件，体积 1.73MB，便于离线查阅与对照打印。已有 134 人学习下载，可当作安装阶段的随身清单，边看边核对，减少反复试错的时间成本。

1. 敲下 ./runInstaller，光标闪了十几秒什么也没发生

在 Linux 上装 Oracle 11gR2，真正折腾人的从来不是那几个 Next，而是 Next 之前和之后没人告诉你的地方。./runInstaller敲下去光标闪十几秒、界面死活弹不出来、检查报告红一片、装完sqlplus报 ORA-12541——这些手册里一句话带过的环节，能让人从傍晚耗到凌晨。我见过太多次同样的场景：系统环境明明照着文档配了，包也装了，参数也改了，最后还是卡在某个弹窗里不知道点 Yes 还是 No。这篇笔记按我实际踩过的顺序，把 Linux 下 Oracle 11gR2 从解压到建库这条路上最常见的几类故障拆开：每一类先说清它为什么报，再给能直接抄的命令，最后告诉你日志在哪一行、下次怎么一眼定位。适合第一次装 11gR2 被卡住的人，也适合装过几次但每次都得重翻文档的人。

2. 前置检查全是红叉：缺包、swap 不足与 kernel.sem 报错怎么改

走到 Prerequisite Checks 那一页，红叉多到让人怀疑人生，这是 11gR2 给人的第一记下马威。这些检查项背后其实是三件事：系统里少装了库和工具、共享内存与信号量参数没调、磁盘和交换空间不够。它们的共同点是——只要有一项没处理干净，后面 relink 阶段就会以Error in invoking target这种完全看不出因果的方式炸出来，那时候再回头补，成本翻好几倍。

2.1 Package 那一项打红叉：把缺的包名精确捞出来

最常见的表现是检查列表里 Package 一项失败，展开能看到一串compat-libstdc++-33 is missing、libaio-devel is missing之类的明细，安装程序给的编号（PRVF-7531 一类）在小版本之间会有出入，但含义都一样：系统里缺 Oracle 依赖的运行库。别急着点 Yes 跳过——包缺失是少数几个「跳过必翻车」的检查项，跳过之后安装会在链接可执行文件的阶段失败，日志里只有一行 makefile 报错，比现在难查十倍。

定位方法很简单，别一个一个rpm -q手敲，直接跑个循环把缺失项一次性列出来：

# 逐项核对 11gR2 在 64 位 Linux 上要求的依赖包，只打印缺失的 for p in binutils 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 make sysstat \ unixODBC unixODBC-devel; do rpm -q "$p" >/dev/null 2>&1 || echo "MISSING: $p" # 查不到就认为是缺失 done

这段脚本的逻辑就一句话：rpm -q查到返回 0，查不到返回非 0，用||把非 0 的分支接到 echo 上。参数部分只有循环变量$p，包名列表按官方要求抄，不要自己删减——比如sysstat和unixODBC看着和数据库没关系，但检查项里确实会查。

补包的时候有两个坑值得提前说。第一，pdksh在老版本系统上是必需的，RHEL6/CentOS6 之后换成了ksh，如果照着老文档装pdksh会找不到包。第二，也是最多人栽的：64 位系统上只装了 x86_64 版本的 glibc 和 libaio，检查依然报缺失，因为它查的是 i686 版本。常见做法是把对应版本的 32 位包一起装上：

# 64 位系统上 11gR2 会同时校验 32 位库，缺了照样红叉 yum install -y glibc.i686 libaio.i686 libgcc.i686 libstdc++.i686

装完再点一次 Check Again，Package 这一项应该就干净了。如果公司内网没有外网源，compat-libstdc++-33这类老包往往得从系统安装镜像的 Packages 目录里手动rpm -ivh，路径别搞错。

2.2 kernel.sem、shmmax 报错：参数单位是最容易翻车的地方

内核参数检查失败的表现是 OS Kernel Parameter 一项红叉，明细里写semmni、semmsl、shmall、shmmax之类的名字。这一项绝对不能跳过，因为 Oracle 启动实例时要靠 System V 共享内存挂载 SGA，参数不够，实例根本起不来，报的是ORA-27101: shared memory realm does not exist这种完全指不到根因的错误。

改法统一写进/etc/sysctl.conf，别用sysctl -w临时改——重启就丢，装完过两天机器一重启又出问题：

# /etc/sysctl.conf 追加，以下按 2G 内存的单机测试环境估算 kernel.shmmax = 2147483648 # 单个共享内存段上限，单位字节，一般取物理内存一半到全量 kernel.shmall = 524288 # 共享内存总页数，= shmmax / 页大小(4096) kernel.shmmni = 4096 # 共享内存段数量上限 kernel.sem = 250 32000 100 128 # 依次是 semmsl semmns semopm semmni fs.file-max = 6815744 # 系统级文件句柄上限 fs.aio-max-nr = 1048576 # 异步 IO 请求上限，11gR2 的 ASM 和归档都依赖它 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让它立即生效。这里有一个血泪经验：shmmax的单位是字节，shmall的单位是页，两者差 4096 倍。很多人从网上抄来kernel.shmall = 1073741824，在页大小 4K 的 x86 机器上相当于允许 4TB 共享内存，sysctl -p会直接甩一个Invalid argument或者干脆静默不生效，然后你在检查页面上继续看到红叉，怎么改都对不上。

kernel.sem那四个数字也不是随便填的，250 32000 100 128是单实例的标准值，如果后面要上 RAC，第四个数字要调到 142 以上。改完顺手把 oracle 用户的资源限制也放开，这两个文件缺一不可：

# /etc/security/limits.conf 追加，注意是 oracle 用户而不是 * oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240

同时在/etc/pam.d/login里确认有session required pam_limits.so这一行，否则 limits.conf 里的配置对 SSH 登录的会话不生效——这个坑非常隐蔽，你在本地终端ulimit -n看着是 65536，换个登录方式就变回 1024。

2.3 swap、/tmp 和 /etc/hosts：三个最容易被跳过的前置项

这三项在检查报告里往往只是黄色感叹号或者不起眼的红叉，很多人顺手点 Yes 就过去了，结果在后面不同的阶段各栽一次。

Swap Size 检查失败的判定逻辑是：内存 1～2G 时交换分区至少要是内存的 1.5 倍，2～16G 时至少等于内存，超过 16G 时至少 16G。测试机内存给小了很常见，不用重新分区，补一个 swap 文件就行：

# 用文件补足交换空间，改完立即生效且重启后自动挂载 dd if=/dev/zero of=/swapfile bs=1M count=4096 # 生成 4G 大小的交换文件 chmod 600 /swapfile # 权限必须收紧，否则 swapon 会拒绝 mkswap /swapfile # 格式化成 swap swapon /swapfile # 立即启用 echo '/swapfile swap swap defaults 0 0' >> /etc/fstab # 写进 fstab，开机自动挂载

bs=1M count=4096就是 4G，按缺多少补多少；最后一行不加的话，机器一重启交换分区就没了，实例照样起不来。

/tmp空间不足是另一类隐形杀手。安装程序会往/tmp解压几百兆的临时文件，空间不够时报的是No space left on device，有时候出现在安装中途，有时候出现在 root.sh 阶段，措辞完全不同但根因一样。开工前先df -h /tmp看一眼，低于 1G 就先清或者扩。

/etc/hosts的问题更隐蔽：主机名解析不到不会立刻报错，而是等到你配监听、客户端连库的时候才以ORA-12514、TNS-12545的形式冒出来。检查方法就是两行：

hostname # 拿到当前主机名，比如 db01 grep -v '^#' /etc/hosts # 确认里面有一行：192.168.x.x db01

如果 hosts 里只有127.0.0.1 localhost，补一行真实 IP 加主机名，同时确认/etc/sysconfig/network里的 HOSTNAME 和hostname输出一致。这一条建议在跑 runInstaller 之前就做掉，能省下后面半小时的监听排查。

3. 安装界面起不来：runInstaller 无响应、X11 报错与两盘解压翻车

前置检查过了，接下来卡住的地方从「系统」变成了「图形」。这一类故障的特征是：命令敲下去什么反应都没有，或者界面出来了但显示不全、按钮点不到，甚至装到一半提示文件找不到。它们的根因分散在 X11 转发、显示分辨率和安装介质解压三件事上，但表现都是「装不下去」。

3.1 弹不出界面：DISPLAY、xhost 与分辨率的三种排查顺序

最典型的一句报错是Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.，也有时候一个字都不输出，命令直接返回，echo $?还是 0，让人以为装完了。

排查顺序我固定按这三步走。第一步看 DISPLAY 变量有没有传过去——用su oracle从 root 切过去的时候，如果不带横杠，当前环境变量会原样继承，DISPLAY 有可能还在；但如果是su - oracle或者换了个 SSH 会话，DISPLAY 就是空的，runInstaller 找不到 X server 只能静默退出。

# 切到 oracle 用户后第一件事，先确认图形环境变量在 echo $DISPLAY # 期望看到 :0.0 或 :10.0，空的说明变量丢了

第二步，如果 DISPLAY 有值还是连不上，问题在 X server 的访问控制上。在本机桌面的终端里（不是在 ssh 会话里）执行xhost +临时放行本地连接，再切到 oracle 用户跑安装：

xhost + # 临时放宽 X 访问控制，装完记得 xhost - 收回 su - oracle cd /opt/database # 解压后的 database 目录，runInstaller 在它下面 export DISPLAY=:0.0 ./runInstaller

xhost +是把访问控制整个放开，属于临时手段，装完之后用xhost -恢复，别留在生产机上。export DISPLAY=:0.0是给当前会话补上变量，:0表示本机第一块显示器，:10.0这类一般是 ssh 转发出来的虚拟屏。

第三步才是分辨率。11gR2 的 Java 安装界面最小要求 1024×768，屏幕小于这个尺寸时，底部的 Next 按钮会被裁掉，你能看到界面但点不到下一步，非常折磨人。虚拟机里装的话把分辨率调到 1024×768 以上；单纯改分辨率不够的话，装一下 VMware Tools 让显卡驱动正常接管显示，界面才会跟着分辨率重新排版。这个过程不需要重启安装程序，改完分辨率窗口拉伸一下就好了。

3.2 两个 zip 解压到不同目录：装到一半报找不到文件

11gR2 的 Linux 介质是两个 zip 分包，一个1of2、一个2of2。很多人图省事分别解压成database1/和database2/两个目录，安装跑到一半开始报文件不存在——因为第二个包补的是第一个包的部分子目录，分开解压之后目录结构根本拼不起来。

正确的做法是把两个包解到同一层，让 unzip 自动合并同名目录：

mkdir -p /opt/oracle_install && cd /opt/oracle_install unzip -q linux.x64_11gR2_database_1of2.zip -d . # -d . 解压到当前目录 unzip -q linux.x64_11gR2_database_2of2.zip -d . # 第二个包必须解到同一目录，覆盖合并 ls -l database/stage/Components/ # 目录列不全说明合并失败

参数说明只记一条：-d .指定解压目标为当前目录，两个包的目标必须完全相同，unzip 遇到同名目录会自动合并内容而不是覆盖整目录。

顺手验证介质完整性也很有必要，尤其是从别处拷贝来的 zip。unzip -t会逐条校验 CRC，报错就是包传坏了：

unzip -t linux.x64_11gR2_database_1of2.zip | tail -3 # 最后一行应为 No errors detected

传输方式上，scp 和 sftp 默认就是二进制，不用管；用 ftp 传的话务必先执行bin再put，文本模式会把 zip 里的二进制内容改坏，表现和解压失败一模一样。

3.3 Inventory Directory 与 orainstRoot.sh：权限不对后面全是连锁反应

安装到指定 Inventory Directory 那一步，默认路径通常是/opt/oracle/oraInventory或者$ORACLE_BASE的同级目录。这一步如果目录属组不对，安装可能能过去，但 root.sh 阶段或者后续打补丁时报INS-32025、oraInst.loc不存在之类的连锁错误。

根因只有一个：Inventory 目录必须属于oinstall组，并且 oracle 用户可写。建目录的时候就把属组定好，别等报错再回头改：

mkdir -p /opt/oracle/oraInventory chown -R oracle:oinstall /opt/oracle # 属组是 oinstall，不是 oracle 用户同名组 chmod -R 775 /opt/oracle # 组内可写，安装程序需要在这里落清单文件

装完之后验证一下清单文件有没有生成，这个文件是 Oracle 所有安装记录的索引，缺了它以后打补丁、装客户端都会找不到 Oracle Home：

cat /etc/oraInst.loc # 正常应该有两行： # inventory_loc=/opt/oracle/oraInventory # inst_group=oinstall

如果这个文件指到了别的路径，或者inst_group不是 oinstall，说明装的时候填错了，后面opatch一定找不到家。改法是把两处对齐后重跑orainstRoot.sh，或者干脆把路径统一到同一个位置。

4. 装到一半卡住：检查报告判读、root.sh 失败与 netca/dbca 连不上库

真正把人熬到半夜的是这一段：界面在跑，进度条在走，然后一个弹窗跳出来问你要不要继续。点 Yes 还是点 No，全凭猜——猜错的代价是三十秒后另一个更难懂的报错。这一章的重点不是「怎么点」，而是「怎么在点之前就知道这一项能不能放过」。

4.1 检查报告怎么读，哪些红叉能点 Yes 放过

Prerequisite Checks 页面里每一项失败都能展开，展开后有 Code、Severity 和 Detail 三部分。Detail 里写的是具体缺什么，Severity 里 Warning 和 Failed 的处理方式完全不同。我的判断标准很粗暴，按这张表对：

判断完还得知道日志在哪，因为有些明细在界面上显示不全。安装期的临时目录在/tmp/OraInstall加时间戳下面，里面有全量的installActions*.log和只记错误的oraInstall*.err。装了多轮的话，按时间排序找最新那个：

ls -lt /tmp | grep OraInstall | head -3 # 找时间戳最新的安装临时目录 grep -iE "fail|error|prereq" /tmp/OraInstall*/oraInstall*.err | head -50

-lt是按修改时间倒序，head -3取最近三次安装的记录。oraInstall*.err里只有错误行，比翻全量 log 快得多；要查上下文再回头看installActions*.log，那个文件是每一步操作的完整流水。

4.2 root.sh 执行失败：两类原因和一段可重跑的命令

安装快结束时，界面会提示你用 root 执行两个脚本：先orainstRoot.sh，再$ORACLE_HOME/root.sh。这一步失败的画风很有辨识度——满屏Oops、chmod: cannot access、Failed to create，或者干脆一行No space left on device。

第一类原因是磁盘空间，/tmp或者$ORACLE_HOME所在分区满了。先看一眼再动手：

df -h /tmp /opt # 使用率到 100% 的话先清空间，重跑才有意义

第二类原因是权限。root.sh 干的事包括往/etc写oraInst.loc、在/usr/local/bin下建软链接、设置$ORACLE_HOME/bin下若干可执行文件的属主和 setuid 位。如果之前为了图方便手动chown -R oracle:oracle $ORACLE_HOME把属组改成了 oracle 而不是 oinstall，这一步就会在改权限的时候报一堆拒绝。

处理方式是把属组改回来，然后重跑。root.sh 本身是幂等的，跑几遍都没关系：

chown -R oracle:oinstall /opt/oracle/product/11.2.0/dbhome_1 /opt/oracle/oraInventory/orainstRoot.sh # 先跑清单脚本 /opt/oracle/product/11.2.0/dbhome_1/root.sh # 再跑 Oracle Home 脚本

跑完看最后几行，正常会输出The following environment variables are set as:加一串 ORACLE_HOME、ORACLE_SID 的信息。如果最后是Adding entry to /etc/oratab之类，说明 DB 家目录已经注册好了，后面 dbca 建库能直接用。还有一个容易忽略的细节：安装路径和主机名里不要有空格、中文或者中文括号，这些字符在 root.sh 的脚本里没有做转义，出问题的方式千奇百怪。

4.3 netca 起不来监听、dbca 报 ORA-01034 与 SID 对不上

很多安装手册在这一步写的是「在 root 用户下执行 netca 和 dbca」，照着做大概率翻车。root 用户跑 dbca 时，ORACLE_HOME、ORACLE_SID这些环境变量通常是空的或者指向别处，于是建库进程连一个不存在的实例，报ORA-01034: ORACLE not available或者ORA-27101: shared memory realm does not exist——看起来像是数据库坏了，其实只是找错了门。

正确姿势是先切到 oracle 用户，确认环境变量，再动监听：

su - oracle # 一定要带横杠，让它读 ~/.bash_profile echo $ORACLE_SID $ORACLE_HOME # 两个都不能为空，SID 要和后面建库时一致 lsnrctl start # 先把监听起起来 lsnrctl status # 状态里要能看到监听端口和实例注册情况 netca # 图形界面配监听，主机名必须是 /etc/hosts 里能解析的那个

lsnrctl status输出里如果只有Listening Endpoints而没有Service "xxx" has 1 instance(s)，说明实例没注册上，这时候先确认实例是不是真的起来了，而不是继续折腾监听。

监听起不来还有两种常见报错。TNS-12541: TNS:no listener，意思是连的那一头没找到监听，先在本机lsnrctl status确认它活着，再看$ORACLE_HOME/network/log/listener.log里最后一次启动失败的原因。TNS-12545、TNS-00515这一组，九成是listener.ora里HOST写的主机名解析不到，回到 2.3 那节的/etc/hosts检查一遍。端口被占也会导致启动失败，netstat -tlnp | grep 1521一眼就能看出来。

建库时 dbca 里填的 Service Name / SID 必须和$ORACLE_SID完全一致，这是 11g 单实例最容易出错的地方。环境变量里写的是orcl，建库时手滑填了orcl.example.com，建完sqlplus / as sysdba连得上，客户端用 tnsnames 连就报ORA-12514: TNS:listener does not currently know of service requested in connect descriptor。名字要改就得两边一起改，别只改一边。

5. 避坑清单：五条装完才发现的坑

前面四章讲的是「装不下去」和「装到一半卡住」，这一章讲的五条是装完了、以为自己成功了，结果用起来才发现不对的类型。它们的共同特征是：安装过程没有任何报错，等你把数据往里一放，问题才暴露出来。

5.1 建库时密码被拒：ORA-28003 与数字开头的密码

现象：dbca 走到设置口令那一步，输了一个自己觉得很复杂的密码，比如123456abc，弹窗报ORA-28003: password verification for the specified password failed，反复重试都不行，最后只能取消建库重来。

原因：11g 默认启用了密码复杂度校验，密码不能以数字开头、必须包含字母和数字、不能和用户名相同、长度至少 8 位。以数字开头的密码会被直接判定不合法，而这个规则在界面上没有任何提示。

解决：建库时用字母开头、大小写加数字的组合，比如Oracle11gR2这种。如果确实要用简单密码做测试库，建库前先把校验函数关掉，建完再改回来——但这只是测试环境的手段，生产库不要这么干。建库中途取消的残留实例要先dbca删干净再重建，否则第二次建库会因为同名实例已存在而失败。

5.2 字符集选错：中文存进去变成问号

现象：库建好了，应用连上去插一条带中文的记录，查出来全是???，或者报ORA-12705: Cannot access NLS data files or invalid environment specified。

原因：两种可能。一是建库时字符集选了默认值，跟着系统 locale 走成了WE8ISO8859P1这种单字节字符集；二是字符集选对了但客户端NLS_LANG没设，服务端存的是 UTF-8，客户端按别的编码解释。项目正文里提到建库时选 UTF-8 就够用，这个判断是对的——AL32UTF8是 11g 的推荐值，能存汉字和绝大多数符号。

解决：建库时在 dbca 的字符集页面明确选AL32UTF8，别用「默认」那个选项。已经建好的库可以先查一下到底存的是什么字符集：

-- 确认数据库实际字符集，NLS_CHARACTERSET 才是存数据的那个 SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

如果结果是AL32UTF8，那问题在客户端，检查~/.bash_profile里的NLS_LANG=AMERICAN_AMERICA.AL32UTF8有没有导出、sqlplus所在会话有没有生效。如果结果是单字节字符集，那只能重建库或者走 CSALTER 流程——后者对数据有风险，测试库直接删了重建最省事。

5.3 环境变量写在 /etc/profile 里，换个会话就失效

现象：在 root 下装完，su - oracle进去一切正常，但只要开一个新的 SSH 会话，sqlplus就报command not found，或者echo $ORACLE_HOME是空的。

原因：把ORACLE_HOME、PATH、LD_LIBRARY_PATH写进了/etc/profile或者/etc/bashrc，而实际登录时用的是非交互 shell，这些文件根本没被读；也有可能写进了 root 的~/.bash_profile，oracle 用户根本读不到。

解决：统一写到 oracle 用户自己的~/.bash_profile，并且用su - oracle而不是su oracle切换：

# ~/.bash_profile 追加，注意 LD_LIBRARY_PATH 里 $ORACLE_HOME/lib 顺序要靠前 export ORACLE_BASE=/opt/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:/usr/lib64 export NLS_LANG=AMERICAN_AMERICA.AL32UTF8

改完source ~/.bash_profile或者重新登录验证。su不带横杠会保留当前用户的环境变量，这是最容易忽略的细节——同一个命令，su oracle和su - oracle跑出来结果不一样，排查时先确认自己是哪种。

5.4 主机名解析半通不通：监听能起，客户端连不上

现象：本机sqlplus / as sysdba完全正常，从另一台机器用 tnsnames 连，报ORA-12514，或者时好时坏，隔几次能连上一次。

原因：/etc/hosts里只写了127.0.0.1 localhost，没有主机名对应的真实 IP。listener.ora里的HOST写的是主机名，解析不到时监听可能绑到 127.0.0.1 上，只监听回环地址，外部当然连不进来。

解决：在 hosts 里补一行真实 IP 加主机名，重启监听验证：

echo "192.168.10.21 db01" >> /etc/hosts lsnrctl stop && lsnrctl start lsnrctl status | grep -A2 "Listening Endpoints" # 确认绑定的是 192.168.10.21 而不是 127.0.0.1

绑定地址对不对，看 status 输出里Listening Endpoints Summary下面那行(HOST=...)就行，一眼能分辨。

5.5 机器一重启，监听和实例全没了

现象：装完当天一切正常，第二天上班连库报ORA-12541: TNS:no listener，登录服务器一看进程全不在。

原因：11gR2 默认不会随系统启动自动拉起监听和实例。/etc/oratab里每个实例那一行最后一个字段默认是N，意思是「不要自动启动」，很多人装完根本没看过这个文件。

解决：把那一行最后的N改成Y，然后手动跑一次验证：

# /etc/oratab 里这行改成 Y 才允许 dbstart 接管 # orcl:/opt/oracle/product/11.2.0/dbhome_1:Y $ORACLE_HOME/bin/dbstart $ORACLE_HOME # 启动 oratab 里标记为 Y 的实例 $ORACLE_HOME/bin/lsnrctl start # 监听要单独起，dbstart 不管它

要做成开机自启，就把这两条写进rc.local或者包一层启动脚本，注意执行身份必须是 oracle 用户，用 root 跑会因为读不到环境变量而静默失败。

6. 快速定位：11gR2 的日志就那几个地方，按这个顺序看

装 Oracle 出的问题，九成以上能在日志里找到原话，难的是不知道去哪个文件里找。11gR2 的日志位置其实非常固定，我习惯按「装到哪一步」来决定先看哪个，而不是一上来就find / -name "*.log"全盘搜——那样搜出来的结果比问题本身还多。

安装阶段（还能看到 Java 界面的时候），第一站永远是/tmp/OraInstall<时间戳>/，里面的oraInstall*.err只记错误，installActions*.log记全流程。这个目录是临时目录，重装一次就换一个时间戳，所以务必按时间排序取最新的那个。

装完之后运行期的问题，分四类去看：

实例级的alert_<sid>.log是最值钱的一个文件，实例起不来、表空间满、归档写不出去，全都会在这里留一行带时间戳的记录。查它的方式不是从头读，而是倒着看最后几十行：

# 实例告警日志，路径里的 <sid> 换成实际的 ORACLE_SID，倒着看最近的记录 tail -100 $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/alert_orcl.log

看完日志别急着改，先确认一件事：报错的时间戳和你做操作的时间对不对得上。如果日志里最新一条是三天前的，说明你查的根本不是当前这次问题的日志——曾经有一次我在一台机器上排查了四十分钟，最后发现改了/etc/hosts之后没重启监听，日志里全是历史记录，白折腾。

从那以后我每次装完 11gR2，都强制走一遍固定的验收动作：lsnrctl status确认监听绑定的是真实 IP、sqlplus / as sysdba能进、select * from nls_database_parameters确认字符集、最后重启一次机器再重复前三条。这四步花不了五分钟，但能把上面五章里的坑提前暴露八成。这份资源把每一步的界面和检查报告都按顺序存了下来，卡在某个弹窗对不上号的时候，翻对应的那一页比在论坛里翻半天快得多。希望帮到你。

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