4. Oracle软件安装与补丁策略
在生产环境中，Oracle软件的安装与补丁管理是DBA最基础也最容易出问题的环节。图形化OUI虽然直观，但在批量部署、远程机房、无图形界面的Linux服务器上，静默安装才是标准做法。本节围绕OUI静默安装Grid Infrastructure与Database软件，以及OPatch、RU、PSU补丁的评估与回退展开。
一、静默安装的核心：响应文件
OUI静默安装的本质是用一个响应文件（response file）替代交互式输入。响应文件分为两类：安装响应文件（如grid_install.rsp、db_install.rsp）和配置响应文件（如netca.rsp、dbca.rsp）。安装前必须用runInstaller -record -destinationFile录制一份模板，再根据实际环境修改，而不是从零手写。
以Grid Infrastructure 19c为例，关键参数包括：oracle.install.option=CRS_CONFIG、ORACLE_BASE=/u01/app/oracle、INVENTORY_LOCATION=/u01/app/oraInventory、oracle.install.asm.diskGroup.name=OCR、oracle.install.asm.diskGroup.redundancy=NORMAL、oracle.install.asm.diskGroup.disks=/dev/asm-ocr1,/dev/asm-ocr2,/dev/asm-ocr3、oracle.install.crs.config.clusterNodes=rac1:rac1-vip,rac2:rac2-vip、oracle.install.crs.config.networkInterfaceList=eth0:192.168.1.0:1,eth1:10.0.0.0:5。这些参数一旦写错，安装会在root.sh阶段失败，回退成本很高。
Database软件安装响应文件相对简单，核心是oracle.install.option=INSTALL_DB_SWONLY、UNIX_GROUP_NAME=oinstall、oracle.install.db.InstallEdition=EE、oracle.install.db.OSDBA_GROUP=dba、oracle.install.db.OSOPER_GROUP=oper。安装完成后用dbca -silent建库，或用dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbName orcl -sid orcl -sysPassword ...完成实例创建。
./runcluvfy.sh stage -pre crsinst -n rac1,rac2 -verbose做集群预检查，把内核参数、用户限制、共享存储权限、时间同步等问题提前暴露，避免安装中途失败。二、补丁体系：OPatch、RU与PSU的关系
Oracle从12c开始推行RU（Release Update）和RUR（Release Update Revision），取代了早期的PSU（Patch Set Update）。RU是季度累积补丁，包含自上一个RU以来的所有修复；RUR是在RU基础上针对特定高优先级问题的补充。PSU在11g时代是季度补丁，12c之后逐步被RU替代，但部分老系统仍在用。
OPatch是补丁的安装工具，本身也需要定期升级。补丁评估的核心是冲突检查：用opatch prereq CheckConflictAgainstOHWithDetail -ph ./检查补丁与当前ORACLE_HOME的冲突，用opatch lspatches查看已安装补丁，用opatch lsinventory -detail查看详细清单。RU补丁通常要求先升级OPatch到指定版本，否则会报OPatch version check failed。
三、补丁评估的关键判断
拿到一个RU补丁后，不能直接opatch apply。评估要回答三个问题：能不能装、装完有什么影响、出问题怎么退。
第一，检查补丁与当前环境的兼容性。用opatch prereq CheckApplicable -ph ./确认补丁适用于当前ORACLE_HOME版本和平台。第二，检查冲突。如果之前打过one-off patch，RU可能与之冲突，需要先用opatch rollback回退one-off，或使用opatch apply -skip_conflict_check（不推荐，除非确认无实质冲突）。第三，评估停机窗口。GI的RU通常支持滚动升级，节点逐个重启，业务不中断；DB的RU需要停实例，除非使用opatch apply -online（仅限部分补丁）。
回退方案必须在打补丁之前就准备好。最可靠的回退是备份整个ORACLE_HOME：tar -czf /backup/oracle_home_before_ru.tar.gz $ORACLE_HOME。如果补丁应用失败，用opatch rollback -id <patch_id>回退；如果回退也失败，直接解压备份覆盖。注意：回退后需要重新执行root.sh（GI场景）并重启集群。
catbundle.sql）。一旦执行了数据字典升级，单纯回退ORACLE_HOME二进制文件可能导致数据库无法启动。因此，打补丁前必须做全库备份（RMAN），并确认回退窗口内可以恢复数据库。四、实操示例：19c RU补丁应用流程
假设当前GI和DB均为19.3，计划升级到19.19 RU。以下为关键命令序列（示例，实际补丁号以MOS为准）：
# 1. 升级OPatch（GI和DB的ORACLE_HOME都要做）
cd /tmp
unzip p6880880_190000_Linux-x86-64.zip -d $ORACLE_HOME
$ORACLE_HOME/OPatch/opatch version
# 2. 检查冲突
cd /tmp/19.19_RU
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
# 3. 备份ORACLE_HOME
tar -czf /backup/grid_home_before_1919.tar.gz $GRID_HOME
tar -czf /backup/db_home_before_1919.tar.gz $ORACLE_HOME
# 4. 应用GI补丁（滚动方式，节点1）
$GRID_HOME/OPatch/opatch auto /tmp/19.19_RU -oh $GRID_HOME
# 5. 应用DB补丁（节点1，需停实例）
srvctl stop instance -d orcl -i orcl1
$ORACLE_HOME/OPatch/opatch apply /tmp/19.19_RU
srvctl start instance -d orcl -i orcl1
# 6. 验证
$ORACLE_HOME/OPatch/opatch lspatches
$GRID_HOME/bin/crsctl stat res -t
sqlplus / as sysdba
SQL> select version_full from v$instance;
执行完节点1后，观察集群状态和告警日志至少30分钟，确认无异常再操作节点2。如果节点1验证失败，立即用opatch rollback -id <patch_id>回退，并恢复ORACLE_HOME备份。
五、补丁台账与版本管理
生产环境必须维护补丁台账，记录每个ORACLE_HOME的当前补丁集、上次补丁时间、回退点位置。推荐字段包括：主机名、ORACLE_HOME路径、组件（GI/DB）、当前RU版本、OPatch版本、上次补丁日期、备份文件路径、验证结果。每次补丁后更新台账，避免“这个库到底打过什么补丁”说不清楚。
补丁策略上，建议跟随Oracle季度RU节奏，但不必每个RU都打。通常选择每半年或每年打一次累积补丁，优先选择RUR（包含关键修复）。对于安全合规要求高的系统，按季度打RU；对于稳定性优先的系统，可延迟1～2个季度，观察社区反馈后再打。