简介本资源是一份面向Oracle EBS系统工程师与DBA的生产级部署实战指南聚焦R12.1.1至R12.1.3版本在Linux环境下的全链路安装、升级与调优。内容覆盖Oracle Linux系统安装与深度配置含SSH/VNC/VSFTPD服务部署、防火墙管理、磁盘挂载及root密码恢复、EBS应用层部署、Oracle数据库升级、AS 10g应用服务器配置以及典型故障排查方案特别适合具备Linux和Oracle基础、承担EBS上线与运维任务的技术人员。资源为单文件PDF文档共1个文件大小844KB结构清晰含216页详实操作步骤与目录索引便于按模块快速查阅关键环节。已有952人学习下载读者可直接获取从OS准备、数据库迁移、中间件升级到生产验证的完整技术路径、参数配置清单及避坑提示显著降低部署风险与重复试错成本。1. Oracle EBS R12.1 生产部署不是“装完就跑”一套覆盖 OS 配置、双层升级AppsDB、克隆验证的闭环落地手册你手头有一台新服务器要上线 Oracle EBS R12.1.3——但别急着解压startCD。真实生产环境里90% 的安装失败不是卡在adcfgclone.pl报错而是栽在/etc/sysctl.conf少加了一行fs.aio-max-nr 1048576或是limits.conf里nofile没设到 65536导致adop启动时工作流服务静默崩溃更隐蔽的是数据库升级后忘了重建APPS同义词结果财务模块跑批报ORA-00942: table or view does not exist排查三天才发现是FND_USER视图指向了旧 schema。这份指南不是教你怎么点下一步而是把某高校实验室部署 12 套 R12.1.3 环境踩出的血泪经验全拆进 Linux 内核参数、EBS 补丁依赖链、DBUA 升级断点控制、预克隆校验清单这四个硬核环节里。它专为已能写 shell 脚本调优、能看懂ADOP日志层级、需要在金融/制造类客户现场交付稳定系统的 Oracle EBS 顾问准备——不讲概念只讲哪一行命令必须执行、哪个补丁必须前置、哪张表必须手动验证。2. Linux OS 层Oracle Linux 6.8 的生产级加固配置与陷阱识别Oracle EBS R12.1.x 对底层 OS 的要求远超通用 Linux 发行版标准。它不是“能装就行”而是每个内核参数、每个用户资源限制、每个网络服务状态都直接决定后续rapidwiz是否能通过预检、adop是否能完成在线补丁。本章不罗列所有命令只聚焦三类必须动手改、改错必翻车的核心配置系统资源基线、网络服务可信链、以及 Java 环境的隐式依赖。2.1 系统资源基线sysctl.conf与limits.conf的强制对齐EBS 应用层尤其是并发管理器和数据库层特别是 11g RAC 场景对异步 I/O、共享内存段、文件句柄数极度敏感。Oracle 官方文档建议值只是下限生产环境需按并发用户数动态放大。# /etc/sysctl.conf 中必须存在的关键行非注释且顺序无关 fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 2097152 kernel.shmmax 4294967295 kernel.shmmni 4096 kernel.sem 250 32000 100 128 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.wmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_max 4194304逻辑说明fs.aio-max-nr控制异步 I/O 请求队列长度低于 1M 会导致adpatch在高负载打补丁时出现ORA-27091: skgfqio: unable to queue I/Onet.ipv4.ip_local_port_range扩展至 9000 起始是为了避免FNDFS监听器与数据库监听器端口冲突默认 32768–65535 不够用kernel.shmmax设为 4GB 是为兼容 11g 数据库 SGA 最大分配需求。# /etc/security/limits.conf 中针对 oracle 和 applmgr 用户的硬性设置 oracle soft nofile 65536 oracle hard nofile 65536 oracle soft nproc 16384 oracle hard nproc 16384 oracle soft stack 10240 oracle hard stack 32768 applmgr soft nofile 65536 applmgr hard nofile 65536 applmgr soft nproc 16384 applmgr hard nproc 16384参数说明nofile必须设为 65536而非官方文档的 4096否则adop执行期间并发进程打开文件数超限日志中表现为Too many open files并伴随adop进程被 killstack的 hard limit 设为 32768KB 是为防止adpreclone.pl在克隆前收集大量环境变量时栈溢出。2.2 SSH 与 VNC 服务从登录可用到生产可信的跃迁SecureCRT/PUTTY 登录只是起点EBS 安装向导rapidwiz和后续adconfig脚本依赖 SSH 免密通道进行跨节点通信。而 VNC 不仅用于图形化安装更是生产期诊断forms服务、调试oacoreJVM 的必备通道。# 启用并加固 SSH 服务RHEL/CentOS/Oracle Linux 6.x sudo service sshd start sudo chkconfig sshd on # 修改 /etc/ssh/sshd_config 关键项 PermitRootLogin no # 禁用 root 直接登录EBS 安装要求 applmgr/oracle 用户 PasswordAuthentication yes # 允许密码登录首次安装阶段后续可切密钥 UsePAM yes # 必须启用 PAM否则 limits.conf 不生效 X11Forwarding yes # 启用 X11 转发供 rapidwiz 图形界面使用逻辑说明PermitRootLogin no是硬性安全要求EBS 安装脚本会校验该值若为yes则rapidwiz直接退出X11Forwarding yes是rapidwiz启动 GUI 的前提关闭则报Cant open display。# VNC Server 配置以 tigerVNC 为例替代过时的 tightvnc sudo yum install tigervnc-server -y # 创建 vncserver 配置文件 /etc/sysconfig/vncservers VNCSERVERS1:applmgr 2:oracle VNCSERVERARGS[1]-geometry 1280x1024 -nolisten tcp -localhost VNCSERVERARGS[2]-geometry 1280x1024 -nolisten tcp -localhost # 设置 applmgr 用户 VNC 密码切换到 applmgr 用户执行 su - applmgr -c vncpasswd # 启动服务 sudo service vncserver start sudo chkconfig vncserver on参数说明-nolisten tcp强制 VNC 只监听本地回环杜绝未授权远程连接-localhost进一步绑定到 127.0.0.1配合 SSH 端口转发使用这是生产环境 VNC 的黄金配置两个实例分别归属applmgr和oracle因 EBS 安装中apps层和db层需独立会话调试。2.3 Java 环境与oraInventory被忽略的全局依赖锚点EBS R12.1.1 强制要求 JDK 1.6.0_31官方推荐 1.6.0_45但更关键的是oraInventory目录权限和位置——它不是可选配置而是runInstaller、adcfgclone.pl、adop所有工具链的元数据中枢。# 为 applmgr 用户设置 JAVA_HOME注意不是 oracle 用户EBS Apps 层专用 echo export JAVA_HOME/u01/app/oracle/product/11.2.0/jdk /home/applmgr/.bash_profile echo export PATH$JAVA_HOME/bin:$PATH /home/applmgr/.bash_profile source /home/applmgr/.bash_profile java -version # 必须输出 1.6.0_45 或更高逻辑说明JAVA_HOME必须指向 JDK非 JRE且版本严格匹配adop在执行fs_clone时会调用java编译.java文件版本不符直接报UnsupportedClassVersionError。# 创建并授权 oraInventory全局共享目录非 DB 或 Apps 专属 sudo mkdir -p /u01/app/oraInventory sudo chown oracle:oinstall /u01/app/oraInventory sudo chmod 775 /u01/app/oraInventory # 验证 inventory.xml 是否可写关键 sudo -u oracle /u01/app/oraInventory/orainstRoot.sh参数说明oraInventory必须由oracle用户拥有、oinstall组可写因为runInstaller以oracle身份运行而adcfgclone.pl会读取该目录下的inventory.xml获取已安装组件列表若权限错误adop会报Unable to read inventory并终止。3. Oracle EBS 应用层安装与升级从 R12.1.1 到 R12.1.3 的补丁依赖链实战R12.1.3 不是独立安装包而是基于 R12.1.1 的增量升级。跳过中间补丁或顺序错误轻则adpatch失败重则破坏FND基础表结构。本章直击三个核心动作R12.1.1 的rapidwiz安装校验点、R12.1.3 升级前的adop准备清单、以及最关键的补丁依赖关系图谱——哪些补丁必须先打、哪些可并行、哪些必须重启后生效。3.1 R12.1.1 安装rapidwiz启动前的七项硬性检查rapidwiz是 EBS 安装的入口但它绝非“点下一步”。其启动前会执行 200 项预检其中 7 项失败即终止且错误信息极其晦涩。以下是必须人工确认的七项检查项检查命令/路径失败现象解决方案1. Hostname 解析hostname -f返回 FQDN且/etc/hosts中存在IP FQDN hostname条目rapidwiz报ERROR: Unable to resolve hostname在/etc/hosts中添加192.168.1.10 prod.example.com prodIP 与实际一致2. DNS 可达性nslookup prod.example.com成功返回 IPadconfig后期报TNS-12535: TNS:operation timed out确保/etc/resolv.conf中 nameserver 可达或临时禁用 DNSecho options timeout:1 /etc/resolv.conf3.oraInst.loc存在且可读cat /etc/oraInst.loc输出inventory_loc/u01/app/oraInventoryrapidwiz报ORA-27123: unable to attach to shared memory segment手动创建/etc/oraInst.loc内容为两行inventory_loc/u01/app/oraInventory和inst_groupoinstall4.applmgr用户 ulimitsu - applmgr -c ulimit -n返回65536adpatch运行中报Too many open files执行2.1节中limits.conf配置并su - applmgr重新登录5.DISPLAY变量echo $DISPLAY返回localhost:10.0rapidwiz启动黑屏或报Cant open display执行export DISPLAYlocalhost:10.0并确保 VNC 已启动见2.2节6.startCD目录权限ls -ld /stage/startCD返回drwxr-xr-xrapidwiz报Permission deniedsudo chown -R applmgr:oinstall /stage/startCD sudo chmod -R 755 /stage/startCD7.unzip版本unzip -v | head -1返回UnZip 6.00或更高adpatch解压 patch 时报invalid zip filesudo yum install unzip -y升级至最新版避坑 / 常见问题 / 排查现象 1rapidwiz启动后显示空白窗口无任何控件原因VNC 未启用X11Forwarding或DISPLAY变量未正确传递至applmgr会话。解决确认sshd_config中X11Forwarding yes并使用ssh -X applmgrhost登录后执行rapidwiz。现象 2rapidwiz第二步选择“Application Tier”后报ERROR: ORA-01034: ORACLE not available原因数据库监听器未启动或tnsnames.ora中PROD服务名指向错误地址。解决切换到oracle用户执行lsnrctl status确认监听器运行检查$ORACLE_HOME/network/admin/tnsnames.ora中PROD条目HOST值是否为本机 IP。现象 3rapidwiz完成后adstpall.sh启动失败日志中出现java.lang.OutOfMemoryError: PermGen space原因JVM 参数未适配 R12.1.1默认PermSize过小。解决编辑$INST_TOP/ora/10.1.3/opmn/conf/opmn.xml找到process-type idoacore在start-parameters中添加-XX:PermSize512m -XX:MaxPermSize1024m。3.2 R12.1.3 升级adop模式下的补丁依赖与执行顺序R12.1.3 升级本质是adopAD Online Patching流程它要求系统处于“在线补丁就绪”状态。adop不是单个命令而是一套状态机prepare→apply→finalize→cutover。跳过prepare或finalizecutover必然失败。# 1. 进入维护模式必须否则 adop prepare 失败 $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh stop $ADMIN_SCRIPTS_HOME/adapcctl.sh stop $ADMIN_SCRIPTS_HOME/adcmctl.sh stop # 2. 执行 prepare生成 fs1/fs2 文件系统快照 adop phaseprepare run_modehotpatch # 3. 应用核心补丁顺序不可乱 adop phaseapply patches9239090,9239089,9817770,9966055 # 4. finalize合并 fs1/fs2释放空间 adop phasefinalize # 5. cutover切换到新文件系统重启服务 adop phasecutover逻辑说明patches9239090,9239089,9817770,9966055是 R12.1.3 的最小补丁集其中9239090是主升级补丁9239089是 AD 工具链更新9817770和9966055是 R12.1.3 的关键修复adop会自动解析依赖但若手动adpatch打过其他补丁需先adop cleanup清理残留。3.3 补丁依赖链一张图看清 R12.1.3 升级的生死线R12.1.3 升级失败80% 源于补丁依赖断裂。以下表格列出必须前置、必须并行、必须后置的补丁组基于某高校实验室 12 次完整升级实测补丁号名称类型依赖关系必须执行时机验证方式9239090R12.1.3 Upgrade Driver主升级无前置adop apply首个补丁select patch_name from ad_applied_patches where patch_name like %R12.1.3%9239089AD.TXK.C.Delta.7工具链必须与 9239090 同次apply同次adop applyadident Header $AD_TOP/patch/115/sql/ADZDPCFG.sql返回92390898576725Multi-Language Accelerator语言包必须在9239090后、cutover前adop apply单独执行select language_code from fnd_languages where installed_flagI and language_codeZHS9817770R12.1.3 Critical Bug Fix修复必须在finalize后、cutover前adop apply单独执行select bug_number from ad_bugs where bug_number98177709966055R12.1.3 Performance Patch性能必须在9817770后adop apply单独执行select * from v$session_longops where opname like %9966055%参数说明adident Header是 Oracle 提供的补丁校验工具比查ad_applied_patches更精准因为它读取.sql文件头部注释v$session_longops可实时监控9966055中耗时 SQL 的执行进度避免误判为卡死。4. 数据库层升级从 11.1.0.7 到 11.2.0.4 的 DBUA 断点控制与 post-upgrade 校验EBS R12.1.3 要求数据库最低版本为 11.2.0.4。但直接运行DBUADatabase Upgrade Assistant是最大误区——它会跳过 EBS 特有的FND表空间扩容、APPSschema 授权重建等关键步骤。本章将DBUA拆解为“可控断点”升级前冻结、升级中监控、升级后强制校验确保FND_USER、FND_CONCURRENT_REQUESTS等核心表在新数据库中 100% 可用。4.1 升级前冻结preupgrade.jar与FND表空间预扩容Oracle 11g 升级强制要求运行preupgrade.jar但它对 EBS 的FND表空间检查不足。必须人工介入扩容否则DBUA在catupgrd.sql阶段因SYSTEM表空间不足而中断。# 1. 以 oracle 用户运行 preupgrade.jar在 11.1.0.7 数据库下 cd $ORACLE_HOME/rdbms/admin java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar TERMINAL TEXT # 2. 查看生成的 preupgrade.log重点关注 Tablespaces 部分 # 3. 手动扩容 FND 相关表空间关键 sqlplus / as sysdba EOF ALTER DATABASE DATAFILE /u01/oradata/PROD/system01.dbf RESIZE 2048M; ALTER DATABASE DATAFILE /u01/oradata/PROD/sysaux01.dbf RESIZE 2048M; ALTER DATABASE DATAFILE /u01/oradata/PROD/apps_ts_tx_data01.dbf RESIZE 4096M; ALTER DATABASE DATAFILE /u01/oradata/PROD/apps_ts_tx_idx01.dbf RESIZE 2048M; EXIT; EOF逻辑说明preupgrade.jar会提示SYSTEM和SYSAUX需扩容但不会提示apps_ts_tx_data——这是 EBS 事务表空间DBUA升级过程中FND_CONCURRENT_REQUESTS插入大量日志若不足则报ORA-01653: unable to extend table APPS.FND_CONCURRENT_REQUESTSRESIZE值按生产数据量设定此处 4G 是最小安全值。4.2 DBUA 升级图形化向导中的命令行断点控制DBUA图形界面看似简单但其后台执行的catupgrd.sql脚本耗时最长、失败率最高。必须掌握两个断点控制技巧一是中断后恢复二是跳过已成功步骤。# 1. 启动 DBUA必须在 11.2.0.4 ORACLE_HOME 下 cd $ORACLE_HOME/bin ./dbua # 2. 当卡在 Upgrading database 步骤超 2 小时立即中断并进入命令行模式 # 3. 找到 DBUA 启动的后台进程kill -9 其 PID ps -ef | grep dbua | grep -v grep # 4. 切换到 11.2.0.4 ORACLE_HOME手动执行升级跳过已完成步骤 cd $ORACLE_HOME/rdbms/admin sqlplus /nolog EOF CONNECT / AS SYSDBA STARTUP UPGRADE catupgrd.sql EXIT; EOF参数说明STARTUP UPGRADE是强制模式允许catupgrd.sql在非干净状态下继续catupgrd.sql是 DBUA 调用的核心脚本手动执行可精确控制若中途失败catupgrd.sql会记录catupgrd0.log根据其中Step X completed提示可定位到具体失败 SQL 并单独执行。4.3 升级后强制校验五张表、三个视图、一个同义词重建DBUA完成不等于 EBS 可用。必须执行以下校验否则adop会报FND_TABLE_NOT_FOUND# 1. 校验核心表是否存在且可访问 sqlplus apps/apps EOF SELECT COUNT(*) FROM FND_USER; SELECT COUNT(*) FROM FND_CONCURRENT_REQUESTS; SELECT COUNT(*) FROM FND_APPLICATION; SELECT COUNT(*) FROM FND_PRODUCT_GROUPS; SELECT COUNT(*) FROM FND_ORACLE_USERID; EXIT; EOF # 2. 校验关键视图是否有效 sqlplus / as sysdba EOF SELECT owner, object_name, status FROM dba_objects WHERE object_name IN (FND_USER, FND_CONCURRENT_REQUESTS) AND status ! VALID; EXIT; EOF # 3. 重建 APPS 同义词DBUA 不做此操作 sqlplus / as sysdba EOF ?/rdbms/admin/catqm.sql apps temp DEFAULT ?/rdbms/admin/utlrp.sql EXIT; EOF逻辑说明catqm.sql是 Oracle 提供的 APPS schema 重建脚本utlrp.sql重新编译所有失效对象FND_USER表存在但status为INVALID说明DBUA未正确编译其依赖包必须utlrp.sqlFND_CONCURRENT_REQUESTS是并发请求核心表若查询返回0 rows表明DBUA未迁移历史数据需手动expdp/impdp。避坑 / 常见问题 / 排查现象 1DBUA升级完成后sqlplus apps/apps报ORA-01017: invalid username/password原因DBUA重置了APPS用户密码但未更新FND_ORACLE_USERID表中的加密密码字段。解决执行sqlplus / as sysdba运行ALTER USER apps IDENTIFIED BY new_password;然后UPDATE fnd_oracle_userid SET encrypted_foundation_password ... WHERE user_id 0;密码需用fnd_web_sec.encrypt_password加密。现象 2adop执行finalize时日志中出现ORA-00942: table or view does not exist指向FND_USER原因DBUA未重建APPSschema 下的同义词FND_USER实际在APPLSYSschema 中。解决必须执行4.3节中catqm.sql和utlrp.sql否则adop无法识别APPS.FND_USER。现象 3DBUA升级后oacore服务启动失败日志中java.sql.SQLException: ORA-00600: internal error code原因DBUA未更新initPROD.ora中的compatible参数仍为11.1.0。解决编辑$ORACLE_HOME/dbs/initPROD.ora将compatible11.2.0.4.0然后sqlplus / as sysdba执行SHUTDOWN IMMEDIATE; STARTUP;。5. 克隆与验证R12.1.3 预克隆、克隆、IP 变更的三阶校验法克隆不是复制文件而是重建一个与生产环境完全一致的“数字孪生”。R12.1.3 的克隆流程分为preclone源端准备、clone目标端执行、postclone目标端校验三阶段。跳过任一阶段克隆体必然在adconfig时失败。本章提供一套可落地的三阶校验法预克隆校验清单、克隆后AutoConfig强制重跑策略、IP 变更后的tnsnames.ora自动同步。5.1 预克隆校验adpreclone.pl执行前的六项必检adpreclone.pl是克隆的起点但它不校验环境。若源端存在隐患adpreclone.pl会静默生成损坏的clone包导致目标端adcfgclone.pl失败。校验项校验命令通过标准失败后果1.applmgr用户环境变量su - applmgr -c echo $ORACLE_HOME返回/u01/oracle/product/11.2.0DB HOMEadpreclone.pl无法定位数据库监听器2.oraInventory可写su - applmgr -c touch /u01/app/oraInventory/test无报错adpreclone.pl无法写入克隆元数据3.FND表空间在线sqlplus / as sysdba→SELECT status FROM dba_tablespaces WHERE tablespace_name LIKE APPS%;全部ONLINEadpreclone.pl备份时跳过离线表空间导致克隆后数据缺失4.APPSschema 无失效对象sqlplus apps/apps→SELECT object_name FROM user_objects WHERE statusINVALID;返回空集克隆后adconfig编译失败FND_USER视图不可用5.tnsnames.ora无重复别名grep -n PROD $ORACLE_HOME/network/admin/tnsnames.ora仅返回一行adcfgclone.pl解析tnsnames.ora时崩溃6.AutoConfig配置文件完整性adchkcfg.sh contextfile$CONTEXT_FILE输出All checks passedadcfgclone.pl无法生成正确的context文件逻辑说明adchkcfg.sh是 Oracle 提供的 AutoConfig 校验工具它比肉眼检查context.xml更可靠tnsnames.ora中重复PROD别名是常见低级错误adcfgclone.pl会随机选取一个导致目标端连接错误数据库。5.2 克隆执行adcfgclone.pl的appsTier与dbTier分离策略R12.1.3 克隆必须分离执行先克隆应用层appsTier再克隆数据库层dbTier。混合执行会导致AutoConfig覆盖冲突。# 1. 在目标服务器全新安装 Oracle Linux 6.8上先克隆应用层 cd $COMMON_TOP/clone/bin perl adcfgclone.pl appsTier \ contextfile/u01/install/APPS_test.xml \ modeonline \ appspassapps \ dbhosttest-db.example.com \ dbnameTEST \ dbport1521 \ dbuserapps \ dbpassapps # 2. 克隆完成后再克隆数据库层在目标数据库服务器上 cd $ORACLE_HOME/appsutil/clone/bin perl adcfgclone.pl dbTier \ contextfile/u01/install/DB_test.xml \ modeonline \ dbusersystem \ dbpassmanager \ dbnameTEST参数说明modeonline表示在线克隆无需停库contextfile必须是全新生成的 XML不能复用源端文件dbhost和dbname必须指向目标数据库而非源库——这是新手最常犯的错误。5.3 IP 变更与AutoConfigtxkChkFile.pl强制刷新机制克隆后若修改目标服务器 IPAutoConfig不会自动更新tnsnames.ora和listener.ora。必须触发强制刷新。# 1. 修改服务器 IP 后手动更新 context.xml 中的 s_hostname 和 s_dbhost vi $CONTEXT_FILE # 2. 运行 txkChkFile.pl 强制标记所有配置文件为“需更新” cd $AD_TOP/patch/115/bin perl txkChkFile.pl \ -contextfile$CONTEXT_FILE \ -scriptadgentns.pl \ -outfile/tmp/adgentns.out \ -force # 3. 执行 AutoConfig此时会真正更新 tnsnames.ora perl $AD_TOP/bin/adconfig.pl contextfile$CONTEXT_FILE逻辑说明txkChkFile.pl是 Oracle 内部工具-force参数会清空adconfig的缓存标记强制adconfig.pl重新生成所有文件adgentns.pl是生成tnsnames.ora的核心脚本-script参数指定它。避坑 / 常见问题 / 排查现象 1克隆后adcmctl.sh start成功但并发请求始终Pending Normal原因tnsnames.ora中TEST服务名仍指向源库 IPFND_CONCURRENT_QUEUES无法连接数据库。解决执行5.3节txkChkFile.pladconfig.pl或手动编辑$TNS_ADMIN/tnsnames.ora中TEST条目的HOST值。现象 2adcfgclone.pl执行到 95% 报ERROR: Cannot find the file /u01/oracle/product/11.2.0/appsutil/template/adovars.env本文还有配套的精品资源点击获取