简介：本资源是一份面向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 配置、双层升级（Apps+DB）、克隆验证的闭环落地手册
你手头有一台新服务器，要上线 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/O；net.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进程被 kill；stack的 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 的前提，关闭则报Can't open display。
# VNC Server 配置（以 tigerVNC 为例，替代过时的 tightvnc） sudo yum install tigervnc-server -y # 创建 vncserver 配置文件 /etc/sysconfig/vncservers VNCSERVERS="1: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 prod（IP 与实际一致） |
| 2. DNS 可达性 | nslookup prod.example.com成功返回 IP | adconfig后期报TNS-12535: TNS:operation timed out | 确保/etc/resolv.conf中 nameserver 可达，或临时禁用 DNS（echo "options timeout:1" >> /etc/resolv.conf） |
3.oraInst.loc存在且可读 | cat /etc/oraInst.loc输出inventory_loc=/u01/app/oraInventory | rapidwiz报ORA-27123: unable to attach to shared memory segment | 手动创建/etc/oraInst.loc，内容为两行：inventory_loc=/u01/app/oraInventory和inst_group=oinstall |
4.applmgr用户 ulimit | su - applmgr -c "ulimit -n"返回65536 | adpatch运行中报Too many open files | 执行2.1节中limits.conf配置并su - applmgr重新登录 |
5.DISPLAY变量 | echo $DISPLAY返回localhost:10.0 | rapidwiz启动黑屏或报Can't open display | 执行export DISPLAY=localhost:10.0并确保 VNC 已启动（见2.2节） |
6.startCD目录权限 | ls -ld /stage/startCD返回drwxr-xr-x | rapidwiz报Permission denied | sudo chown -R applmgr:oinstall /stage/startCD && sudo chmod -R 755 /stage/startCD |
7.unzip版本 | unzip -v | head -1返回UnZip 6.00或更高 | adpatch解压 patch 时报invalid zip file | sudo yum install unzip -y升级至最新版 |
避坑 / 常见问题 / 排查
现象 1：rapidwiz启动后显示空白窗口，无任何控件
原因：VNC 未启用X11Forwarding或DISPLAY变量未正确传递至applmgr会话。
解决：确认sshd_config中X11Forwarding yes，并使用ssh -X applmgr@host登录后执行rapidwiz。现象 2：
rapidwiz第二步选择“Application Tier”后报ERROR: ORA-01034: ORACLE not available
原因：数据库监听器未启动，或tnsnames.ora中PROD服务名指向错误地址。
解决：切换到oracle用户，执行lsnrctl status确认监听器运行；检查$ORACLE_HOME/network/admin/tnsnames.ora中PROD条目HOST=值是否为本机 IP。现象 3：
rapidwiz完成后，adstpall.sh启动失败，日志中出现java.lang.OutOfMemoryError: PermGen space
原因：JVM 参数未适配 R12.1.1，默认PermSize过小。
解决：编辑$INST_TOP/ora/10.1.3/opmn/conf/opmn.xml，找到<process-type id="oacore">，在<start-parameters>中添加-XX:PermSize=512m -XX:MaxPermSize=1024m。
3.2 R12.1.3 升级：adop模式下的补丁依赖与执行顺序
R12.1.3 升级本质是adop（AD Online Patching）流程，它要求系统处于“在线补丁就绪”状态。adop不是单个命令，而是一套状态机：prepare→apply→finalize→cutover。跳过prepare或finalize，cutover必然失败。
# 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 phase=prepare run_mode=hotpatch # 3. 应用核心补丁（顺序不可乱！） adop phase=apply patches=9239090,9239089,9817770,9966055 # 4. finalize（合并 fs1/fs2，释放空间） adop phase=finalize # 5. cutover（切换到新文件系统，重启服务） adop phase=cutover逻辑说明：
patches=9239090,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 次完整升级实测：
| 补丁号 | 名称 | 类型 | 依赖关系 | 必须执行时机 | 验证方式 |
|---|---|---|---|---|---|
| 9239090 | R12.1.3 Upgrade Driver | 主升级 | 无前置 | adop apply首个补丁 | select patch_name from ad_applied_patches where patch_name like '%R12.1.3%' |
| 9239089 | AD.TXK.C.Delta.7 | 工具链 | 必须与 9239090 同次apply | 同次adop apply | adident Header $AD_TOP/patch/115/sql/ADZDPCFG.sql返回9239089 |
| 8576725 | Multi-Language Accelerator | 语言包 | 必须在9239090后、cutover前 | adop apply单独执行 | select language_code from fnd_languages where installed_flag='I' and language_code='ZHS' |
| 9817770 | R12.1.3 Critical Bug Fix | 修复 | 必须在finalize后、cutover前 | adop apply单独执行 | select bug_number from ad_bugs where bug_number='9817770' |
| 9966055 | R12.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。但直接运行DBUA（Database 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_REQUESTS；RESIZE值按生产数据量设定，此处 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.sql；FND_CONCURRENT_REQUESTS是并发请求核心表，若查询返回0 rows，表明DBUA未迁移历史数据，需手动expdp/impdp。
避坑 / 常见问题 / 排查
现象 1：DBUA升级完成后，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加密）。现象 2：
adop执行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。现象 3：
DBUA升级后，oacore服务启动失败，日志中java.sql.SQLException: ORA-00600: internal error code
原因：DBUA未更新initPROD.ora中的compatible参数，仍为11.1.0。
解决：编辑$ORACLE_HOME/dbs/initPROD.ora，将compatible='11.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.0（DB HOME） | adpreclone.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%'; | 全部ONLINE | adpreclone.pl备份时跳过离线表空间，导致克隆后数据缺失 |
4.APPSschema 无失效对象 | sqlplus apps/apps→SELECT object_name FROM user_objects WHERE status='INVALID'; | 返回空集 | 克隆后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 passed | adcfgclone.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 \ mode=online \ appspass=apps \ dbhost=test-db.example.com \ dbname=TEST \ dbport=1521 \ dbuser=apps \ dbpass=apps # 2. 克隆完成后，再克隆数据库层（在目标数据库服务器上） cd $ORACLE_HOME/appsutil/clone/bin perl adcfgclone.pl dbTier \ contextfile=/u01/install/DB_test.xml \ mode=online \ dbuser=system \ dbpass=manager \ dbname=TEST参数说明：
mode=online表示在线克隆，无需停库；contextfile必须是全新生成的 XML，不能复用源端文件；dbhost和dbname必须指向目标数据库，而非源库——这是新手最常犯的错误。
5.3 IP 变更与AutoConfig：txkChkFile.pl强制刷新机制
克隆后若修改目标服务器 IP，AutoConfig不会自动更新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 \ -script=adgentns.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服务名仍指向源库 IP，FND_CONCURRENT_QUEUES无法连接数据库。
解决：执行5.3节txkChkFile.pl+adconfig.pl，或手动编辑$TNS_ADMIN/tnsnames.ora中TEST条目的HOST=值。现象 2：
adcfgclone.pl执行到 95% 报ERROR: Cannot find the file /u01/oracle/product/11.2.0/appsutil/template/adovars.env
本文还有配套的精品资源，点击获取
