简介：面向数据集成工程师、中间件运维与 Oracle 技术学习者的 ODI 12cR1 安装实操文档，针对企业级 JEE 与独立安装场景梳理部署要点，帮助读者理解 ODI 与 Fusion Middleware Infrastructure 的依赖关系及安装顺序。资源包仅含 1 个 docx 文档，大小约 2.23MB，内容围绕下载准备、JDK 版本检查、Infrastructure 与 ODI 的图形化安装、odi64.exe 指定 JDK 主目录，以及安装后的 ODI Studio 连接和基础配置展开，对 Operator、Topologies、接口映射与知识模块等核心概念也有说明。已有 266 人学习，适合作为搭建实验环境、排查安装前提和快速熟悉 ODI 部署流程的参考资料，也可供需要补全中间件架构认知的初中级读者按文档逐步实践。

1. 装 ODI 12cR1 卡在第一步的人不少：两个 jar 的顺序比命令本身更要紧

第一次装 ODI 的人，十有八九会把注意力放在图形向导的“下一步”上，真正让人返工的却是前面那些看起来不起眼的决定：JDK 用哪一个、两个 jar 包谁先谁后、ODI 要不要装进 Infrastructure 的那个目录里。这份自编的 ODI 安装文档（Oracle Data Integrator 12cR1，12.1.3.0.0）把这条链路完整走了一遍：两个官方 zip、解压出的fmw_12.1.3.0.0_infrastructure.jar与fmw_12.1.3.0.0_odi.jar、JDK 1.7 以上的前置校验，以及最后双击odi64.exe指定 JDK home 的那一步。它适合要在内网机器上从零搭一套企业级 ODI 环境、后续还要接真实数据源做 ETL 的实施和开发人员；如果你只是想在本机摸一摸 Studio 的界面，走 Standalone 分支就够，不用碰 Infrastructure。下面按环境对齐、双 jar 叠加、域与资料库、排查、脚本化五段，把这份文档里没写透的地方补齐。

2. 环境对齐：JDK、资料库、安装目录三张清单先定死

安装器本身不复杂，复杂的是它对你机器现状的假设。ODI 12.1.3.0.0 的安装程序是 Java 写的，它启动时只认JAVA_HOME和PATH里的那个java；域配置阶段又要连一个能建 schema 的数据库；两个 jar 还必须落在同一个 Oracle Home 下。这三件事任何一件在装之前没定死，后面都会以“装到一半报错”的形式还回来。

2.1 JDK 版本与 JAVA_HOME：别让 PATH 里的老 java 顶包

文档里写的是“JDK 1.7 以上”，这句话在实际操作里太宽。机器上常见的状态是：系统自带一个 1.6 的java在/usr/bin下，环境变量里又挂着另一个 1.8，java -version出来的是前者。安装器一旦用到 1.6，表现出来往往不是一句清楚的“版本不符”，而是解压到一半退出、日志里丢一句Unsupported major.minor version。

我一般会把 JDK 单独放一个目录，比如/u01/jdk1.8.0_1xx，不往系统路径里塞，安装时用绝对路径调它的bin/java，同时在命令行上再显式带一次-jreLoc。这样即使PATH里那堆东西再乱，安装器也只会用你指定的这一份。版本上，12.1.3 这个年代的产品，1.7.0_80 和 1.8.0 的早期小版本是最省心的组合，太新的 8u 尾号有时候会在先决条件检查里被判定为“未认证”。

# 确认这份 JDK 是真能被调起来的，注意用的是绝对路径 /u01/jdk1.8.0_1xx/bin/java -version # 输出里要能看到 64-Bit Server VM，32 位 JDK 装不了企业版 # java version "1.8.0_1xx" # Java(TM) SE Runtime Environment ... # Java HotSpot(TM) 64-Bit Server VM ...

这段命令的意义不在看版本号，而在确认两件事：一是java可执行文件本身没坏，二是它是 64 位的。ODI 企业版安装器在 Windows 上给的是odi64.exe，在 Linux 上虽然没有显式的 64 位后缀，但整个 FMW 栈都是按 64 位编的，32 位 JDK 会在解压阶段就失败，报错信息还相当含糊。参数上，-version走的是标准输出，后面排查安装器问题时，把这条命令的结果和安装日志第一段对一遍，能快速判断到底用的是哪份 JDK。

2.2 资料库规划：schema 前缀、表空间与字符集

企业版 ODI 跑起来需要两类东西：一套 FMW 自己的元数据 schema（MDS、OPSS、IAU、STB 这些），一套 ODI 的仓库 schema（Master Repository 和 Work Repository）。前者由 RCU 统一建，后者也在 RCU 里勾选，或者先建 Master、再在 Studio 的 Topology 里挂 Work。

规划的核心是前缀。RCU 里填一个前缀（比如DEV），它会给你生成DEV_MDS、DEV_OPSS、DEV_IAU、DEV_STB、DEV_ODI_REPO这一串用户。这个前缀一旦定了，后面域配置阶段校验 schema 时是大小写敏感、一字不差的，改一次就得重跑 RCU。我的习惯是：环境名 + 用途，全大写，不超过 8 个字符，比如DEV、UAT、PRD，绝不用odi、test1这种看不出环境的写法。

表空间也别全塞进默认的USERS。FMW 那套 schema 建起来会占掉几百兆，ODI 仓库随接口数量增长得更快，单独给一个ODI_DATA表空间、初始 1G 自动扩展，比事后挪表空间省事得多。数据库字符集要确认是 AL32UTF8，源系统里有中文或特殊字符时，这一条不满足，后面接口跑出来的乱码会让人怀疑人生，而且这种问题在 ODI 层面几乎无解。

表里这些 schema 名在 RCU 界面里是勾选组件后自动拼出来的，不要手写。有一点要提前想清楚：Work Repository 是和具体项目绑定的，一个 Master 下可以挂多个 Work。如果团队里同时有开发库和测试库，常见做法是同一套前缀下建一个 Master、两个 Work（DEV_WORK_REP、UAT_WORK_REP），而不是每个环境都重装一遍。

2.3 安装目录与磁盘：Oracle Home 只装一次，别装两处

这是整份文档里最容易被忽略、后果又最严重的一条。Infrastructure 和 ODI 两个 jar，必须装进同一个Oracle Home 目录。文档里写“选择安装位置”，但没说清楚第二次装 ODI 时这个位置不能新建，必须指回第一次装 Infrastructure 的那个路径。

我在测试机上见过最典型的翻车：Infrastructure 装到了/u01/app/oracle/middleware，装 ODI 时手一抖选了/u01/app/oracle/odi，安装器一路绿灯装完，目录里也确实有文件，可启动config.sh建域时，模板列表里压根没有 ODI 相关的项。原因很简单，ODI 的组件是“叠加”到已有的 FMW Home 上的，装到别处等于装了一份孤立的文件，注册信息根本没进 Oracle Home 的清单。

目录规划上，我的固定结构是这样：/u01/app/oracle/middleware作为唯一的 Oracle Home（两个 jar 都装这里），/u01/app/oracle/config/domains放域，/u01/app/oracle/admin放 Node Manager 和实例相关，/u01/soft放安装包和解压临时文件。磁盘上，Oracle Home 装完大概 4 到 5G，加上域、日志、临时解压，预留 20G 比较稳。/tmp也要看一眼，安装器会往里面写临时文件，/tmp只有 1G 的机器在解压阶段报“空间不足”的情况并不少见。

# 装之前先看一眼磁盘，别等安装器报错才回头查 df -h /u01 /tmp # 建好目录，属主给运行中间件的那个用户，别用 root 装再 chown mkdir -p /u01/app/oracle/middleware mkdir -p /u01/app/oracle/config/domains mkdir -p /u01/app/oracle/admin chown -R oracle:dba /u01/app/oracle # 解压安装包，路径不要带空格和中文 mkdir -p /u01/soft/infra /u01/soft/odi unzip -q fmw_12.1.3.0.0_infrastructure_Disk1_1of1.zip -d /u01/soft/infra unzip -q fmw_12.1.3.0.0_odi_Disk1_1of1.zip -d /u01/soft/odi ls /u01/soft/infra /u01/soft/odi

unzip -q的-q是静默模式，解压大包时刷屏没什么意义，出错了才需要看输出。两个目录分开解压是为了出问题时能一眼看出是哪个包没解开。ls那一步是必须的：正常应该看到fmw_12.1.3.0.0_infrastructure.jar和fmw_12.1.3.0.0_odi.jar两个文件，如果只看到一个.zip或者一个空目录，说明unzip因为磁盘或权限问题中途失败了，这时候去跑java -jar只会得到一句Unable to access jarfile。

3. 双 jar 叠加安装：Infrastructure 先落地，ODI 再叠到同一个 Oracle Home

到这里环境已经定死了，接下来是两个安装器的执行。顺序不能反，Infrastructure 必须先把 Oracle Home 建起来，ODI 才能识别到“这里已经有一套 FMW”并切换到企业安装模式。两份安装器的向导页数都不多，真正需要盯的是安装位置、安装类型和最后那几行日志。

3.1 解压与安装器的启动方式（图形 + 静默）

文档里的做法是进 JDK 的bin目录再跑java –jar 路径\xxx.jar，这是 Windows 上的写法，注意那个短横线其实是中文破折号，直接复制会报错，得手改成 ASCII 的-。Linux 上更推荐用绝对路径调java，省得纠结当前在哪个目录。

# 图形方式启动 Infrastructure 安装器 # -jar 后面跟 jar 的绝对路径，别用相对路径，容易在切换目录后失效 /u01/jdk1.8.0_1xx/bin/java -jar /u01/soft/infra/fmw_12.1.3.0.0_infrastructure.jar # 先决条件检查想跳过自动更新，可以加参数，但生产环境不建议图省事 # /u01/jdk1.8.0_1xx/bin/java -jar .../fmw_12.1.3.0.0_infrastructure.jar -novalidation

图形向导里的几个关键页：欢迎页的自动更新可以取消勾选，内网机器连不上外网时这步会卡很久；先决条件检查页会跑一遍操作系统参数、JDK 版本、磁盘空间的校验，这里出现的警告要逐条看，尤其是“OS Kernel Parameters”相关的，semmsl、shmmax这些不满足，后面域起不来；安装位置页填/u01/app/oracle/middleware，也就是 2.3 里定死的那个目录；安装类型选默认的 Fusion Middleware Infrastructure 即可。整个过程大概 10 到 20 分钟，进度条走到 90% 附近会停一会儿，那是在生成组件清单，不用以为卡死了。

静默安装更适合要装好几套环境的场景，参数就三个关键项：-silent表示无界面，-responseFile指向响应文件，-jreLoc指向 JDK 根目录。

# 静默安装 Infrastructure # -jreLoc 要填 JDK 的根目录，不是 bin 目录，这点和后面 Studio 的要求一致 # -invPtrLoc 指向 oraInst.loc，多 Oracle Home 的机器上必须显式指定 /u01/jdk1.8.0_1xx/bin/java -jar /u01/soft/infra/fmw_12.1.3.0.0_infrastructure.jar \ -silent \ -responseFile /u01/soft/infra.rsp \ -jreLoc /u01/jdk1.8.0_1xx \ -invPtrLoc /u01/oraInst.loc \ -logLevel info

-jreLoc这一项填错是最常见的，很多人下意识写成/u01/jdk1.8.0_1xx/bin，安装器会报找不到 JRE，因为它在那个路径下找lib和release文件。-invPtrLoc的作用是告诉安装器去哪个文件里记“这台机器装过哪些 Oracle Home”，不指定的话它会默认往用户家目录写，多用户共用一台机器时，换个人装就读不到之前的清单。-logLevel info让日志详细一点，出问题时有东西可查，日志默认落在/u01/app/oracle/middleware/oraInst.loc同级或者安装目录下的install子目录里，具体路径安装器结束时会打印在终端最后几行，记得往下翻一屏。

3.2 ODI 安装器的 Enterprise 与 Standalone 分支

Infrastructure 装完，接着装 ODI。这一步的安装位置必须指回/u01/app/oracle/middleware，安装器检测到这个目录下已有 FMW 组件，安装类型里就会出现企业安装的选项。

文档里那句“ODI 企业安装之前必须安装 Oracle Fusion Middleware Infrastructure，独立安装则不需要”，对应的就是这里的两个分支。企业安装（Enterprise）会把 ODI 的组件注册进已有的 Oracle Home，后续能配 JEE 代理、能接 WebLogic 域、能在 EM 里管；独立安装（Standalone）会新建一个只含 Studio、Agent 和 SDK 的目录，不依赖 WebLogic，适合单机试水或者只做设计不做调度的场景。两者的区别不在功能全不全，而在“要不要跑在域里”，一旦涉及生产调度和集群，只能走企业安装。

# 装 ODI，注意安装位置必须与 Infrastructure 完全一致 /u01/jdk1.8.0_1xx/bin/java -jar /u01/soft/odi/fmw_12.1.3.0.0_odi.jar \ -silent \ -responseFile /u01/soft/odi.rsp \ -jreLoc /u01/jdk1.8.0_1xx \ -invPtrLoc /u01/oraInst.loc

响应文件里对应的是ORACLE_HOME=/u01/app/oracle/middleware和INSTALL_TYPE=Enterprise Install这两行，前者写错就变成两份互不相干的安装，后者写错装完就没有域的模板可选。图形方式下，安装类型那一页如果只看到 Standalone 一个选项，说明安装器没认出这是同一个 Oracle Home，退回去检查 2.3 的目录。

安装器跑完后有个细节：它不会自动把odi64.exe或odi.sh放到显眼的位置，Studio 的启动器在$ORACLE_HOME/odi/studio/bin下面。文档里说“双击 odi64.exe，第一次提示指定 JDK home 路径”，指的就是这个位置，Windows 上直接双击，Linux 上跑odi.sh。第一次启动它会弹一个框让你填 JDK 路径，这里填的同样是 JDK 根目录，填bin会一直提示“无效的 JDK 主目录”。

3.3 装完怎么验：目录、组件清单、日志三处交叉确认

安装器显示“成功”不等于真的成功。我一般会做三处交叉确认，任何一处对不上都说明叠加没生效。

第一处看目录结构。Oracle Home 下应该同时存在odi、oracle_common、wlserver这几个一级目录，odi下面有studio、agent、sdk等子目录。如果odi目录存在但wlserver不在，说明 Infrastructure 那份装到了别处。

第二处看组件清单。用 OPatch 列出这个 Oracle Home 里注册的所有组件，正常应该能看到 ODI 和 FMW Infrastructure 各自的条目。

# 列出 Oracle Home 中注册的所有组件 /u01/app/oracle/middleware/OPatch/opatch lsinventory # 输出里重点关注这几行，版本号要对得上 12.1.3.0.0 # Oracle Data Integrator 12.1.3.0.0 # Oracle Fusion Middleware Infrastructure 12.1.3.0.0 # Oracle WebLogic Server 12.1.3.0.0

opatch lsinventory的输出比较长，grep一下能省事，但第一次装的时候建议完整看一遍，里面还会列出 patch 情况。如果 ODI 那行不在，说明第二个 jar 装的其实是另一个 Home，-invPtrLoc指向的清单文件里会有线索。

第三处看安装日志。两个安装器都会在自己的logs目录下留下install*.log，搜索SEVERE和ERROR，有些非致命的错误安装器不会中断，但会在后面配置域时爆发。这三处都对上了，再往下走域配置，能省掉一大半“装完了但配不起来”的排查时间。

4. 域与资料库落地：RCU 建 schema、config.sh 建域、Studio 首连验证

组件装完只是把一个软件栈铺在了磁盘上，它还不会跑。真正让 ODI 能连、能建接口的，是接下来的三件事：RCU 建 schema、配置向导建域、Studio 首次连接。这三步有严格的先后顺序，跳过任何一步都会在下一步卡住。

4.1 RCU 建库：组件勾选与 schema 前缀

RCU 是随 Infrastructure 一起装进来的，位置在$ORACLE_HOME/oracle_common/bin/rcu。它的作用是把 FMW 和 ODI 需要的那一堆 schema 一次性建出来，包括用户、表空间、基础表结构。

图形方式下，几个页要盯住：数据库连接页填的是服务名形式的连接串（主机:端口/服务名），填 SID 在部分版本上会连不上；schema 前缀页填 2.2 里定好的那个字符串，全大写；组件选择页勾选需要建的那些，ODI 相关的在列表里是以Oracle Data Integrator开头的两三项。

静默方式更适合重复执行，组件名用-listComponents先查准确，各版本之间命名会有细微差别。

# 先列出当前 RCU 支持的组件名，别凭记忆写 /u01/app/oracle/middleware/oracle_common/bin/rcu -listComponents # 静默建库，注意连接串、前缀、组件三者要和后续域配置一致 /u01/app/oracle/middleware/oracle_common/bin/rcu -silent \ -createRepository \ -connectString dbhost:1521/ORCLPDB \ -dbUser SYS -dbRole sysdba \ -schemaPrefix DEV \ -component MDS \ -component IAU -component IAU_APPEND -component IAU_VIEW \ -component OPSS -component STB \ -component ODI_REPO \ -f < /dev/null

-connectString用服务名而不是 SID，是为了兼容容器库和多实例；-dbUser SYS -dbRole sysdba是建库必须的权限，用普通 DBA 账号有时会在建表空间那步失败；-f < /dev/null是让它在需要交互确认时直接走默认值，不加会在无人值守时挂住。跑完 RCU 会生成一份rcu.log，里面明确列出每个 schema 的创建结果和临时口令（如果设了统一口令就不用管），这份日志建议留着，域配置阶段连不上库时第一件事就是回来对连接串。

RCU 建完不要急着关窗口，去数据库里确认一下用户是不是真的建出来了，select username from dba_users where username like 'DEV%';应该能列出前面规划的那一串。少一个，后面域配置的 schema 校验就会失败，而且报错信息不一定点名是哪个组件缺。

4.2 config.sh 建域：模板、端口、Node Manager

域配置用的是$ORACLE_HOME/oracle_common/common/bin/config.sh。这个向导前面几步都是通用配置（域位置、管理员口令、端口），真正决定性的是模板选择页。

模板列表里能看到的条目取决于 RCU 建了哪些 schema，正常情况下能看到 Oracle Data Integrator 相关的 Agent、Console、SDK 这几个模板，以及 Oracle Enterprise Manager 的可选项。企业版部署一般至少勾 Agent 和 Console：Agent 负责实际执行调度，Console 提供 Web 端的监控和管理界面。如果模板页里一个 ODI 条目都没有，九成是 RCU 没跑完或者前缀对不上，别在这个页面反复试。

域位置我固定在/u01/app/oracle/config/domains/odi_domain，和管理域分开，方便以后单独备份和迁移。端口规划上，管理服务器用 7001（HTTP）和 7002（SSL），Node Manager 用 5556，这几个端口在测试机上经常被别的服务占着，建域前netstat -tlnp | grep 70看一眼能省一次返工。

# 启动域配置向导 /u01/app/oracle/middleware/oracle_common/common/bin/config.sh # 建完之后启动管理服务器和 Node Manager # 注意顺序：先 Node Manager 再管理服务器，机器重启后靠这个顺序自恢复 /u01/app/oracle/config/domains/odi_domain/bin/startNodeManager.sh & /u01/app/oracle/config/domains/odi_domain/bin/startWebLogic.sh

startNodeManager.sh后面的&只是把它丢到后台，正式环境应该配成系统服务，不然登出终端就断了。启动日志里要确认两件事：一是 Node Manager 报Secure socket listener started，二是管理服务器最后出现Server state changed to RUNNING。这两个都出现了，再用浏览器访问http://主机:7001/em或者 ODI Console 的地址，能出登录页说明域是活的。

域启动慢是常态，尤其第一次，为了生成各种缓存文件，两三分钟都正常。内存不足的机器上，管理服务器会启动到一半退出，日志里是OutOfMemoryError，这种情况在 4.1 建库阶段看不出来，只能靠启动日志判断。测试环境把 JVM 堆调到 1G 到 2G 一般够用。

4.3 Studio 首连与三个必配项（Topology、Operator、KM）

域起来之后才轮到 ODI Studio。第一次启动它连 Master Repository，会走一遍创建向导：填数据库连接、schema 用户和口令，然后设一个SUPERVISOR的 ODI 口令和资料库 ID。这个 SUPERVISOR 口令和数据库口令是两套东西，别混，忘了的话需要进库删记录重建，没有后悔药。

连上之后，一个全新的仓库是空的，按文档里说的，接下来要建 Topology、Operator 和加载知识模块，这三件事是后续所有接口开发的前提。

Topology 最容易卡人的是自己把自己绕晕：物理架构定义“数据库在哪”，逻辑架构定义“在接口里怎么引用”。新手常见的做法是每接一个源库就建一套逻辑架构，结果几十个接口各用各的，后面换库时改到崩溃。稳妥的做法是先按业务域分逻辑架构，物理架构跟具体库一一对应，中间用上下文（Context）来区分环境。Operator 那边，Agent 的 URL 要和 4.2 里域的实际地址端口对上，写错了执行会话会一直停在等待状态。KM 是从安装目录里导入的，路径在$ORACLE_HOME/odi/sdk/xml-reference或者 Studio 的导入向导里直接选，导入前先确认目标数据库的版本，选错 KM 生成的 SQL 在目标库上跑不通。

5. 避坑与排查：五条装完连不上的血泪记录

前面四章是顺着流程走的，这一章按“出了什么现象”倒着查。安装类问题有个特点：报错信息往往指向的是表层，真因藏在几步之前。下面五条是我和同事在不同机器上真实踩过的，每条按现象、原因、解决三段写。

5.1 安装阶段的三次翻车

现象一：java -jar执行后一闪而过，终端只留一句Unable to access jarfile。原因基本只有两种：路径里有空格或中文字符，或者命令行里的短横线是从文档里复制来的全角符号。Windows 上从网页复制命令时，-被替换成–的概率相当高，肉眼几乎看不出来。解决方法是把 jar 路径整体放到一个纯英文、无空格的目录下，命令行里的每个参数前缀手敲一遍，别复制。实在不确定，用ls把完整路径打印出来再粘贴。

现象二：安装器起来了，先决条件检查页报 JDK 版本不符合要求，但java -version明明是新版本。原因是安装器用的不是你终端里那个java，而是它自己按JAVA_HOME或者PATH找到的第一份。机器上装了多个 JDK、又把老版本留在PATH前面时，就会出现“终端看着对、安装器说不对”的分裂。解决是启动时显式传-jreLoc指向正确的 JDK 根目录，同时在当前 shell 里临时把JAVA_HOME覆盖掉，别去改全局配置，改全局会影响机器上别的应用。

现象三：两个包都显示安装成功，但建域时模板列表里没有任何 ODI 条目。这是最费时间的一种，因为两个安装器都给了成功的结论。原因几乎都是安装位置不一致：Infrastructure 装在 A 目录，ODI 装的时候手选了 B 目录，或者第二份的-invPtrLoc指到了另一个清单文件，导致 ODI 认为自己是独立安装。解决只能重装 ODI 那一个包，安装位置严格指回 Infrastructure 所在的 Oracle Home，装完用opatch lsinventory确认两个组件在同一个清单里。这一条没有捷径，唯一的预防手段是装之前把目录写在一张纸上。

5.2 域与 Studio 阶段的两次翻车

现象四：域配置走到 schema 校验页，报“指定的 schema 不存在或口令错误”，但 RCU 日志里明明建成功了。先查连接串格式，RCU 建库和域配置必须用完全相同的连接串写法，一边写 SID、一边写服务名，校验必然失败。再查前缀大小写，RCU 里填小写dev，实际建出来的是大写用户，域配置里如果也填小写做比较就对不上。最后才是查口令，RCU 建库时如果每个 schema 设了不同口令，域配置页要逐个填，漏一个就整页报错。解决顺序就按这个来，从最外层往里排，别一上来就怀疑数据库。

现象五：双击odi64.exe填了 JDK 路径，反复提示“无效的 JDK 主目录”。十次里有八次填的是bin目录。这个启动器要的是 JDK 根目录，也就是包含bin、lib、release那一层的路径，填.../jdk1.8.0_1xx/bin它找不到release文件就判定无效。剩下两次是 JDK 位数不对，32 位 JDK 能被识别但后续加载会失败。解决就是填根目录、确认 64 位，一次搞定。

提示：这五条里有三条的根因都在“安装前没把路径定死”。装之前花十分钟写清楚 JDK 路径、Oracle Home 路径、域路径、schema 前缀这四项，比装完再排查两小时划算得多。

6. 静默安装与重装：把一次性手工活变成可复跑的脚本

一套环境装下来，图形向导点几十次，第二次装的时候你会发现顺序记不全、参数记不准，尤其是隔了几个月再装测试环境。这份自编文档的价值在“步骤清楚”，但要把步骤变成资产，还得落到响应文件和清理清单上。我自己维护的两份 rsp 加一个清理脚本，重装一套环境从半天压到了四十分钟。

6.1 响应文件的关键字段

响应文件不需要从头写，安装器支持-record参数：图形方式完整走一遍，它会把你填的每一项记成一个 rsp，后面照着改就行。手写的话，重点盯下面这几个字段。

# infrastructure.rsp 里必须对的几项 ORACLE_HOME=/u01/app/oracle/middleware # 两个包必须完全一致 INSTALL_TYPE=Fusion Middleware Infrastructure DECLINE_SECURITY_UPDATES=true # 内网机器必须 true，否则卡在联网检查 SECURITY_UPDATES_VIA_MYORACLESUPPORT=false

# odi.rsp 里对应的是这两行，INSTALL_TYPE 写错会装成独立模式 ORACLE_HOME=/u01/app/oracle/middleware INSTALL_TYPE=Enterprise Install

DECLINE_SECURITY_UPDATES这一项如果不设成 true，静默安装会尝试连外网做安全检查，内网环境下会一直等到超时，日志里还不一定写清楚是在等什么。INSTALL_TYPE的取值在两个 rsp 里不一样，这是最容易复制粘贴串的地方，装完发现模板列表空的，先回来查这一行。

6.2 装坏了怎么清：回滚清单

重装的前提是清干净。FMW 的安装不像普通软件那样卸载完就没了，它在 Oracle Home、域目录、数据库 schema、系统服务、清单文件五处都留了痕迹，任何一处没清，重装时都可能读到旧的注册信息。

数据库那一条要特别说：直接drop user ... cascade能删掉用户，但 RCU 在同一套库里还记了组件注册信息，下次建库时会报“该前缀已被占用”。正确做法是用 RCU 的静默删除参数，按同样的组件列表和前缀跑一遍删除，它会把注册信息和用户一起清掉。我吃过一次亏，直接删用户之后重装，RCU 报了一个和权限完全无关的错，查了两小时才反应过来是注册残留。

序也要注意：先停域、再停 Node Manager、最后删目录；反过来的话，进程还握着文件句柄，删到一半会报“设备忙”，而这时候目录已经是半残状态，只能重启机器再删一遍。从那以后我每次重装前都强制走一遍这个清单，一项一项勾，不凭记忆。这套流程加上前面那份自编的安装步骤，基本能保证同一台机器反复装、装到第几遍结果都一致。希望帮到你。

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