不是必须，但强烈建议使用out-of-place方式；因oracle 11.2.0.x不支持in-place升级主版本，opatch apply会报错73，且out-of-place可规避rollback不可靠、内存残留、监听冲突等问题。
oracle 11gr2补丁集安装必须用out-of-place方式吗？
不是必须，但强烈建议。oracle官方对11.2.0.x的psu、bp（bundle patch）和gi补丁，已明确不支持in-place升级到新主版本（如11.2.0.3 → 11.2.0.4），opatch apply会直接报错opatch failed with error code 73。out-of-place本质是新建oracle_home，把旧环境完整迁移过去，规避了opatch rollback不可靠、共享内存残留、监听器冲突等高频故障。
常见错误现象：ORA-00845: MEMORY_TARGET not supported on this system在新OH启动时出现——因为没同步复制$ORACLE_HOME/rdbms/lib/config.c或未重运行root.sh；lsnrctl status显示监听器仍指向旧HOME路径——因listener.ora未手动更新ORACLE_HOME变量。
- 必须提前规划磁盘空间：新
ORACLE_HOME需至少等于原目录大小（含$ORACLE_BASE/diag可不复制，但$ORACLE_HOME/oc4j/j2ee等子目录不能跳过） - 停机窗口主要耗在数据文件拷贝和
root.sh执行上，而非补丁解压本身；实测1TB数据量下，冷拷贝比rman backup as copy快20%以上（因绕过归档校验） - 不要依赖
runInstaller -updateInventory自动同步OUI注册——它常漏掉grid home关联项，务必手动核对oraInst.loc和inventory.xml中HOME_LIST条目
如何最小化数据库停机时间？
核心思路是把“可并行”和“可离线”操作前置：补丁解压、opatch prereq检查、新OH权限设置、监听器配置模板准备全部在业务低峰期完成；真正停机只做最后三步：关闭实例→切换OH软链→启动实例。
使用场景：RAC环境需额外注意crsctl stop crs后，所有节点必须统一指向新ORACLE_HOME再启CRS，否则crsctl check cluster会报CRS-4639: Could not contact Oracle High Availability Services。
- 用
rsync -av --delete替代cp -r同步$ORACLE_HOME：支持断点续传，且--delete确保旧文件残留被清理（尤其$ORACLE_HOME/lib/stubs目录易因权限问题残留） - 启动前务必运行
$ORACLE_HOME/root.sh（非旧HOME路径！），否则sqlplus / as sysdba会提示ORA-12547: TNS:lost contact（因oracle二进制未正确链接libclntsh.so） - 若使用Data Guard，备库可在主库切OH前就完成补丁安装——但必须确保主备
COMPATIBLE参数一致，否则ALTER DATABASE RECOVER MANAGED STANDBY DATABASE会卡在waiting for gap
opatch auto和opatch apply哪个更安全？
opatch auto仅适用于GI+RDBMS联合补丁（如11.2.0.4 BP），且要求OS用户为root；单独给数据库打PSU必须用opatch apply。混用会导致opatch lsinventory显示补丁状态为applied but not active，后续opatch rollback失效。
参数差异：opatch apply -oh /u01/app/oracle/product/11.2.0/db_2 -id 12345678中的-id必须与补丁包内etc/config/inventory.xml的PATCH_ID严格一致，大小写敏感；漏掉-oh参数则默认作用于当前$ORACLE_HOME，极易误刷GI HOME。
- 执行前先跑
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./：能提前发现与现有补丁的冲突（如两个PSU修改同一libnnz11.so函数） - 补丁应用后立即验证
SELECT * FROM v$version和SELECT action, namespace, version FROM dba_registry_history，避免出现OPatch succeeded but database startup fails这类静默失败 - 别信
opatch query -all输出的“Active”字段——它只查inventory.xml，实际是否生效得看$ORACLE_HOME/.patch_storage下对应补丁ID目录是否存在apply_date文件
为什么补丁后监听器连不上，但tnsping能通？
典型症状：tnsping ORCL返回OK，但sqlplus scott/tiger@ORCL报ORA-12514: TNS:listener does not currently know of service requested。根本原因是监听器进程仍在旧ORACLE_HOME下运行，而新OH里的listener.ora未被加载。
性能影响：若强制用lsnrctl reload而不重启监听器，可能触发ORA-00600: internal error code, arguments: [kghfrh:ds]（内存管理bug，11.2.0.3+已知）。
- 必须用
lsnrctl stop+lsnrctl start彻底重启，不能只reload - 检查
lsnrctl status输出第一行是否显示Listening Endpoints Summary...后紧跟新ORACLE_HOME路径（如/u01/app/oracle/product/11.2.0/db_2） - RAC环境下，
srvctl config listener显示的Oracle Home字段必须与实际一致，否则srvctl start listener会静默失败
最易被忽略的是sqlnet.ora里的SQLNET.AUTHENTICATION_SERVICES值——某些PSU会重置它为(NONE)，导致操作系统认证失效，需要手工改回(NTS)或(BEQ)。
