深度学习-卷积神经网络-基于VGG16模型, 实现猫狗二分类(文末附带数据集下载链接, 长期有效)
2026/9/7 9:34:59
简介：针对Oracle 11g第二版（11.2.0.4）的季度补丁包，适配64位Linux系统，面向数据库管理员及运维工程师，用于修复已知漏洞、增强安全性并提供性能优化。压缩包约100.6MB，内含补丁二进制文件与XML检索清单，通过该清单可核对补丁适用性、依赖关系及安装指引，便于快速识别补丁内容。此补丁对应2016年10月18日发布的11.2.0.4.161018版本，涵盖自动存储管理（ASM）、实时应用集群（RAC）、数据加密与高级压缩等企业级特性的问题修复，对保持生产环境安全高效运行至关重要。读者可借此掌握Oracle季度补丁的维护节奏、Opatch工具的验证与回滚思路，以及应用前备份、兼容性检查、停机规划等关键注意事项。目前已有264人学习，适合需要定期为数据库环境应用关键更新的中高级DBA参考。 做DBA这些年，Oracle补丁包见过不少，但每一个文件名都有固定套路。比如你手里现在这个p24006111_112040_Linux-x86-64.zip，别急着解压，先把文件名拆开读一遍，能省下后面一大半的折腾。这篇文章就是来聊聊这种补丁包到底怎么回事，从下载、校验、解压到打补丁、踩坑，一步步给到你，适合正在维护Oracle 11.2.0.4环境的运维和DBA参考。
1. 先看懂这个文件名，再决定要不要装
1.1 文件名不是乱码，是补丁身份证
p24006111_112040_Linux-x86-64.zip这一串字符，拆解下来信息量很大：
p开头代表 patch，Oracle的标准补丁命名习惯；24006111是补丁号，对应MOS文档中的具体补丁说明；112040表示应用版本，这里是 11.2.0.4.0，也就是Oracle Database 11g R2的最后一个大版本；Linux-x86-64是平台信息，说明这个补丁只能在64位Linux上使用；.zip是打包格式，里面通常包含补丁目录和README文件。
这种命名方式基本全行业通用，看到类似p12345678_112040_Solaris-64.zip也能立刻反应过来。补丁号很重要，它直接对应MOS上的一篇说明文档，里面写着bugs fixed、前置条件、opatch版本要求。很多人拿到zip后不搜文档直接解压，装到一半报错才回头查，效率太低。
1.2 这是哪类补丁？装在哪个环境
Oracle 11.2.0.4的补丁分为几类：PSU（Patch Set Update，季度累积补丁）、SPU（Security Patch Update，安全补丁）、OJVM PSU（Java虚拟机补丁）、单个临时补丁（One-off Patch）等。从命名看，p24006111是一个具体的补丁号，具体是PSU还是OJVM要看MOS文档和README。建议去支持站点搜一下这个补丁号，搞清楚它属于哪一类、解决了哪些问题。
确认补丁类型后，还得明确安装范围。补丁可能涉及数据库软件（DB）、集群软件（GI）、客户端（Client）或者ASM实例。不同组件安装方式不一样，DB补丁和GI补丁不能混打。拿到zip后，先看是第一级目录是Database、Grid Infrastructure还是Client，再决定下一步。装错了环境，轻则报冲突，重则把集群软件搞坏，这个锅可不小。
2. 下载前把环境摸透，省得后面手忙脚乱
2.1 需要哪些前置信息
很多人在补丁下载下来以后就慌慌张张开始打，结果前置条件没查，打到一半流程卡死。打补丁前，至少要把下面几项摸清楚：
- 当前数据库版本：
SELECT * FROM v$version;，确认是大版本11.2.0.4； - OPatch版本：在
$ORACLE_HOME/OPatch下执行./opatch version，需要和补丁要求的opatch最低版本做比较； - 当前已安装的PSU或补丁列表：
$ORACLE_HOME/OPatch/opatch lsinventory，避免和已有补丁冲突； - 磁盘空间：安装目录和ORACLE_HOME所在分区至少要有补丁包大小的2到3倍空间。补丁安装过程会产生备份和日志，空间不够会直接报错；
- 数据库是否RAC环境：RAC环境打补丁更复杂，需要滚动更新，不能直接一台全装完再装另一台。
这些信息建议整理成一个表格记录下来。尤其要检查OPatch版本，11.2.0.4的补丁更新很频繁，老版本OPatch经常无法识别新补丁，报错信息会写在opatch apply的日志里，但查起来很费劲。
2.2 补丁包里有啥，先读README
p24006111_112040_Linux-x86-64.zip解压后，通常会看到以补丁号命名的目录，目录里一般有：
README.txt或README.html：这是最关键的文件，里面写了补丁安装步骤、前置条件、需要停哪些服务、是否需要执行SQL脚本；files目录：实际的补丁文件；etc、patch等子目录：脚本和配置。
建议先看README，不要跳过。一个补丁包几千行说明，挑重点看：前置opatch版本、是否需要turn off DST updates（时间戳更新）、是否建议与某个补丁一起装、安装过程中是否需要所有实例都关闭。我见过有人不看README直接执行opatch apply，结果提示补丁要求某个前序补丁已装，只能回滚重来。README里的注意事项往往是前人踩坑后的总结，别跟自己的生产环境过不去。
3. 解压和升级Opatch，很多坑都在这两步
3.1 解压的正确姿势
在Linux上解压zip包，第一反应是unzip。但要注意几点：
# 先创建单独的目录，避免解压内容散落 mkdir -p /u01/software/patch cd /u01/software/patch # 上传zip包后检查MD5 md5sum p24006111_112040_Linux-x86-64.zip # 核对官方MD5值后再解压 unzip -q p24006111_112040_Linux-x86-64.zip-q参数可以少刷屏，避免终端缓冲太长。解压完成后一定要看目录结构，确认补丁号目录存在。有些zip包自带的README是在最外层，解压后先看它。如果解压报cannot find zipfile directory，大概率是上传过程中文件损坏，重新用二进制模式上传。很多人用FTP或scp的时候用了ASCII模式，文件传完表面没问题，一解压就废。
另外，解压的目录不能放在ORACLE_HOME内部或分区空间小的位置，补丁安装时会把整个补丁目录作为输入，空间不足又会报错。最好单独放/u01/software这样的独立目录。
3.2 升级Opatch环境
Opatch版本过低会导致补丁apply失败，而且失败原因很隐晦，日志里可能只写Prerequisite check failed。为了避免这种无谓报错，建议每次打重要补丁前，都从支持站点下载最新的OPatch版本，覆盖到$ORACLE_HOME/OPatch。
注意：更新OPatch之前，最好备份原来的OPatch目录：
cp -rp $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak_$(date +%Y%m%d)覆盖opatch时，需要先确认当前用户有权限写入ORACLE_HOME。如果是root安装的Oracle，还需要用root用户或授权DBA组用户。覆盖完成后执行：
$ORACLE_HOME/OPatch/opatch version确认版本号高于README要求。这一步很基础，但很多人在生产环境上吃过亏：打完补丁后，opatch lsinventory查看补丁信息都正常，但是因为opatch版本不对，实际补丁文件没有正确写入，数据库版本显示有补丁，内部组件却还是旧状态。所以我的习惯是：补丁前先升级opatch，再打补丁。
4. 补丁安装实操记录
4.1 标准apply流程
以单机数据库环境为例，打完补丁前的准备，补丁apply的流程大概是：
# 1. 设置环境变量 export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export ORACLE_SID=orcldb # 2. 停止监听和数据库 lsnrctl stop sqlplus / as sysdba SQL> shutdown immediate; SQL> exit # 3. 进入补丁目录执行apply cd /u01/software/patch/24006111 $ORACLE_HOME/OPatch/opatch apply # 4. 看到apply complete后，重新启动数据库 sqlplus / as sysdba SQL> startup; SQL> exit lsnrctl start执行opatch apply时，它会先做一系列系统检查，包括环境变量、补丁冲突、空间大小等。如果卡在某个阶段，不要立刻干预，看日志。默认日志在$ORACLE_HOME/cfgtoollogs/opatch/opatch.log和当前目录下自动生成的*.out文件。
启动数据库后，还要按README要求执行必要的SQL脚本。有些补丁安装后需要执行类似：
cd /u01/app/oracle/product/11.2.0/dbhome_1 sqlplus / as sysdba @?/rdbms/admin/catbundle.sql PSU apply这一步经常被遗漏，导致补丁虽然显示已安装，但数据字典版本没升级。执行SQL脚本前要确保数据库真正open，且有足够的undo空间，脚本跑完可能需要几分钟。
4.2 常见安装模式差异
RAC环境的补丁安装和单机差别很大。单机是所有组件都停下直接更新，RAC则需要滚动更新（rolling patch），逐个节点操作。如果你的环境是RAC，opatch apply时会有提示，支持滚动的补丁也会在README里注明。操作时先在节点1上让实例1运行，关闭实例2，在节点2上打补丁，再切回来。整个流程要配合集群资源状态检查。
另外，如果是GI补丁（Grid Infrastructure），不能用数据库的ORACLE_HOME下的opatch，要去GI home下执行。很多人打完数据库补丁发现集群补丁没打，其实是因为跑错了opatch。在ORACLE_HOME和GI_HOME并存的环境，补丁要分别apply，不能混。
还有一种情况是Oracle Client补丁。如果你只在应用服务器上装了Instant Client或完整客户端，补丁包里的Client目录就是给它的。客户端补丁可以不关数据库，但需要断开现有连接，更新后重新配置tnsnames和环境变量。这个容易忽略，因为客户端补丁不在opatch lsinventory的数据库补丁列表里显示，但生产环境经常因客户端旧导致SQL执行计划问题。所以运维要记住：补丁要覆盖到所有安装Oracle组件的机器，不能只盯着数据库服务器。
5. 安装后验证与问题排查实录
5.1 验证补丁是否生效
打完补丁不是说看到opatch apply succeeded就完事了。我的验证三连：
# 1. 查看补丁是否在list里 $ORACLE_HOME/OPatch/opatch lsinventory | grep -i 24006111 # 2. 查看数据库组件版本 sqlplus / as sysdba SQL> select * from registry$history; # 3. 检查alert日志和监听状态 tail -100 $ORACLE_HOME/diag/rdbms/orcldb/orcldb/trace/alert_orcldb.logopatch lsinventory显示的是软件层面的补丁记录，registry$history显示的是数据库内部的补丁应用记录。两个地方都有，才说明补丁真正生效。如果软件显示有补丁，但registry$history没有对应记录，那基本可以判断SQL脚本没跑或者没跑完。
另外提醒一句：如果执行opatch lsinventory时出现Inventory check failed，说明Central Inventory损坏或权限有问题。遇到这种情况别慌，先检查/etc/oraInst.loc指向的目录是否存在，当前用户是否有读写权限。很多时候是root跑过opatch导致文件owner变成root，DBA用户无法读取。处理方法就是确保环境变量统一，用同一用户执行所有补丁命令。
5.2 我踩过的坑和排查清单
打补丁这些年，遇到的坑不少，挑几个印象深的：
第一个坑：空间不足。生产环境ORACLE_HOME所在分区可能因为归档日志或者trace文件已经是90%占用，补丁包解压和apply又很吃空间，一中间就报No space left on device。最好在 apply 前用df -h检查，至少留出20GB空闲。如果空间实在不够，可以把补丁放在临时目录，加-invptl参数指向别的Inventory，但这条路其实更麻烦，不如提前清理日志。
第二个坑：环境变量混乱。机器上有多个ORACLE_HOME或多个环境的用户，opatch默认用的是当前生效的ORACLE_HOME，如果PATH里先加载了旧的ORACLE_HOME，明明补丁打到了另一个环境，检查时发现没打上。每次打补丁前必须echo $ORACLE_HOME确认环境变量指向正确。还要检查which opatch，确保用的是带系统权限的哪个OPatch。
第三个坑：补丁冲突。比如以前手动打过某个one-off补丁，新的PSU可能包含相同修复，导致冲突。opatch apply会直接拒绝。解决方法是用opatch conflict查看冲突补丁，在确认业务允许的情况下，先把旧补丁rollback掉，再打新补丁。这步一定要评估，不能瞎回滚，否则可能出现修复回退，引发旧bug复发。
第四个坑：应用服务器客户端补丁未更新。某个系统数据库打了新版PSU，但应用服务器上的客户端还是老版本，结果新特性或修复无法在客户端体现，甚至出现ORA-28040之类的版本不匹配。所以补丁方案要包含所有中间层。
我在项目实施中会把常见问题整理成一张速查表，分享给大家参考：
| 问题现象 | 可能原因 | 排查/解决方法 |
|---|---|---|
| 解压报错或文件损坏 | 上传方式错误、文件不完整 | 用md5sum比对官方MD5，用二进制模式重新上传 |
| opatch apply前置检查失败 | 环境变量错、缺少前序补丁、opatch版本过低 | 检查echo $ORACLE_HOME，升级opatch，查阅README前置要求 |
| 补丁已装但数据库内部版本未更新 | 未执行SQL脚本 | 检查registry$history，运行README要求脚本 |
| 空间不足、apply中断 | 日志和备份占满 | 清理归档和日志，确保至少空闲20GB |
| RAC节点补丁版本不一致 | 未逐个节点滚动apply | 逐个节点检查lsinventory，按README滚动节点更新 |
opatch lsinventory提示Inventory损坏 | 权限错误或Central Inventory受损 | 检查oraInst.loc指定目录权限，必要时用root reset inventory |
这张表基本覆盖了日常打补丁的主要风险点，但遇到具体报错还是要结合日志看。opatch日志文件路径在$ORACLE_HOME/cfgtoollogs/opatch/下，报错信息一般会给出详细原因。不要一报错就直接回滚，先看日志能省不少事。
最后再说两句经验
补丁这活儿，做得越多越觉得“稳”字最重要。我个人的习惯是，任何补丁先到测试环境完整跑一遍，记录所有输出和报错，再考虑生产。生产打补丁前，数据库的物理备份一定不能少，哪怕有RAC有DG，备份也是底线。补丁打完后，别急着走，观察一段时间数据库日志，确认没有新错误再宣布完成。另外，补丁zip包和README我建议保留在软件目录中，后续排查问题还能溯源。打补丁这件事，细节决定成败，多一份谨慎就少一份事故。
本文还有配套的精品资源，点击获取