简介：面向具备Linux与Oracle数据库基础的技术人员，尤其是负责Oracle EBS系统安装、配置与维护的IT专业人员，这份资料聚焦生产环境下Oracle EBS R12.1.1至R12.1.3的完整部署链路，涵盖Oracle Linux系统安装与网络、SSH、VNC等环境配置，EBS安装与升级、数据库升级以及Oracle Application Server 10g的安装升级，并附常见问题处理思路，可帮助读者在生产环境中按步骤完成部署并规避典型故障。资源包共1个PDF文件，约844KB，内容按Linux OS安装、系统在线升级与软件安装、OS环境配置等章节组织，目录清晰，便于按环节检索查阅。目前已有953人学习下载，适合需要系统掌握EBS生产环境搭建与升级流程、对照排查配置问题的技术人员参考。

1. 装到一半报 ORA-12547，问题往往不在数据库

Oracle EBS R12.1 生产环境部署最让人头疼的，不是安装本身有多复杂，而是你按文档一步步走完，最后卡在一个看起来跟当前操作毫无关系的报错上。ORA-12547: TNS:lost contact 就是典型——数据库明明起来了，监听也在跑，sqlplus 本地连却直接断掉。这类故障在 EBS 安装、数据库升级、克隆迁移三个阶段都会冒出来，新手容易反复重装，熟手则知道要往 OS 层和权限层翻。这篇笔记按 Linux 系统安装、EBS 安装升级、数据库升级、克隆与 IP 变更几条线，把踩过的坑和能直接抄的排查命令摊开讲，适合正在生产环境部署 R12.1.x 的同行对照使用。

2. Linux OS 配置没做干净：后面 EBS 安装全在还债

EBS 安装器对操作系统的要求比普通 Oracle 数据库更苛刻，很多在单机数据库上能跑过去的环境，到了 EBS 这里会在链接阶段、补丁阶段、甚至启动应用服务时集中爆发。这一章把 OS 层最容易翻车的几处单独拎出来，因为后面所有报错追到底，十有八九能追回这里。

2.1 系统包缺失导致链接失败：libdb-4.3.so 找不到

安装或打补丁过程中出现Rapidwiz Fails With Error Opening libdb-4.3.so，本质是 EBS 安装介质里部分工具链依赖的 Berkeley DB 库在 Oracle Linux 6.x 上默认没有装全。报错通常出现在 rapidwiz 启动阶段或 adpatch 生成可执行文件时，提示某个 .so 打不开，进程直接退出。

先确认缺的是哪个库、被谁引用：

# 查 libdb 相关包是否安装 rpm -qa | grep -i libdb # 查某个二进制依赖了哪些库，定位缺失项 ldd $ORACLE_HOME/appsutil/bin/adconfig.sh 2>/dev/null | grep "not found" # 在系统库路径里找 libdb-4.3.so find / -name "libdb-4.3.so" 2>/dev/null

如果rpm -qa里只有 libdb-4.7 或更高版本，说明 4.3 的兼容包没装。常见做法是从系统安装介质里补装compat-db或对应版本的 libdb 包，装完后用ldconfig刷新缓存，再重新执行失败的步骤。注意不要手工把高版本 .so 软链成 4.3 的名字，链接能过但运行时符号不匹配，会在更靠后的环节炸出来，排查成本翻倍。

参数上重点看两个地方：LD_LIBRARY_PATH是否包含库所在目录，以及oraInventory下安装日志里make阶段的最后几十行。链接失败的真实原因经常被前面的 warning 淹没，直接看$ORACLE_HOME/install/make.log末尾更高效。

2.2 sysctl.conf 与 limits.conf 没调够：安装中途内存/句柄报错

EBS 安装和 adpatch 阶段对共享内存段、信号量、文件句柄的要求比普通库高。sysctl.conf里 kernel.shmmax、kernel.shmall、kernel.sem 没按 EBS 要求设置，表现是安装到一半报共享内存分配失败，或者数据库启动时 ORA-27102 out of memory。limits.conf里 nofile、nproc 不够，则会在并发编译、打补丁时出现莫名其妙的 fork 失败。

我一般按下面这组值先落下去，再根据实际内存调整：

# /etc/sysctl.conf 追加或更新 kernel.shmmax = 68719476736 kernel.shmall = 16777216 kernel.shmmni = 4096 kernel.sem = 256 32000 100 142 fs.file-max = 6815744 net.ipv4.ip_local_port_range = 9000 65500 # /etc/security/limits.conf applmgr soft nofile 65536 applmgr hard nofile 65536 applmgr soft nproc 16384 applmgr hard nproc 16384

kernel.shmmax单位是字节，一般设成物理内存的一半到全部，具体看是否与其他实例共存；kernel.sem四个值分别是每个信号集的信号数、系统级信号数、每次 semop 可操作数、信号集总数，EBS 文档给的参考值偏保守，生产上按并发补丁数量适当放大。改完sysctl -p生效，limits 需要重新登录才对新会话起作用，验证用ulimit -n和ipcs -l看实际值。

提示：改完参数别急着继续装，先重启一次再验证，避免旧会话还带着旧限制，装到一半才发现没生效。

2.3 主机名、IP、hosts 不一致：后面 AutoConfig 反复失败

EBS 对主机名和域名的敏感度极高，安装时填的 hostname、/etc/hosts里的解析、实际 IP 三者必须一致。不一致的典型症状是安装能过，但 AutoConfig 跑不完，或者应用服务起来后 forms 连不上，报 FRM-92050 或 TNS 相关错误。更隐蔽的是 IP 变更后没有重跑 AutoConfig，监听和 tnsnames 里还是旧地址。

排查顺序固定为三步：hostname输出、/etc/hosts里本机记录、ifconfig实际地址，三者对齐后再看tnsnames.ora和listener.ora里的 host 字段。IP 变更后的标准动作是跑一次 AutoConfig，让 EBS 自己把配置刷一遍，而不是手工改 tns 文件——手工改的地方越多，下次打补丁越容易覆盖回去。

# 三步对齐检查 hostname grep -v "^#" /etc/hosts | grep -E "127|192|10\." ip addr show | grep "inet " # IP 变更后重跑 AutoConfig（在应用层执行） cd $ADMIN_SCRIPTS_HOME ./adautocfg.sh

adautocfg.sh会读上下文文件里的主机信息重新生成配置，执行前确认数据库和应用层上下文文件里的 host 已经是新值，否则刷完还是旧的。这一步在克隆场景里同样关键，克隆机改完 IP 不跑 AutoConfig，应用起不来几乎是必然的。

3. EBS R12.1.1 安装与升级：补丁顺序错一步，后面全乱

EBS 的安装和升级是一条强顺序链：R12.1.1 装完、打基础补丁、升到 R12.1.3、再升数据库、再升 AS 10g。任何一步跳序或漏打前置补丁，报错都不会当场出现，而是在下一个阶段以完全不相干的面目爆出来。这一章按实际执行顺序拆开讲。

3.1 adpatch 报 ProcessStateException：先看补丁前置条件

打补丁时出现oracle.apps.fnd.txk.config.ProcessStateException，adpatch 日志里通常伴随某个 worker 失败。这个异常本身信息量很低，真正的原因在adpatch的 log 和adworkxxx目录下的 worker 日志里。常见触发点有三类：前置补丁没打、表空间不足、某个并发管理器没停干净。

定位动作是先找失败 worker 的日志，再看它执行到哪条 SQL 或哪个脚本：

# 进入 adpatch 日志目录，找最新一次运行的日志 ls -lt $APPLRSC/admin/log | head # 在 adpatch 主日志里搜错误关键字 grep -n -i "error\|exception\|failed" adpatch.log | tail -50 # 看失败 worker 的详细日志 ls -lt adwork*/*.log | head

如果日志指向某张表空间写满，先扩表空间再重跑；如果指向某个对象不存在，多半是前置补丁漏打，回补丁说明里核对 patch 依赖。重跑 adpatch 时用adpatch options=nocopyportion,nogenerateportion可以跳过已完成的拷贝和生成阶段，节省大量时间，但前提是确认失败点不在这些阶段。

参数上注意defaultsfile里的patchtop和appl_top路径必须与实际一致，路径写错时 adpatch 会在很早期就报状态异常，看起来像补丁问题，其实是环境变量没对。

3.2 中文语言补丁与多语言加速包：顺序和授权不能省

R12.1.3 升级过程中，中文语言补丁和多语言加速包（如 8576725）的安装顺序有讲究。先装加速包再授权语言，和先授权再装包，结果不同。漏装加速包直接授权中文，表现是登录后部分页面乱码或菜单缺失，不会报硬错误，但功能不完整，属于最难查的一类问题。

标准顺序是：关闭应用保留数据库、启用维护模式、装多语言加速包、打 ADPatch、编译 APPS schema、再授权中文语言。授权语言用 adadmin 里的 License Manager 或对应并发请求，授权后需要重启应用服务才生效。

# 启用维护模式（应用层） cd $ADMIN_SCRIPTS_HOME ./adstpall.sh apps/<password> # 数据库保持运行，执行 adpatch 相关操作 # 授权语言后验证 sqlplus apps/<password> @$FND_TOP/sql/afcpprof.sql

编译 APPS schema 这一步耗时很长，但跳过它会在后续打补丁时出现对象无效，报 ORA-04063 或 ORA-06508。编译完成后用utlrp.sql再扫一遍无效对象，确认数量归零再继续。

3.3 扩展表空间与 adrelink 参数：升级卡住的隐形门槛

升级到 R12.1.3 过程中，SYSTEM、APPS_TS_TX_DATA 等表空间容易在打大补丁时写满。报错形式可能是 ORA-01653 无法扩展表，也可能是 adpatch 某个 worker 莫名失败。提前扩表空间比事后救火省事得多，我一般在升级前把关键表空间的数据文件加一到两个，并打开自动扩展但设上限。

adrelinknew.sh的参数修改是另一个容易忽略的点。链接阶段如果报内存不足或链接器参数过长，需要调整脚本里的链接参数，把并行度和内存相关选项降下来。改之前先备份原脚本，改完只重跑链接步骤，不要整个补丁重来。

-- 查表空间使用率和自动扩展状态 SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS total_gb, ROUND(SUM(maxbytes)/1024/1024/1024, 2) AS max_gb FROM dba_data_files GROUP BY tablespace_name ORDER BY total_gb DESC;

maxbytes为 0 表示没开自动扩展，需要手工加数据文件或改自动扩展。生产环境建议设上限而不是无限扩展，避免一个失控的补丁把磁盘写满拖垮整台机器。

4. 数据库升级到 11.2.0.4：DBUA 前后的坑最集中

EBS 的数据库升级不是单纯跑 DBUA，升级前后有一串配套动作：装 11.2.0.4 软件、打 DB 补丁、更新 initPROD.ora、DBUA 升级、重建监听、补授权和同义词、收集统计信息。漏掉任何一环，应用层都会以连接失败或功能异常的形式反馈回来。

4.1 ORA-12547 TNS lost contact：权限和内核参数两头查

这个报错在数据库升级后首次连接时很常见。表面是 TNS 断连，实际原因分两类：一类是$ORACLE_HOME/bin/oracle可执行文件的权限或属主不对，另一类是内核参数（尤其是 shmmax、sem）不满足新版本要求。升级后如果手工拷贝过 oracle 二进制，权限位容易丢 setuid，导致本地连接直接 lost contact。

排查按下面顺序走，基本能覆盖九成情况：

# 1. 检查 oracle 二进制权限，正常应带 setuid 位 ls -l $ORACLE_HOME/bin/oracle # 2. 权限异常时修复 chmod 6751 $ORACLE_HOME/bin/oracle chown oracle:oinstall $ORACLE_HOME/bin/oracle # 3. 检查内核参数是否满足 11.2.0.4 要求 ipcs -l sysctl kernel.shmmax kernel.shmall kernel.sem # 4. 本地连接测试，绕过监听 sqlplus / as sysdba

如果ls -l显示权限是-rwxr-x--x而不是-rwsr-s--x，就是 setuid 丢了，chmod 6751修复后重试。如果权限正常仍报错，看ipcs -l里共享内存段上限是否小于实例需要，调大 shmmax 后重启数据库。还有一类是$ORACLE_HOME/network/admin/sqlnet.ora里配了不兼容的参数，临时改名排除。

注意：修复权限后不要直接在生产上反复试连，先在测试库验证一遍同样的操作，确认不是其他因素叠加。

4.2 DBUA 升级后监听和 TNS 没重建：应用连不上

DBUA 跑完不代表升级结束。升级后原监听器可能还指向旧 ORACLE_HOME，或者 tnsnames 里的服务名没更新。表现是应用启动时报 TNS 无法解析服务名，或者监听状态里服务是 unknown。标准动作是用 netca 重建监听，或者手工更新 listener.ora 和 tnsnames.ora 后重启监听。

# 查看当前监听状态和服务注册情况 lsnrctl status # 停止并重建监听（交互式，按提示操作） netca # 或手工更新后重启 lsnrctl stop lsnrctl start

重建后确认lsnrctl status里服务状态是 READY，并且tnsping对应服务名能通。应用层还要检查$APPL_TOP/admin/<SID>_<host>.xml上下文文件里的数据库连接串是否已指向新监听，没指向就重跑 AutoConfig。

4.3 升级后补授权和同义词：功能报 ORA-00942

数据库升级完成后，应用层部分功能报 ORA-00942 表或视图不存在，但用 apps 用户查对象明明在。这类问题多半是升级过程中同义词和授权丢失，或者 APPS schema 编译不完整。EBS 有专门的脚本重建 apps 授权和同义词，升级后必须跑一遍。

-- 以 apps 用户执行，重建同义词和授权（示例调用） @$AD_TOP/sql/adgrants.sql

执行前确认当前连的是升级后的数据库，脚本会按 EBS 的标准授权模型重新刷一遍。跑完后用utlrp.sql编译无效对象，再查dba_invalid_objects确认数量。统计信息收集也别漏，SYS 统计信息缺失会导致部分并发请求执行计划异常，表现为请求跑得特别慢而不是报错，更难察觉。

5. 克隆与 IP 变更：最容易在“看起来成功”时翻车

EBS 克隆分预克隆、克隆 DB、克隆应用三步，IP 变更则是在克隆或迁移后必须补的一刀。这两块的问题特点是：克隆脚本返回成功，但应用起不来或部分功能不可用，排查时容易怀疑到错误的方向。

5.1 克隆时报 FileNotFoundException：路径和权限先对齐

数据库克隆阶段出现java.io.FileNotFoundException，常见原因是克隆目标端的目录结构、权限或环境变量与源端不一致。克隆脚本按源端上下文里的路径去找文件，目标端没有对应目录或 applmgr 用户没权限读，就抛这个异常。

先核对三处：目标端$ORACLE_HOME、$APPL_TOP是否已创建且属主正确；克隆响应文件里的路径是否已改成目标端；JDK 相关环境变量是否指向存在的路径。用ls -ld逐个确认目录权限，用echo $JAVA_HOME确认 JDK 路径。修正后重跑克隆的对应阶段，不需要从头来。

5.2 IP 变更后 AutoConfig 没跑：FRM-92050 和 FNDFS 报错

克隆机或迁移机改完 IP，如果不跑 AutoConfig，应用服务起来后 forms 页面报 FRM-92050 Failed to connect to the Server，或者并发请求报 TNS listener on node FNDFS_ may not be running。根因是应用层配置里还留着旧 IP，forms servlet 和 FNDFS 节点解析不到。

处理顺序是：改/etc/hosts和主机名、更新上下文文件里的 host、跑 AutoConfig、重启应用和数据库。上下文文件在$APPL_TOP/admin/<SID>_<host>.xml，host 字段要改成新主机名，然后执行adautocfg.sh。跑完检查tnsnames.ora、listener.ora、httpd.conf里的地址是否都刷新了。

# 改完 hosts 和上下文后执行 cd $ADMIN_SCRIPTS_HOME ./adautocfg.sh # 重启应用 ./adstpall.sh apps/<password> ./adstrtal.sh apps/<password>

如果 AutoConfig 本身报错跑不完，先看$APPL_TOP/admin/<SID>/log下最新的 adconfig 日志，多数是上下文文件里某个路径或主机名对不上，改对再跑。

6. 快速定位这类问题的几个习惯

EBS 的报错有个共同规律：前端报的错和根因往往隔了好几层。ORA-12547 可能追到文件权限，FRM-92050 可能追到 hosts 文件，ProcessStateException 可能追到表空间。所以定位时我固定按“先看日志、再对配置、最后动环境”的顺序走，不凭报错字面猜。

第一步永远是找对日志。EBS 的日志分散在$APPLRSC/admin/log、$ORACLE_HOME/install、adwork*、$APPL_TOP/admin/<SID>/log几处，按时间排序找最新修改的那个，比在界面上反复点更有效。第二步是对配置三件套：hosts、上下文文件、tnsnames/listener，三者一致是绝大多数连接类问题的前提。第三步才是动环境，改参数、补包、扩表空间，每改一处记一笔，避免多个变量同时变导致无法归因。

下面这张对照表是我处理高频报错时的第一反应，可以直接拿去用：

还有一个习惯值得养成：每次打补丁或升级前，先把当前环境的 hosts、上下文文件、tnsnames 备份一份，出问题时能快速对比“改了什么”。EBS 的配置项太多，靠记忆回溯不现实，备份是最便宜的后悔药。另外，补丁和升级操作尽量在测试环境完整走一遍再上生产，很多顺序问题在测试环境就会暴露，不用拿生产去赌。

从那以后我每次动 EBS 环境，不管是装、升还是克隆，都强制先跑一遍主机名/IP/hosts 三对齐检查，再开始任何安装或补丁动作。这个习惯帮我省掉了大量“装到一半才发现环境不对”的返工。希望帮到你。

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