企业官网建设流程全解析

简介：面向 Oracle Data Integrator 12cR1 (12.1.3.0.0) 的安装文档，适合需要搭建 ODI 集成环境的 ETL 开发、数据仓库运维及中间件实施人员。文档基于自编实测过程，厘清了企业级 JEE 安装与独立安装的前提差异，明确必须先安装 Oracle Fusion Middleware Infrastructure，并给出两个官方安装文件的获取方式、JDK 版本要求和 java -jar 启动安装的关键步骤。同时覆盖 ODI Studio 的初始化配置，包括 Operator、Topologies、Interfaces、Mappings 及知识模块的作用说明，帮助读者快速建立从底层组件到上层设计的完整认知。资源为单个 docx 文件，大小 2.23MB，共 1 份文档，内容以分步文字说明为主，适合边看边操作。目前已有 262 人学习下载，对于初次接触 ODI 或希望整理安装思路的读者，可少走不少弯路。

1. ODI 安装文档：为什么我坚持自己写一份而不是照抄官方手册

ODI（Oracle Data Integrator）的安装，表面上是“下一步下一步”的图形界面操作，实际上坑都藏在看不见的地方：JDK 版本与 11g/12c 的兼容矩阵、主仓库与工作仓库的分离逻辑、执行代理的内存参数、以及那个最容易让人翻车的“先建主仓库再建工作仓库”的顺序问题。我见过太多同行拿着官方安装文档一步步走，最后卡在 RCU 创建仓库的报错里出不来，不是文档写得不对，而是官方文档为了覆盖所有操作系统和数据库组合，把信息铺得太开，反而让人找不到自己那一条路径。

所以我一直保持一个习惯：每装一次 ODI，就用自己的话重写一份安装文档，只记录当前这套环境（操作系统版本、JDK 版本、数据库类型、ODI 版本）下验证过的步骤和参数。这份“自编文档”不是一个简单地复制粘贴官方步骤的合集，而是把选型理由、参数含义、失败时的现象和解决方案都写进去的实战笔记。这篇博文，就是把我最近一次在某公司内部环境（Linux 服务器 + Oracle 数据库）上安装 ODI 12c 的完整过程做一个复盘，把能复现的步骤和参数都摊开讲，也把那些让我折腾到半夜的坑点提前标出来。

2. 安装前必须想清楚的三件事：版本矩阵、JDK 与仓库规划

2.1 版本兼容矩阵：先查清这四者的关系再动手

ODI 的安装失败的根源，十有八九不是安装步骤出了问题，而是版本之间互相不认。这里说的版本不是 ODI 自己的版本号，而是四者的关系：操作系统版本、JDK 版本、ODI 版本、以及你要连接的数据库版本。官方发布过一个兼容性矩阵文档，网上能搜到，但那个文档更新得不算勤快，而且有些组合标注的是“Certified”和“Compatible”的区别字眼，语义模糊，容易误导人。

我这次用的是 ODI 12.2.1.3，操作系统是 CentOS 7.6，JDK 用的是 1.8.0_202，数据库是 Oracle 12c R2。这个组合我验证过，能跑通。如果你用的是 ODI 11g，那 JDK 必须降到 7，且部分 Linux 发行版的图形界面依赖库也要单独装。有个容易忽视的细节：ODI 12c 的安装程序本身需要图形环境，但很多服务器是纯命令行环境，这时要么用 X11 转发，要么在安装时用 silent 模式。我建议别在生产服务器上直接装图形界面，用 X11 转发最省事，后面会讲到怎么配。

在动手之前，把下面这张表打印出来贴在显示器边上，安装时每一步都对着看一遍，能省掉很多“装到一半才发现版本不对”的返工：

这里要特别强调 JDK 的问题：很多资料说 OpenJDK 也能用，我在某次测试环境里试过，安装程序确实能起来，但跑到创建域（Domain）那一步会报一个和 JVM 内存分配相关的错误，换回 Oracle JDK 就正常了。如果你的环境只能用 OpenJDK，那在一开始就要有这个预期，别等到报错了再回头查，浪费时间。

2.2 主仓库和工作仓库：这两个概念的区分必须在安装前理解

ODI 的仓库体系是两层的：主仓库（Master Repository）存的是元数据、拓扑结构、安全信息和版本历史；工作仓库（Work Repository）存的是开发时的项目、映射、场景等具体设计对象。一个主仓库下面可以挂多个工作仓库，每个工作仓库服务于一个开发团队或一个项目隔离需求。

这个双层结构直接决定了安装顺序：必须先创建并连接主仓库，再创建工作仓库。RCU（Repository Creation Utility）是创建主仓库的工具，它不负责创建工作仓库——工作仓库是在 ODI 的图形客户端里用管理员的身份创建的。很多人在这里搞混，以为 RCU 一次就把两个仓库都建好了，结果在 ODI Studio 里连接不上工作仓库，然后开始怀疑网络配置和端口问题，查了半天才发现是少了一个步骤。

还有一个规划问题：生产环境和开发环境要用不同的工作仓库，但通常只共用一个主仓库。这个在设计拓扑时就要想清楚，因为主仓库一旦创建，它的存放位置和连接信息会写进好几个配置文件里，后面要迁移是很麻烦的一件事。我建议你在安装前先把下面这个规划表填好，填完再动手：

2.3 数据源与系统权限准备：sysdba 账号、表空间与字符集

RCU 在创建主仓库时，需要在目标数据库里做三件事：建立若干表空间、创建若干 schema、执行一批建表和初始化脚本。这三件事都要求你用有 sysdba 权限的账号连接数据库。这里有一个安全上的两难：生产库一般不会直接给你 sysdba 权限，但 RCU 又没有“委托给低权限账号”的方式。常见的做法是请 DBA 协助，在一个测试库上先跑通，然后由 DBA 把建好的 schema 信息导出到生产库。但这样做的风险是，有些系统视图和包的授权在导出导入时容易丢，后面连接仓库时报错时排查起来很费劲。

我的建议是：如果条件允许，就在生产库上用 sysdba 跑 RCU，跑完以后立刻改掉 RCU 创建的 schema 密码，并把初始的 SUPERVIOR 密码也一起改掉。这个流程虽然短，但涉及数据库安全策略，不同单位的规矩不一样，你按自己单位的制度来。这里要强调一点，RCU 创建主仓库时默认会创建一套前缀为 CONFIG 的辅助 schema，这个 schema 不能删，它存的是 RCU 自己的配置信息，删了以后主仓库的元数据会变成黑匣子，没人能解开。

字符集也是一个经常出问题的点。RCU 创建仓库时，如果数据库字符集不是 AL32UTF8，脚本执行时不会立刻报错，但后续在 ODI Studio 里打开映射编辑器时，会出现中文注释乱码、变量名变成问号这类诡异现象，有时候重启 ODI Studio 又好了，过一会儿又乱，排查起来非常费时。所以安装前用下面的 SQL 确认字符集，一步都不能省：

SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';

执行结果必须返回 AL32UTF8。如果不是，你先别继续装 ODI，先和 DBA 讨论数据库字符集改造方案。在错误字符集上装 ODI，相当于在沙地上盖楼，后面每走一步都可能塌，与其这样，宁可先停下来花时间把地基弄对。

3. 用静默模式跑完安装主程序：响应文件与参数说明

3.1 为什么我宁愿用静默模式而不是图形界面安装

ODI 12c 的安装程序支持两种模式：图形交互模式和静默模式。图形模式在本地虚拟机里装没问题，但在远程 Linux 服务器上装，需要处理 X11 转发、中文乱码、窗口尺寸太小导致按钮点不到等一系列问题，非常影响心情。静默模式只需要在命令行里执行一个 java 命令，把安装参数写在一个响应文件里，程序会自动把所有模块安装完成，对网络不稳定和终端断连的容忍度也高很多。

有人会担心静默模式看不到过程，出了问题不好定位。实际上安装程序会输出一份安装日志，位置在 /tmp/oraInstall 目录下，安装过程中任何报错都会完整记录在里面，比图形界面的弹窗提示信息还全。我在实际项目里，装了不下十次 ODI，前两三次用图形界面，后面全部用静默模式加响应文件，效率和稳定性都提升了一个量级。

静默模式还有一个额外的好处：安装参数写在响应文件里，本身就是一份可复现的安装记录。这次装完这台机器，下次换一台新机器，只需要把响应文件拷贝过去，改几个路径变量就能跑，不用重新记忆每一步填了什么。这其实就是在“自编安装文档”之外，多了一层机器可执行的安装规范。

3.2 生成并修改响应文件的完整过程

ODI 安装介质解压后，在根目录下有一个 response 文件夹，里面能找到安装程序的响应文件模板。注意一点：这个模板文件可能不止一个，要选带 odi 字样的那个，别选成 WebLogic 的模板。找到模板后，用文本编辑器打开，重点修改下面几个部分（下面是我用过的响应文件片段，做了脱敏处理）：

# 安装类型：1 表示完整安装（含 ODI Studio、SDK、独立代理） INSTALL_TYPE=1 # 安装目录，注意这个目录最终会是 MIDDLEWARE_HOME 的父目录 ORACLE_HOME=/opt/odi/12c # 操作系统用户组，必须是具备 sudo 权限的用户组 UNIX_GROUP_NAME=oinstall # Java Home，必须是 Oracle JDK 的完整路径 JAVA_HOME=/usr/java/jdk1.8.0_202 # 安装过程中需要读入临时文件的空间 TEMP_DIR=/tmp INSTALL_TEMP_DIR=/tmp # 静默模式必需的参数，固定填 false 表示不显示安装界面 DECLINE_SECURITY_UPDATES=true SECURITY_UPDATES_VIA_MYORACLE_SUPPORT=false

修改时要注意三个地方：第一个是 ORACLE_HOME 的路径不能有空格，也不能是中文路径，否则后面启动 ODI Studio 时会出现解析路径异常；第二个是 UNIX_GROUP_NAME 这个参数，必须是当前系统用户所在的组，如果填错，在安装过程中会在解压到一半时突然报一个权限错误，前面已经生成的文件会被残留下来，影响重装；第三个是 DECLINE_SECURITY_UPDATES 和 SECURITY_UPDATES_VIA_MYORACLE_SUPPORT 这两个参数必须成对出现，只写一个是会有安装程序校验不通过的。

参数修改完，保存文件时一定要用 ASCII 编码，不要用带 BOM 的 UTF-8。我在某次安装时用了 Windows 上的编辑器来修改响应文件，保存时自动加了 BOM，结果安装程序直接报“无法解析响应文件”，排查了半天才发现是文件编码的问题。这个问题太常见了，值得记在你的自编安装文档里。

3.3 执行安装命令与日志排查思路

响应文件准备好之后，执行安装的命令是下面这个样子。注意要在解压后的安装介质根目录下执行，不要跑到别的目录里用绝对路径调用 java，这样会导致程序找不到安装介质的辅助文件：

# 进入安装介质解压后的目录 cd /data/odi_installer/Disk1 # 执行静默安装，-silent 指定静默模式，-responseFile 指定响应文件路径 ./runInstaller -silent -responseFile /data/odi_installer/response/odi_install.rsp # 安装过程大约需要 8-12 分钟，结束后可以通过退出码判断是否成功 echo $?

执行后如果退出码是 0，说明安装程序的主流程已经走完，但注意这并不代表全部组件都装完了。安装程序在最后阶段会在 /opt/odi/12c/oraInventory/logs 目录下生成完整的安装日志，你需要打开看一下有没有 Warning 级别以上的记录，特别是关于“配置文件写入失败”和“权限不足”的提示。这些提示不会影响安装程序的主流程，但会在后续启动 Weblogic 域时变成真正的问题。

还有一个需要手动执行的步骤：安装完成后，安装程序会在日志里提示以 root 身份执行两个脚本，一个是 /opt/odi/12c/oraInventory/orainstRoot.sh，另一个是 /opt/odi/12c/odi/opus/install/root.sh。这两个脚本的作用是设置安装目录的属主和权限、以及注册 ODI 的服务信息。漏掉这一步的直接后果是：后面用命令行启动独立代理时，会报“权限不够”的错误，而且你用普通用户去查日志，日志里没有任何有用的信息，因为根本写不进去。这是一个典型的“安装时一句话带过、运行时让你崩溃”的步骤，务必完成。

4. 用 RCU 创建主仓库并配置域：参数与顺序决定成败

4.1 RCU 的两种运行方式：可选还是必须做对每一步

RCU 的全称是 Repository Creation Utility，在 ODI 安装包解压后能找到它。RCU 本身是一个独立的 Java 程序，它不关心 ODI 是否已经安装，只负责在数据库里创建 ODI 依赖的 schema 和表空间。在 12c 版本中，RCU 的执行方式也分图形和静默两种，我这次要说的是静默方式，原因和安装主程序一样：远程服务器上图形界面不友好，再加上 RCU 执行时会有大量 DDL 输出，图形模式反而看不全。

这里有一个关键认知：RCU 不只是一个建表脚本，它还会往目标数据库写入一组存储过程、系统包和权限配置，这些内容在 ODI 运行时会被频繁调用，尤其是主仓库中的版本控制模块和作业调度模块。所以 RCU 执行时使用的账号必须是 sysdba 权限，普通 DBA 账号即使有建表权限也不行，某些系统包的授权操作会直接失败。

在动手跑 RCU 之前，先用 SQL 确认数据库实例名和监听端口，并把下面这些信息填好：数据库主机地址、端口、服务名（或 SID）、sysdba 账号密码、以及你想创建的主仓库 schema 前缀。这个前缀是 RCU 的一个特色：它会把你输入的前缀和仓库类型合并成一个 schema 名，比如前缀填 DEV，仓库类型选 ODI 主仓库，最终生成的就是 DEV_ODI_MASTER 和 DEV_ODI_CONFIG 两个 schema。

4.2 RCU 静默创建主仓库：命令与配置文件详解

RCU 的安装响应文件位置在安装介质的 rcuhome 目录下，文件名叫 rcu.rsp。它的模板比较简陋，很多参数没有写进模板里，需要你自己往里面加。我把我用的完整配置格式贴出来，带注释解释每个参数的用途：

# RCU 连接数据库的基本信息 RCU_DATABASE_HOST=192.168.10.10 RCU_DATABASE_PORT=1521 RCU_DATABASE_SERVICE_NAME=ORCLPDB # sysdba 权限账号，安装期间会用它来创建 schema RCU_SYSDBA_USER=sys RCU_SYSDBA_PASSWORD=ChangeMe_2024 # 仓库前缀，最终生成的 schema 名是 PREFIX_COMPONENT 形式 RCU_PREFIX=DEV # 仓库类型：1 表示仅创建 ODI 主仓库，0 表示同时创建所有组件 # 注意这个值不要随意改，ODI 12c 只依赖这一个组件 RCU_COMPONENT_ODI=1 # schema 密码，创建后的 ODI_MASTER 和 ODI_CONFIG 都用这个密码 RCU_SCHEMA_PASSWORD=OdiRepo_2024 # 表空间存放位置，留空表示使用数据库默认 RCU_TABLESPACE_LOCATION= # 是否在已有 schema 上执行，1 是跳过已经存在的对象 RCU_SKIP_EXISTING_SCHEMA=0

这里要特别强调两个参数：RCU_SYSDBA_PASSWORD 不能写到命令行里，只能写在响应文件里，并且该文件的权限要设置为 600，否则会在系统日志里留下密码明文，这属于安全红线，在自编文档里要标注清楚。另一个参数是 RCU_SKIP_EXISTING_SCHEMA，这个默认值 0 意味着每次执行都会先清理再重新创建；如果你出于测试目的重复执行 RCU，记得把 1 改成 0 之前先确认那些 schema 已经没有有价值的数据了。

准备好响应文件后，执行 RCU 的命令如下：

# 进入 RCU 安装目录 cd /data/odi_installer/rcuhome # 执行 RCU 静默创建 ./rcu -silent -responseFile /data/odi_installer/response/rcu.rsp # -silent 表示静默模式；-responseFile 指向响应文件；-dryRun 只做校验不执行 # 建议先加 -dryRun 跑一遍，确认参数没写错再正式执行

第一次跑 RCU 时，强烈建议加 -dryRun 参数，它会模拟执行一遍，在参数层面做校验，比如数据库能否连通、前缀是否符合命名规范、表空间路径是否有效。这是很多人忽略但非常有价值的预检步骤，能帮你过滤掉一半的输入错误。正式执行后，RCU 的输出会很多，重点关注结尾部分有没有“Repository creation completed”字样，同时检查日志中是否存在至少两条警告以上的记录，任何“ORA-”开头的错误都不能放过。

4.3 配置域（Domain）的关键步骤与常见参数

主仓库创建完成后，ODI 还不能直接用。你还需要配置一个 Weblogic 域，因为 ODI 12c 的架构是构建在 Weblogic 之上的，ODI Studio 通过 Weblogic 来启动和管理执行代理。配置域的工具是对应的配置向导，Linux 下可以通过命令行静默执行。

配置域的过程里，最关键的一组参数是数据源连接信息。ODI 的域里会创建两个数据源，一个指向主仓库，一个指向配置 schema，如果你之后创建了工作仓库，还需要再对应调整。这组数据源的名称必须和 ODI 内部约定完全一致，不能改动，否则后续连接时会提示找不到数据源。下面是我用的配置脚本关键部分：

# 创建域的命令入口 # 注意这里的 home 参数必须是 ODI 安装时设置的 ORACLE_HOME /opt/odi/12c/odi/oui/bin/config.sh -silent -responseFile /data/odi_installer/response/domain.rsp # domain.rsp 中关键参数 # DOMAIN_HOST_NAME=192.168.10.20 # 本机 IP 或主机名 # DOMAIN_NAME=opdi_domain # 域名称，可以自定义 # DOMAIN_ADMIN_USERNAME=weblogic # Weblogic 管理员账号 # DOMAIN_ADMIN_PASSWORD=Weblogic_2024 # 管理员密码，至少 8 位含字母数字 # JAVA_HOME=/usr/java/jdk1.8.0_202 # 必须和 ODI 安装时一致 # ODI_DATA_SOURCE_CONNECTION_STRING=192.168.10.10:1521:ORCLPDB

配置文件里 DOMAIN_ADMIN_PASSWORD 的复杂度要求是至少 8 位且包含字母和数字，太简单的密码会在配置向导的预校验阶段直接卡住。另外，ODI_DATA_SOURCE_CONNECTION_STRING 这个参数，格式是老式的主机:端口:服务名，中间用冒号隔开，不支持 JDBC URL 格式。我在某次配置时习惯性写成了 jdbc:oracle:thin:@ 开头的长串，配置向导直接报“连接串格式不正确”，后来改成主机冒号端口的格式才通过。这是一个很隐蔽的格式差异，建议在自编安装文档里单独记录。

域配置完成后，还需要检查一下域的启动脚本是否有正确的执行权限。配置向导在最后阶段会自动启动一次域，如果启动失败，你会在日志里看到和 JVM 内存或端口冲突相关的错误。常见的原因有两个：一个是 7001 端口已经被占用（Weblogic 默认管理端口），另一个是机器 hostname 解析异常导致 Weblogic 无法绑定地址。第一个问题好查，用 netstat 看一下端口占用情况就行；第二个问题比较隐蔽，要检查 /etc/hosts 里有没有把主机名映射到 127.0.0.1，Weblogic 对这种情况会直接拒绝启动。

5. ODI 安装中的高频避坑指南：现象、原因与解决方案

5.1 安装程序启动时提示“JAVA_HOME 无效”或直接闪退

现象：执行 runInstaller 时，终端没有任何输出，或者弹出一个对话框提示 JAVA_HOME 无效，然后程序退出。这个问题我在新装系统时经常遇到。原因：ODI 12c 的安装程序虽然可以在终端里执行，但它的启动器是一个二进制文件，该文件在 Linux 上是通过查找 PATH 环境变量里的 java 来定位 JDK 的，如果 PATH 里指向的是 OpenJDK，或者 PATH 里没有 java，启动器就会静默退出。解决：安装前先用 which java 确认当前生效的 JDK 路径，并手动把 JAVA_HOME 导出为 Oracle JDK 的路径，同时也把 PATH 的第一位指到 $JAVA_HOME/bin。如果使用 X11 转发的方式打开图形安装界面，还要确认 xhost 已经放行，否则安装界面会启动后立刻崩溃。

5.2 RCU 提示“ORA-00922: missing or invalid option”

现象：RCU 执行到某个建表语句时报 ORA-00922，然后中断。这个报错看着像 SQL 语法问题，我一开始也是在分析它的建表脚本，后来才发现真正的原因在数据库字符集。原因：RCU 生成的建表语句里，表名和字段名会带有中文注释，这些注释在非 AL32UTF8 字符集的数据库里会被转换成系统默认字符集的编码，导致注释字符串中的某些字符把后面的 SQL 关键词截断，从而触发语法错误。解决：执行 RCU 之前，用前面提到的那条 SQL 检查字符集，如果确实是非 AL32UTF8，不要尝试去改 RCU 脚本，它的脚本是编码过的，改了就没法用了。唯一可靠的方法是让 DBA 调整数据库字符集，或者换一个已经是 AL32UTF8 的实例。

5.3 ODI Studio 连接主仓库时报“无法连接，请检查监听器”

现象：输入主机、端口、用户名密码后，连接提示无法连接主仓库。这个报错信息特别具有迷惑性，因为它暗示问题在网络层，但实际很多时候不是。我排查过三次，两次都是密码问题，一次是服务名写错。原因：ODI 的连接串里，服务名要填写的是数据库服务名而非 SID，且该服务名必须和监听器里配置的一致。开发环境里很多人用的是 SID 而非服务名，习惯了 SID 的写法，拿到 ODI 里用就出错了。解决：用 tnsping 或 SQL Developer 确认正确的服务名，然后在 ODI Studio 的连接配置里重新填写。同时确认主仓库 schema 的密码没有在 RCU 执行后又被 DBA 修改过，这个坑更容易让人抓狂——安装时明明是对的，过了几天连不上了，其实是因为密码过期策略把新建的 schema 账号锁了。

5.4 执行代理（Agent）启动失败，日志里报“Address already in use”

现象：配置完域后，启动 ODI 独立代理或托管代理，日志里出现端口占用错误，代理进程立即退出。原因：ODI 12c 的代理默认端口是 20910，如果同一个服务器上部署了多个 ODI 实例，或者有别的 Java 应用占用了 20910 端口，就会冲突。另外，ODI 的域在启动时会同时启动 Weblogic 的管理服务器，管理服务器的端口是 7001，如果 7001 被占用，也会出现类似的现象。解决：先执行 netstat -tlnp | grep -E '7001|20910' 看端口占用情况。如果是别的应用占用，要么停掉那个应用，要么修改 ODI 的域配置里的端口值。修改端口值不只是改一个数字，它涉及三处：域配置里的监听端口、独立代理脚本里的端口参数、以及 ODI Studio 里创建物理代理时填写的端口。三处不一致，代理状态会显示为“未运行”，实际上进程是活着的，这种假象非常耗费精力排查。

5.5 安装完 ODI Studio 后界面中文乱码或按钮错位

现象：ODI Studio 打开后，界面上的中文全部变成方块和问号，布局也乱了，按钮跑出窗口边界。原因：ODI Studio 的界面字体在 Linux 上默认用系统中文字体，如果系统没有安装文泉驿或 Noto CJK 字体，Java 的 Swing 组件会退回到一个不支持中文的字体，于是出现中文乱码和布局错误。解决：安装字体包，然后在 ODI Studio 的启动配置里手动指定字体。具体来说，用文本编辑器打开 ODI Studio 安装目录下的 odi_studio.conf，在 JVM 参数那一行加一行 -Dawt.useSystemAAFontSettings=on，并指定一个存在的字体名称。注意加错了字体名不会报错，只会仍然乱码，所以改完以后要重启 ODI Studio 验证，这个验证过程本身就是要写进自编文档里的测试用例。

6. 安装后的验证清单与一个小习惯：把安装过程变成可复用的资产

安装完成不代表工作结束，我建议你按下面的清单逐项验证，每一项都对应一个具体的检查动作，这个清单可以直接写进你的自编安装文档里作为验收标准：

这个清单里最重要也是最容易被人忽略的是最后一项——场景执行。很多安装文档在验证环节只做到“连接成功”就收尾了，但连接成功不代表执行组件是好的。我遇到过连接完全正常、代理也是运行中，但一执行映射就报“找不到数据源”的诡异问题，最后的原因是域配置里的数据源没有正确关联到主仓库 schema。这一类问题只有通过执行一个真实的最小映射才能暴露出来，光靠连接测试是查不出来的。

接着这个验证流程，我还想分享一个坚持了很久的习惯：每次安装完 ODI，把关键配置信息记录到一个固定格式的文档里，这份文档不写冗长的描述，只用表格记录主仓库名、工作仓库名、主机端口、 agent 端口、 JDK 路径、以及每个账号的用途。这个文档的价值远超过安装步骤本身，因为它能在三个月后你彻底忘了这次安装细节时，帮你快速定位问题。我曾经在某次环境出问题后，靠这份文档里的端口表和路径表，用了不到 15 分钟就确认是代理进程没有以正确的 ORACLE_HOME 环境变量启动，而旁边一位同事没有这种记录，花了大半天去重新读安装向导的每个界面截图。自编安装文档的真正价值，不在于它比官方文档写得更全，而在于它是被验证过的、和你当前这套环境唯一对应的那一条路径。希望这个习惯对你也有帮助。

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