Oracle EBS R12.2安装Step by Step实战指南

1. 这不是教科书，是我在客户现场踩了7次坑后写下的R12.2安装实录

Oracle EBS R12.2安装——Step by Step，这八个字背后藏着的不是一套标准化流程，而是一整套需要在真实生产环境里反复校准、动态调整的系统工程。我干这行十二年，从R11i到R12.2.9，亲手部署过43套EBS环境，其中28套是全新安装，15套是跨版本升级。R12.2和之前所有版本都不同：它强制要求WebLogic作为应用服务器、引入Online Patching（热补丁）机制、依赖OPatch 12.2.0.1.11以上版本、必须使用Oracle Database 11.2.0.4或更高版本（且必须打上PSU+BP补丁），更关键的是——它的文件系统结构彻底重构为RUN/EBS/FS1/FS2三套并行文件系统。这些不是技术文档里的冷冰冰条目，而是你凌晨三点盯着屏幕时，决定要不要重装的生死线。

如果你正准备在VMware Workstation上搭一套测试环境，或者要在客户数据中心里上线一套财务+供应链模块的生产系统，这篇内容就是为你写的。它不讲“Oracle是什么”，不解释“EBS架构图”，也不罗列官方PDF里的127个前置检查项。它只告诉你：在真实世界里，哪些步骤必须严格按顺序执行，哪些参数填错一个字符就会卡在adcfgclone阶段，哪些日志文件你该盯住看哪几行，以及——当adop phase=apply失败时，你该先删掉哪个临时目录而不是直接重跑整个周期。核心关键词就三个：Oracle EBS R12.2、Step by Step、安装，所有内容都围绕这三个词的真实落地展开。新手能照着操作完成最小可行安装，老手能从中找到自己漏掉的隐性依赖项。接下来的内容，全部来自我笔记本里记下的真实命令、报错截图、修复时间戳和客户签字确认的变更单。

2. 安装前的硬性门槛与不可妥协的底层准备

2.1 操作系统与内核参数：不是“支持列表”而是“运行底线”

R12.2官方支持Red Hat Enterprise Linux 6.5+、Oracle Linux 6.5+、Solaris SPARC/x86_64。但现实是：RHEL 6.9之后的内核更新（比如kernel-2.6.32-754.el6）会触发WebLogic 10.3.6的JVM兼容性问题，导致AdminServer启动后立即挂掉。我试过用-Djava.security.egd=file:/dev/./urandom参数绕过，结果在并发用户超200时出现SSL握手超时。最终方案是锁定内核版本为2.6.32-696.el6（RHEL 6.9初始版），并在/etc/yum.conf里加exclude=kernel*。这不是保守，是血的教训——某汽车零部件客户因未锁定内核，上线第三天财务月结卡在GL_POSTING阶段，回滚耗时17小时。

内存与Swap配置更是硬约束。官方说16GB RAM够用，但实际中：数据库层至少需8GB（SGA+PGA），应用层WebLogic域需4GB堆内存，再加上OS缓存和ADOP后台进程，24GB才是安全线。Swap空间必须≥RAM的1.5倍，且必须是独立分区（不能是swapfile）。曾有个客户用LVM逻辑卷做swap，adpreclone脚本执行时因I/O延迟触发超时，误判为磁盘满，直接终止克隆。解决方案？用fdisk新建/dev/sdb1，mkswap /dev/sdb1，swapon /dev/sdb1，并在/etc/fstab里固化。

提示：检查swap是否生效，别只信free -m。执行swapon --show，确认TYPE列为partition而非file；执行cat /proc/swaps，验证priority值大于0（file类型priority默认为-1，会被内核优先忽略）。

2.2 文件系统规划：FS1/FS2双轨制的物理实现逻辑

R12.2的革命性设计在于将应用文件拆分为两套独立文件系统：FS1（主运行环境）和FS2（补丁应用环境），通过符号链接/fs1和/fs2指向当前激活的文件系统。这要求你在安装前就必须规划好三块独立磁盘分区：

• /u01：存放数据库软件（Oracle 11gR2或12c），大小≥20GB
• /u02：存放EBS应用文件（即FS1/FS2根目录），大小≥120GB（单模块最小值，财务+制造+HR需≥200GB）
• /u03：存放数据库数据文件（datafile）、归档日志（archivelog）、闪回区（flash_recovery_area），大小≥300GB（按日增量5GB预估3个月）

关键细节：/u02必须用ext4格式（RHEL6默认），且挂载选项含noatime,data=ordered。为什么？因为EBS大量小文件读写，atime更新会引发严重I/O瓶颈；data=ordered确保元数据写入前数据已落盘，避免adop apply阶段因断电导致FS损坏。我见过最惨案例：客户用xfs格式装R12.2，adop phase=fs_clone执行到78%时因inode耗尽失败，重建FS耗时9小时。

注意：不要试图用LVM镜像替代多磁盘。adcfgclone脚本会检测/dev/mapper/路径，若发现LVM设备名含vg_ebs_app，会强制要求输入VG名称，而标准安装文档没提这个交互点——结果卡在静默安装模式下无人值守失败。

2.3 用户与权限：oraapps与applmgr的权限边界

R12.2强制要求两个操作系统用户：oracle（数据库所有者）和applmgr（应用所有者）。但权限分配有陷阱：applmgr用户主目录必须是/u02/fs1/EBSapps/appl，且该目录属组必须是dba（不是oinstall！）。为什么？因为adadmin工具在编译表单时会调用$ORACLE_HOME/bin/genclntsh，而genclntsh需要dba组权限才能读取$ORACLE_HOME/lib/libclntsh.so。若属组设为oinstall，编译FORMS时会报ORA-12154，错误日志却指向TNS配置——这是最典型的误导性报错。

更隐蔽的是环境变量隔离。applmgr用户的.bash_profile里，PATH必须把$COMMON_TOP/util/bin放在$ORACLE_HOME/bin之前。否则adstpall脚本调用ps -ef | grep "java"时，会因ps版本差异（RHEL6.5的ps不支持--forest）导致无法杀掉WebLogic进程，后续adstrtal启动时端口被占，报错“Address already in use”。

3. 数据库层安装：从11.2.0.4到PSU+BP的完整链路

3.1 Oracle Database 11.2.0.4：选择正确的安装包与补丁组合

R12.2最低要求Oracle Database 11.2.0.4，但官方下载页提供两个11.2.0.4版本：p13390677_112040_Linux-x86-64_1of7.zip（数据库软件）和p13390677_112040_Linux-x86-64_2of7.zip（数据库库文件）。注意：必须用这两个包，不能用p10404530_112030_Linux-x86-64（11.2.0.3）升上来——因为R12.2的ADZDDBST.sql脚本依赖11.2.0.4新增的DBMS_SCHEDULER.CREATE_JOB过程，11.2.0.3无此接口，adconfig执行时直接ORA-06550。

安装后第一件事不是建库，而是打补丁。11.2.0.4需叠加PSU（Patch Set Update）和BP（Bundle Patch）。正确顺序是：先装PSU（如p28127267_112040_Linux-x86-64.zip），再装BP（如p27735631_112040_Linux-x86-64.zip）。PSU解决核心稳定性问题（如Bug 21188589导致RMAN备份中断），BP修复EBS专用问题（如Bug 25423973影响AP_INVOICES_ALL表索引重建）。漏打任一补丁，adop phase=apply时会出现“ORA-00600: internal error code, arguments: [kcrf_update_ckpt]”，这是控制文件写入异常，只能重启数据库——但重启后又因未打补丁再次触发，形成死循环。

实操心得：打PSU前，必须关闭所有数据库监听器（lsnrctl stop）和数据库实例（shutdown immediate），否则OPatch会报错“OUI-67073: The patch is not applicable because the specified Oracle Home does not contain a valid Oracle Database installation”。这不是权限问题，是OPatch对进程锁的校验机制。

3.2 数据库创建：字符集、表空间与初始化参数的硬编码规则

R12.2强制要求数据库字符集为AL32UTF8（UTF-8 Unicode），且国家字符集（NLS_NCHAR_CHARACTERSET）必须为AL16UTF16。若用WE8ISO8859P1创建，adconfig执行到“Creating database objects”阶段会报错“ORA-12704: character set mismatch”，因为EBS的FND_LOBS表使用CLOB字段存储多语言附件，WE8ISO8859P1无法解析中文路径。

表空间规划有明文规定：SYSTEM、SYSAUX、UNDOTBS1、TEMP必须存在，且UNDOTBS1大小≥2GB（自动扩展开启）。额外必须创建四个EBS专用表空间：

• APPS_TS_TX_DATA：存放事务数据，初始大小10GB，自动扩展每次1GB
• APPS_TS_TX_IDX：存放事务索引，初始大小5GB，自动扩展每次512MB
• APPS_TS_SEED：存放种子数据（如FND_STANDARD_FIELDS），初始大小2GB，禁止自动扩展（防止seed数据被意外覆盖）
• APPS_UNDOTS1：专用undo表空间，大小3GB，与UNDOTBS1物理隔离（避免EBS事务undo与DBA维护操作争抢）

初始化参数中，processes必须≥500（默认150不够），open_cursors≥2000（默认300会导致并发报表报ORA-1000），nls_length_semantics必须设为CHAR（非BYTE），否则VARCHAR2(30)在AL32UTF8下可能存不下15个汉字。

3.3 监听器与TNS配置：绕过ora-28547的终极解法

ora-28547是R12.2安装中最高频报错：“connection to server failed, probable oracle net admin error”。根源不在监听器本身，而在sqlnet.ora的SQLNET.AUTHENTICATION_SERVICES配置。默认值为(NTS)，即Windows NT认证，Linux下必须改为(NONE)。但改完还不够——必须删除$ORACLE_HOME/network/admin/sqlnet.ora里所有以#开头的注释行。为什么？因为adconfig脚本调用sqlplus时，会逐行读取sqlnet.ora，遇到#号行会触发内部解析器bug，导致认证服务参数读取失败，进而拒绝连接。

监听器配置listener.ora必须包含显式HOST值。不能写localhost，必须写服务器实际IP（如192.168.1.100）。因为EBS应用层通过tnsnames.ora连接数据库时，会反向DNS解析HOST名，若解析失败（如/etc/hosts未配），就报ora-28547。最稳妥方案是在/etc/hosts里加一行：192.168.1.100 ebsdb.yourdomain.com ebsdb。

踩坑实录：某金融客户用DHCP获取IP，adconfig成功后第二天IP变更，所有EBS页面报“Unable to connect to database”。解决方案不是重配监听器，而是把监听器HOST设为0.0.0.0（监听所有接口），并在防火墙放行1521端口——这才是生产环境该有的弹性。

4. 应用层安装：从rapidwiz到adcfgclone的全链路实操

4.1 rapidwiz图形化安装：避开GUI陷阱的静默模式

R12.2提供rapidwiz图形界面安装，但生产环境严禁使用。原因有三：一是Java GUI在无桌面环境（如纯CLI服务器）下崩溃；二是rapidwiz生成的配置文件含绝对路径硬编码，迁移时需手动修改；三是它跳过adpreclone校验，导致后续adop无法识别FS结构。正确做法是用静默模式：

cd $EBS_HOME/startCD/Disk1/rapidwiz ./rapidwiz -silent -responseFile /tmp/r122.rsp

响应文件r122.rsp关键字段：

• ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
• APPL_TOP=/u02/fs1/EBSapps/appl
• COMMON_TOP=/u02/fs1/EBSapps/comn
• DB_NAME=ebsprod
• DB_HOST=ebsdb.yourdomain.com
• DB_PORT=1521

特别注意：DB_HOST必须与tnsnames.ora里SERVICE_NAME的HOST一致，且DB_PORT不能写成字符串"1521"，必须是数字1521（rapidwiz会校验类型）。

4.2 adcfgclone.pl：克隆脚本的参数博弈与日志定位

rapidwiz完成后，真正的安装才开始。执行adcfgclone.pl是核心环节，命令如下：

perl $AD_TOP/patch/115/bin/adcfgclone.pl appsTier \ appspass=welcome123 \ contextfile=/u02/fs1/inst/apps/PROD_ebsdb/appl/admin/PROD_ebsdb.xml \ mode=apply \ skipfmw=true

参数解析：

• appspass：APPS schema密码，必须与数据库里apps用户密码完全一致（区分大小写）
• contextfile：上下文文件路径，必须指向fs1下的xml，不能是fs2或旧备份
• mode=apply：执行克隆应用层，不是dbTier（数据库层克隆由另外脚本处理）
• skipfmw=true：跳过Fusion Middleware安装，因R12.2已内置WebLogic，重复安装会冲突

最关键的隐藏参数是-logfile，必须指定完整路径：

-logfile /u02/fs1/inst/apps/PROD_ebsdb/logs/appl/clone/clone.log

因为adcfgclone默认日志在/tmp，而/tmp可能被清理，导致故障时无日志可查。我坚持把所有日志存到/u02/fs1/inst下，与应用文件同生命周期。

4.3 WebLogic域配置：AdminServer与Managed Server的端口策略

adcfgclone执行后，WebLogic域位于/u02/fs1/FMW_Home/user_projects/domains/EBS_domain_PROD。此时需手动验证AdminServer状态：

cd /u02/fs1/FMW_Home/user_projects/domains/EBS_domain_PROD ./startWebLogic.sh & tail -f nohup.out

等待出现“ADMIN SERVER STARTED IN RUNNING MODE”即成功。但真正麻烦的是Managed Server（oacore、oafm、forms等）。它们默认端口是：oacore=8000, oafm=8001, forms=8003。问题在于：若服务器已有其他服务占用8000，adstrtal会静默失败。解决方案是修改端口映射：

编辑/u02/fs1/inst/apps/PROD_ebsdb/appl/admin/PROD_ebsdb_wl.properties，修改：

s_oacore_http_port=8010 s_oafm_http_port=8011 s_forms_http_port=8013

然后执行autoconfig：

cd /u02/fs1/EBSapps/appl/ad/12.0.0/bin ./adautocfg.sh \ contextfile=/u02/fs1/inst/apps/PROD_ebsdb/appl/admin/PROD_ebsdb.xml \ logfile=/u02/fs1/inst/apps/PROD_ebsdb/logs/appl/autocfg.log

实操心得：autoconfig执行后，必须检查/u02/fs1/inst/apps/PROD_ebsdb/appl/admin/PROD_ebsdb.xml里 标签是否已更新。曾有个客户autoconfig成功但端口未变，原因是contextfile路径输错，脚本用了旧xml——这种错误不会报错，只会静默失效。

5. 验证与故障排查：从登录首页到后台进程的立体诊断

5.1 登录验证：不只是URL能打开，而是看三个核心进程

访问https://ebs.yourdomain.com:8000/OA_HTML/AppsLogin.jsp只是第一步。真正验证成功需确认三件事：

1. 数据库连接：在应用服务器执行sqlplus apps/welcome123@PROD，能登录即通
2. WebLogic状态：ps -ef | grep java | grep AdminServer和grep oacore必须各有一条进程
3. 并发管理器：登录EBS后，导航到“系统管理员 > 并发 > 管理器 > 管理器”，查看Internal Manager状态为“正常”，且“已处理请求数”每分钟递增

若首页打开但报错“Unable to generate forwarding URL”，大概率是$COMMON_TOP/html/下的Apache配置未生效。检查/u02/fs1/inst/apps/PROD_ebsdb/appl/admin/scripts/adoacorectl.sh是否执行成功，该脚本启动Apache子进程。

5.2 常见故障速查表：按错误代码精准定位

5.3 日志分析黄金法则：三日志联动定位法

R12.2故障排查必须同时看三个日志：

• 应用层日志：/u02/fs1/inst/apps/PROD_ebsdb/logs/appl/techstack/（WebLogic启动日志）
• 数据库日志：/u01/app/oracle/diag/rdbms/prod/PROD/trace/alert_PROD.log（数据库告警日志）
• EBS日志：/u02/fs1/inst/apps/PROD_ebsdb/logs/appl/ad/（adop、adconfig等工具日志）

例如，adop phase=apply卡住时，先看adop日志末尾的“ERROR”行，再根据报错中的SQLID（如sql_id=abc123def456）去alert_PROD.log搜“sql_id=abc123def456”，最后在techstack日志里找对应时间戳的“OutOfMemoryError”。三日志时间戳对齐，就能锁定是内存不足、SQL锁表还是JVM配置错误。

最后分享一个小技巧：在/u02/fs1/EBSapps/appl/ad/12.0.0/bin/下创建alias，把常用命令简化：

alias adop='perl $AD_TOP/patch/115/bin/adop.pl' alias adcm='perl $AD_TOP/patch/115/bin/adcmctl.sh' alias adstp='perl $AD_TOP/patch/115/bin/adstpall.sh'

这样输入adop就可以直接执行，省去每次cd和长路径，每天节省12分钟——12年就是876小时，够重装36套环境。