去年年底我们把内部所有测试环境的数据库部署都统一到了脚本化安装这条路上省掉了大量重复的点击下一步操作。但说句实话那段脚本最初只是为了应付 Oracle 19c 和 21c 写的内部塞了不少临时补丁和硬编码路径能跑通全靠佛祖保佑。这次接到 Oracle 26ai 的安装需求我本来想照着老路先试试结果发现连runInstaller的参数都变了静默安装响应文件的格式也和以前不一样。没办法只能把这套老脚本拉出来重新打磨。今天这篇就完整记录一下我这次脚本再升级、兼容 Oracle 26ai 一键安装的整个过程包括环境检测逻辑的取舍、响应文件怎么写更稳、静默安装阶段容易踩的坑以及最后验证环节的经验教训。如果你手头也维护着数据库安装脚本或者正准备把新版本数据库纳入自动化体系这篇应该能帮你避免后面几周的折腾。顺便说一下我手上这套环境的背景方便你对照参考主要用于模拟项目X的测试环境搭建操作系统是 Linux 系统内核版本不算新但也不算老CPU 和内存配置属于中规中矩的物理服务器或较大规格的虚拟机存储是本地盘加共享存储的组合。实际生产环境通常会更加复杂我后面讲到的检查项和建议基本考虑了这类差异你可以根据自己的环境适当调整。1. 脚本升级的起因与价值定位1.1 从手工安装到一键脚本的必然转变先说一个感知特别明显的事Oracle 数据库的安装已经不是简单的下一步下一步能糊弄过去的了。尤其到了 26ai 这个版本前置依赖检查、内核参数验证、用户权限规划、目录结构设计每一步都嵌套着大量的判断逻辑。手工安装最大的问题不是慢而是不一致。同一个安装手册让不同的人去执行最后装出来的环境大概率会有细微差异有人把ORACLE_BASE放在了/u01/app/oracle有人随手放在/home/oracle/app有人记得改limits.conf有人装完才发现nproc没生效。这些差异平时看着无关紧要一旦后面做集群、做备份恢复、做性能调优全是隐形的坑。一键安装脚本的核心价值并不是快而是把安装过程标准化、可重复、可审计。脚本写好了不管是新手还是老手执行结果都一样。出了问题时也不用翻聊天记录猜谁改了哪个参数直接看脚本里怎么定义的就行。这也是为什么我这次升级决定不只是把旧脚本里的版本号从 19c 改成 26ai而是把整条安装链路重新梳理了一遍。1.2 旧脚本在 Oracle 26ai 面前暴露的问题旧脚本最核心的问题是硬编码太多 判断逻辑太弱。比如里面有一段检测磁盘空间的代码直接写死了要检查/u01这个挂载点。但 26ai 的安装文档建议把ORACLE_BASE和ORACLE_HOME分开放还推荐数据文件目录单独规划光靠检查一个/u01显然不够。再比如旧脚本里对操作系统的版本判断用的是grep版本号里的一个数字可 26ai 在系统依赖上做了一些调整旧的判断条件直接失准。还有更隐蔽的问题旧脚本在静默安装阶段用的是响应文件response file但 26ai 对响应文件的格式做了比较大的调整有一些旧的关键字被废弃了新的配置项如果不写又会触发警告。我当时第一个想法是这脚本怕不是要重写后来冷静下来重新评估了一遍发现其实核心框架还能用主要是需要在几个关键节点上做兼容层适配。所以我定下的升级策略是保留原有脚本的分阶段执行框架重构环境检测和响应文件生成这两个核心模块同时增加安装后的验证环节。1.3 升级脚本的最终目标与适用范围这次脚本升级我设定了几个明确的验收目标不只是能装上就行在全新的 Linux 服务器上从零开始自动完成 oracle 用户创建、目录规划、内核参数配置、依赖包检查、静默安装、root.sh 执行、环境变量配置。支持同一套脚本适配至少三种常见的 Linux 发行版或同一发行版的不同大版本不能只在某一台机器上能跑。安装过程要有日志记录并且出错了能清楚看到是哪个阶段、哪条命令、什么报错。整个安装过程无人值守跑完从执行到结束不需要人工介入除非遇到必须人工决策的异常比如磁盘确实不够。适用范围上这套脚本主要面向测试环境和新项目初期的快速交付生产环境如果走这个脚本建议在验证阶段多增加几层检查再上。我在文末会专门讲生产环境使用的注意事项。2. 兼容性分析Oracle 26ai 带来的新变化2.1 安装介质与补丁包的变化趋势Oracle 26ai 的安装介质形态和以前相比有了明显调整。过去我们拿到的通常是一个几 GB 的 zip 包解压后里面是Database、Grid等目录然后通过runInstaller来调用图形或静默模式。26ai 开始官方明显把交付方式往模块化方向推安装包里出现了更多的独立组件目录有些功能组件甚至可以单独部署、单独打补丁。这对脚本来说意味着解压后的目录校验逻辑不能只盯着主安装程序还得检查关键组件目录是否存在否则静默安装进行到一半会报找不到组件文件。另外补丁机制变化也比较大。26ai 建议在安装前把最新的 Release UpdateRU补丁集成到安装介质里而不是装完再打。脚本里最好加入一个可选的补丁集成阶段自动检测补丁包并调用opatch apply完成集成。这一步我强烈建议做成可配置项因为下载补丁需要时间和磁盘空间不是所有环境都需要做成硬性要求反而会拖慢部署速度。2.2 响应文件格式的兼容性差异Oracle 26ai 的静默安装仍然支持响应文件方式这也是脚本自动化的基础。但实际对比后我发现26ai 响应文件的注释和关键字命名习惯和 19c/21c 差别不小。旧版本里配置 Oracle 基目录用的关键字是oracle.install.db.ORACLE_HOME这类写法26ai 新增了面向 AI 功能组件的配置段落如果不设置这些段落默认值也能用但日志里会刷出一堆optional value not specified的提示对排查真实错误干扰非常大。我这次的兼容做法是不直接用散落的配置片段拼响应文件而是用模板 变量替换的方式生成。模板文件里把所有相关关键字都写清楚默认值留空或给一个合理的初始值脚本里通过sed或envsubst把实际值填进去。这样一来旧脚本里最容易被改乱的引号转义路径空格问题就集中到模板里处理一处逻辑清晰很多。2.3 系统依赖与内核参数的适配策略26ai 对系统的要求与过去相比有几个新的关注点。首先是glibc 版本低于某个基线版本直接装不上这个建议在脚本前置检查里做硬校验别等到runInstaller跑起来才报错。其次是共享内存相关内核参数因为 26ai 的某些内存管理特性变化kernel.shmmax和kernel.shmall建议值有调整如果你的环境里跑着其他数据库或中间件改之前最好确认一下不会互相影响脚本里对应改成检测当前值并给出建议值提示而不是简单粗暴地直接覆盖。还有一个在老版本里不那么重要、但 26ai 开始特别明显的是透明大页设置。文档里明确建议关闭透明大页以避免性能抖动脚本检测到/sys/kernel/mm/transparent_hugepage/enabled的值是always时会给出警告但我也遇到过某些云环境的内核不支持直接修改的情况所以这里做成尽力而为警告提示的双轨策略更稳。2.4 选择脚本兼容而非完全重写的理由有人可能觉得既然变化这么大还不如用新方案完全重写。我为什么坚持在旧脚本上升级根本原因是稳定性和成本。这套脚本已经在我们内部跑了大半年安装时踩过的坑、处理过的边界情况都沉淀在代码里了。完全重写意味着那些处理逻辑要重新验证风险反而更高。升级的过程中我只动了必须动的部分响应文件生成模块、环境检查模块、新的日志规范和验证模块其余如基础目录规划、用户创建、权限设置等逻辑保留原样。这种手术刀式的改动策略后期验证范围小出问题也容易定位。3. 一键安装脚本的核心实现拆解3.1 脚本的整体框架设计我把整个安装脚本拆成了四个阶段每个阶段对应一个函数或独立脚本文件这样便于维护和排错pre_check检查操作系统版本、glibc、磁盘空间、内存、CPU、依赖包、用户是否存在、端口是否被占。prepare_env创建用户和目录、设置权限、配置内核参数、补丁集成可选、生成响应文件。run_install调用runInstaller静默安装并自动跟踪安装日志判断是否完成。post_install执行 root.sh、配置环境变量、执行验证 SQL 脚本、输出安装总结。为了让日志更清晰每个阶段都有独立的日志文件并且在关键动作前后打上特殊的标记行比如[PRE_CHECK]、[RUN_INSTALL]。后面排查问题的时候可以直接按标记过滤日志不用在几千行输出里大海捞针。这里给出一段框架代码你会发现核心思路就是阶段隔离 状态机#!/bin/bash # 一键安装脚本主入口兼容 Oracle 26ai set -o pipefail export LC_ALLC LOG_DIR/var/log/ora_install mkdir -p ${LOG_DIR} do_pre_check() { echo [PRE_CHECK] start # 具体检查逻辑聚合 bash /opt/scripts/modules/pre_check.sh } do_prepare_env() { echo [PREPARE] start bash /opt/scripts/modules/prepare_env.sh } do_run_install() { echo [INSTALL] start bash /opt/scripts/modules/run_install.sh } do_post_install() { echo [POST] start bash /opt/scripts/modules/post_install.sh } main() { do_pre_check || { echo pre_check failed; exit 1; } do_prepare_env || { echo prepare_env failed; exit 1; } do_run_install || { echo install failed; exit 1; } do_post_install || { echo post_install failed; exit 1; } echo ALL DONE } main $你没看错主入口就这么简单。复杂的逻辑都在模块文件里这样做最大的好处是出现问题后不需要读整个脚本直接定位到失败模块。之前老版本有一个 700 多行的单文件脚本一旦报错排查成本非常高这次升级也算是顺手把架构重整了。3.2 环境检测模块的升级细节环境检测模块是升级的重点。26ai 对系统的要求比以前更高不能只检测有没有、够不够还要检测版本对不对、类型对不对。我加了几个比较关键的检查项给你参考操作系统版本识别以前很多脚本喜欢用cat /etc/redhat-release来识别系统但这在非 RedHat 系发行版上会直接失效。我这次改成优先读取/etc/os-release这个文件是 Linux 发行版通用的标准接口里面的ID、VERSION_ID字段基本够用。识别出系统后再决定接下来用yum、dnf还是zypper来装依赖包。# 读取操作系统信息 OS_ID$(awk -F /^ID/{print $2} /etc/os-release | tr -d ) OS_VERSION$(awk -F /^VERSION_ID/{print $2} /etc/os-release | tr -d ) echo Detected: ${OS_ID} ${OS_VERSION} # 根据系统类型选择包管理器 case ${OS_ID} in rhel|centos|ol) PKG_MGRdnf ;; sles) PKG_MGRzypper ;; ubuntu|debian) PKG_MGRapt-get ;; *) echo Unsupported OS: ${OS_ID} exit 2 ;; esac依赖包检查依赖包检查这里旧脚本的做法是rpm -q一个个包去试包少了看报错也不直观。这次升级我改成写一个清单文件明确列出 26ai 需要的核心包和对应的正则模式循环检查并一次性汇总输出缺失包列表。用户拿到的是完整的缺失清单不是挨个报错。这里有个很值得说的点检测用rpm -q但安装要交给包管理器。因为rpm -q只能判断装没装有些包虽然装了但版本太老需要升级这时候yum install或dnf install会自动解决依赖和升级比手动rpm -Uvh处理依赖简单得多。内核参数检测内核参数检测不追求必须改而是做基线检查建议修正。分类处理的好处是不会因为个别参数不达标就中断整个安装流程。比如fs.file-max在老环境里被调低过脚本直接改可能和业务冲突所以脚本里给出建议值 patch 文件让用户确认。# 实际代码节选 declare -A KERNEL_PARAMS KERNEL_PARAMS[kernel.shmmax]68719476736 KERNEL_PARAMS[kernel.shmall]4294967296 KERNEL_PARAMS[fs.file-max]6815744 KERNEL_PARAMS[fs.aio-max-nr]1048576 failed0 for key in ${!KERNEL_PARAMS[]}; do curr$(sysctl -n ${key} 2/dev/null) if [ -z ${curr} ]; then echo Missing kernel param: ${key} failed1 continue fi # 这里只输出检测结果具体是否修改在 prepare 阶段处理 echo CHECK: ${key} current${curr} expected_min${KERNEL_PARAMS[$key]} done3.3 响应文件准备模板化思路最省心响应文件这块是这次改动的重头戏。Oracle 的静默安装响应文件本质上就是一堆变量赋值难点在于不同版本的变量名和选填项不一样。老脚本里我见过有人用正则替换的方式去改响应文件结果替换完文件格式错乱直接报废。模板化是更稳妥的路线。我这次维护了一个db_install_26ai.rsp.tmpl模板文件里面的占位符风格统一为__ORACLE_BASE__这种双下划线包裹形式oracle.install.responseFileVersion/oracle/install/rspfmt_dbinstall_response_schema_v26_0 oracle.install.optionINSTALL_DB_SWONLY oracle.install.db.ORACLE_HOME__ORACLE_HOME__ oracle.install.db.ORACLE_HOME_NAMEOraDB26Home1 oracle.install.db.ORACLE_BASE__ORACLE_BASE__ oracle.install.db.installEditionEE oracle.install.db.OSDBA_GROUPdba oracle.install.db.OSOPER_GROUPoper oracle.install.db.OSBACKUPDBA_GROUPbackupdba oracle.install.db.OSDGDBA_GROUPdgdba oracle.install.db.OSKMDBA_GROUPkmdba oracle.install.db.OSRACDBA_GROUPracdba oracle.install.db.CLUSTER_NODES oracle.install.db.CLUSTER_NODES_LIST oracle.install.db.isRACOneInstallfalse oracle.install.db.ConfigureAsContainerDBfalse oracle.install.db.config.PDBName oracle.install.db.config.installTypeRACONLY渲染脚本只需要做简单的变量替换避免直接在运行时拼接大段内容# 渲染响应文件模板 render_rsp() { local tmpl$1 local out$2 local k v while IFS read -r line; do while [[ $line ~ __[A-Z_]__ ]]; do k${BASH_REMATCH[0]} v${!k} line${line//$k/$v} done echo $line $out done $tmpl }这个思路的好处是模板清晰可见任何关键字变更都只需要改模板文件而且变量定义可以显式地放在脚本里统一管理不会散落在各个函数里。如果后面 Oracle 又出新版本最大可能就是新增一个模板文件脚本主体逻辑基本不动。3.4 安装过程与日志跟踪的优化runInstaller静默安装启动后并不是所有输出都会同步写到终端很多关键信息会进日志文件。以前我们经常遇到的情况是脚本卡住半天没反应原因是runInstaller在等待某个后台动作完成而前台脚本已经退出了。这个问题的根因是没有正确处理安装进程的父子关系。解决办法是使用wait或轮询日志关键字。我采用的方案是启动runInstaller后使用循环每秒检查一次安装日志里是否出现 Successfully 或 FATAL 关键字如果超时比如 30 分钟还没结果就手动杀掉进程并报错。这个办法比单纯wait更直观因为能看到实时进度。# run_install.sh 核心逻辑 ./runInstaller -silent -responseFile ${RSP_FILE} -ignoreSysPrereqs \ -showProgress -logLevel fine ${LOG_DIR}/run_installer.log 21 INSTALL_PID$! timeout1800 elapsed0 while [ ${elapsed} -lt ${timeout} ]; do if grep -q Successfully ${LOG_DIR}/run_installer.log; then echo install succeeded after ${elapsed}s break fi if grep -q FATAL ${LOG_DIR}/run_installer.log; then echo install failed after ${elapsed}s tail -100 ${LOG_DIR}/run_installer.log exit 1 fi sleep 5 elapsed$((elapsed 5)) done wait ${INSTALL_PID}注意这套方案要求日志文件路径在设计时就要固定并且runInstaller的输出不能和主脚本日志混在一起否则 grep 时容易误判。我在环境准备阶段就把日志目录权限设置成 oracle 用户可写根因是runInstaller有时需要通过指定用户权限写入日志。4. 实测过程与关键参数解析4.1 环境准备阶段哪些参数最容易被忽略实测过程中我发现很多初次运行脚本失败都是环境准备阶段参数遗漏造成的不是安装本身的问题。最常见的包括swap 空间设置Oracle 26ai 对 swap 有建议值但测试环境经常配的 swap 太小或者没配。脚本里我加了一个判断如果物理内存大于某个阈值且 swap 不到物理内存的一定比例就给出明确警告。但注意这个检查只做提示不做自动修改因为自动改 swap 可能导致系统服务重启风险太大。oracle 用户的环境变量ORACLE_HOME、LD_LIBRARY_PATH这类变量在交互式安装里是安装完成后自动配置好的但静默安装脚本必须自己处理post_install阶段的环境变量导出。更隐蔽的问题是.bashrc里的变量顺序如果PATH设置时没有把ORACLE_HOME/bin放在最前面后面执行sqlplus时可能命中了系统自带的旧版本客户端查错时非常迷惑。目录属组与权限很多人只记得创建ORACLE_BASE / ORACLE_HOME却忽略了oraInventory目录的属组设置。这个目录如果属主不对安装过程中会反复提示确认静默模式直接失败。我在 prepare 阶段用install -d -o oracle -g oinstall统一创建避免默认 umask 影响权限。4.2 响应文件几个关键配置的推荐值实测过程中我把响应文件里的几个核心参数记录一下供你直接参考注意这是基于我环境的内存配置你按实际调整配置项推荐值说明oracle.install.db.installEditionEE企业版功能最全测试环境首选oracle.install.db.ORACLE_HOME_NAMEOraDB26Home1建议保持 26 字样便于后续识别oracle.install.db.OSDBA_GROUPdba与 create user 阶段保持一致oracle.install.db.ConfigureAsContainerDBfalse测试环境不建 CDB/PDB 节省资源oracle.install.db.installTypeRACONLY单机或 RAC 场景差异大需要对应修改这里特别说下installEdition。如果是测试环境CPU 核数或内存不够大时标准版授权范围下的资源占用会更低但很多新特性只在 EE 下支持。26ai 的 AI 功能组件大多数也依赖 EE 版本。我建议测试环境和正式环境都保持EE避免测试时好好的一上生产发现功能缺口的尴尬。4.3 从执行到完成的全过程实录为了让你对整体执行过程有个直观感受我把一次真实执行的日志时间线简化后贴出来关键信息做了打码$ bash oracle_install_26ai.sh --silent [PRE_CHECK] OS: rhel 9.4, glibc 2.34, arch x86_64 [PRE_CHECK] Memory: 32GB, Swap: 16GB [PRE_CHECK] Disk /u01: 200GB available, OK [PREPARE] creating oracle user... [PREPARE] configuring kernel params... [PREPARE] generating response file: /tmp/db_install_26ai.rsp [INSTALL] ./runInstaller -silent -responseFile /tmp/db_install_26ai.rsp [INSTALL] progress: 5%... [INSTALL] progress: 42%... [INSTALL] progress: 100% [INSTALL] Successfully installed software [POST] executing /u01/app/oracle/product/26ai/root.sh [POST] checking sqlplus ... [POST] sqlplus / as sysdba connected OK [POST] Oracle base and home verified ALL DONE整个流程在配置合理的服务器上大约 25 到 35 分钟完成其中runInstaller期间主要是解压和写入二进制文件CPU 和磁盘 IO 占用较高。如果你的机器磁盘速度偏慢时间会拉长但脚本机制不受影响。4.4 安装后验证环节为什么比安装本身更重要脚本装完了怎么确认装得没问题我见过太多人装完就跑sqlplus看一眼版本号就以为完事了实际上问题往往藏在意想不到的地方。我这次在post_install阶段加了三个层面的验证软件版本验证执行sqlplus -v检查二进制是否可以正常启动确认没有链接库缺失。目录结构验证检查$ORACLE_HOME下关键子目录、$ORACLE_BASE下日志目录是否存在并可写避免后续运维时找不到路径。最小连通性验证启动实例到 nomount 阶段并确认alert_log正常生成。这一步虽然耗时多一些但能发现不少环境配置问题比如监听配置错误、共享内存过小等。验证完再关掉实例即可不影响后续正式建库。这个环节我建议做成默认开启、可以跳过的形式。比如加一个--skip-verify参数满足偶尔需要快速部署的场景但默认情况下一定要跑完验证防止交付一个看起来装上、实际没法用的库。5. 常见问题与排查技巧实录5.1 我在这轮升级中踩过的三个典型坑坑一响应文件里的斜杠和转义第一次生成响应文件时我用了一个外部变量拼接的方式里面存的是路径末尾带不带/。结果ORACLE_HOME变量被渲染成/u01/app/oracle/product/26ai//双斜杠在 Linux 路径里不影响,但runInstaller做路径校验时直接判定为非法路径报错信息却很隐晦只说 path check failed。后来我把模板渲染脚本改成了严格的按__变量__替换并在变量定义阶段就把末尾/统一 strip 掉再也没出现过这种问题。建议你也关注一下路径拼接时末尾斜杠的处理。坑二-ignoreSysPrereqs参数要不要加官方文档里不建议在生产环境使用这个参数因为它会跳过系统要求检查可能导致安装到一半失败。但测试环境里一些云镜像自带的内核参数和官方基线差别较大不加的话根本走不到安装阶段。我的做法是把这个参数做成可选默认不加但脚本里预留了--force开关明确提示跳过系统预检可能导致后续失败由使用的人根据环境决定。在受控测试环境里加这个参数的确能减少不必要的重试。坑三日志文件权限导致的假死有一次脚本跑在root用户下runInstaller也可能是 root 执行的但日志目录的属主是 oracle导致runInstaller无法写入日志表现为进程卡住了但 CPU 占用很低。排查了半天才发现/var/log/ora_install的权限是 755 且属主不是 oracle。后来我统一把日志目录属主改成 oracle、权限 775并在脚本开头加了一个检查如果当前用户不是 oracle 且日志目录不可写直接报错退出。这种假死比直接报错更消耗排查时间你应该引以为戒。5.2 问题速查表下面这张表是我把这轮升级过程里遇到的各种问题汇总成的速查表涵盖现象、可能原因和解决办法你以后排查时可以直接对照现象可能原因解决办法runInstaller启动后迅速退出响应文件路径错误或格式非法用-printrecovery或检查oraInstall*.log确认响应文件关键配置安装进度卡在 60% 左右不动磁盘空间不足或日志目录不可写查看installActions.log位置确认实际可用空间调整目录权限sqlplus提示libclntsh.so缺失LD_LIBRARY_PATH未配置或配置顺序错误检查$ORACLE_HOME/lib是否在库路径中重新导出变量并sourceroot.sh执行报权限错oraInventory 属组不对用oui方式修复oraInst.loc内容或重跑 root.sh验证阶段nomount失败共享内存参数过小调整kernel.shmall和kernel.shmmax后重启实例或重启机器响应文件提示未知关键字版本模板没对齐确认使用的模板是 26ai 对应的rspfmt_dbinstall_response_schema_v26_0这张表和官方文档去重过的区别在于每一条都是我在实际执行中遇到过的状态不是从文档里抄来的理论情况。如果你在操作中遇到表里没覆盖的问题建议先看installActions日志里的 stack trace 部分那才是 Oracle 自己记录的完整错误链。5.3 失败重试与幂等性设计脚本自动化的一个核心难题是失败后能不能安全重跑。如果第一次跑到一半失败了第二次再跑脚本怎么确保不会在重复创建用户或目录时出错我这次的方案是在关键动作前都做存在性判断已经存在的就跳过或复用不存在的才创建。比如# 用户存在则跳过创建 if id oracle /dev/null; then echo user oracle exists, skip else useradd -u 54321 -g oinstall -G dba oracle fi目录创建同理用mkdir -p而不是纯mkdir这样即使目录已经存在也不会报错。响应文件每次执行前重新生成覆盖旧文件避免残留参数影响。这套幂等设计让重跑变得很安全最多是之前失败的步骤再执行一遍而不会把环境搞乱。5.4 一个值得单独说明的排查技巧分段截断日志静默安装失败的日志往往非常长几千行甚至上万行。真正常见的报错其实就集中在最后几百行但问题在于前面可能有一些 warning 是误导性的。我的经验是用关键字定位而不是看日志尾部# 过滤出 ERROR 和 WARNING 关键行 grep -n -E ERROR|WARNING|SEVERE|FATAL installActions.log | tail -50如果输出里出现了 INFO: ******** 这类官方自带的间隔线那说明你可能错把 INFO 当错误了。Oracle 日志里有个习惯真正致命错误的关键字通常包含SEVERE或FATAL而ERROR有时只是某个可选组件校验没通过不影响整体安装。理解和适应这个日志风格能帮你少走很多弯路。6. 从升级脚本延伸到运维自动化的几点体会坦白说写这个脚本的初衷只是为了应付一次安装任务但做完之后的最大收获是自动化工具的生命力在于维护成本而不是初始复杂度。一个脚本如果只在某一个人手下能跑通换个人换个环境就各种报错那本质上和手工安装也没太大区别。所以我这次刻意在脚本里加了很多输出版本信息、输出关键参数值、输出每个阶段耗时这类辅助输出这些内容看着不起眼但对维护者了解脚本状态非常有价值。另外脚本升级过程中我深刻体会到文档的重要性。Oracle 26ai 的安装文档里其实已经写得很清楚了只是东西太多翻起来费劲。我把响应文件的每个关键字含义、每个检查项的阈值来源都注释到了模板和脚本里这样三个月之后我再看这段代码不需要把官方文档重新读一遍。这个好习惯也建议你养成脚本里的注释不是写给别人看的更多是写给未来的自己看的。最后提醒一句自动化脚本能解决装得上的问题但解决不了装得对的问题。版本选择、目录规划、参数调优这些还是要靠人对业务的理解。脚本是帮手不是决策者。希望这篇升级记录能给你带来一些启发少踩几个我踩过的坑。
