简介这是一份适用于Linux x86-64平台的Oracle 11g R2112040补丁包面向DBA及系统运维人员用于修复Oracle数据库及相关组件的安全漏洞、性能缺陷与稳定性问题。压缩包共103个文件大小40.49MB主要包含class字节码、sql脚本、xml元数据、jar工具包以及txt说明文件其中PatchSearch.xml可辅助OPatch工具识别补丁适用性便于在既有Oracle环境中有序完成升级。目前已有262人学习下载说明该补丁在实际运维场景中有一定需求。通过该补丁包读者可定位到对应修复代码与配置变更结合Oracle官方文档完成补丁验证和部署从而提升数据库安全性与运行效率同时也能更深入理解Oracle补丁机制与OPatch操作流程。 如果你在Oracle Support上下载过数据库补丁看到p26635834_112040_Linux-x86-64.zip这种文件名一定不会陌生。这个zip包既有补丁号p26635834又有平台标识Linux-x86-64名字里的每一个字段都有实际含义。很多DBA在CentOS 7.6上安装Oracle 19c时第一步就被这个zip包卡住传上去解压报invalid zip archive: could not find eocd好不容易解出来运行opatch又报jar manifest missing最后才发现问题出在上传和解压环节而不是补丁本身。这篇文章我就从实操角度把这个zip包从下载到落地的完整过程拆开讲一遍顺便把invalid zip archive、failed to copy spatial iop zip这类报错的排查思路一并捋清楚。内容主要面向在Linux x86-64平台上维护Oracle数据库的DBA和技术运维人员对刚接触补丁管理的朋友同样适用。1. 文件名拆解p26635834、112040、Linux-x86-64分别代表什么1.1 一段补丁文件的“身份信息”拿到一个zip文件第一件事不是解压而是看懂文件名。p26635834_112040_Linux-x86-64.zip这个命名格式在Oracle官方补丁库里非常典型p26635834是补丁号。每个Oracle补丁在My Oracle Support上都有一个唯一编号后续查文档、比对手动步骤都靠它。112040是补丁包内部的版本构建标识。具体含义随补丁类型不同而不同可以理解为“同一补丁号下的一个发布物标识”。Linux-x86-64是目标平台说明这个包只能在64位Linux的x86架构上使用。哪怕看起来内容一样也不要拿它在Solaris或AIX上尝试。.zip说明它是个ZIP格式压缩包Oracle官方很多补丁都选择zip作为分发格式而不是tar.gz。实际遇到补丁时还要留意文件名里可能出现的完整版本比如19.12.0.0.0。很多DBA把p26635834和19.12混为一谈其实它们是两个维度补丁号决定“这个补丁修了什么”版本决定“这个补丁基于哪个基线”。所以下载前一定要在页面确认版本号。1.2 它属于哪一类补丁怎么跟关键版本对上以p26635834为关键字去查通常能看到这属于Database Proactive Bundle Patch或者Release Update这一类“周期性补丁”。这类补丁的作用是在一个基础版本上做月度或季度累积修复包含安全更新、回归修复和少量新功能。它和小的单次补丁one-off patch不一样。单次补丁可能只有几个文件zip包很小而p26635834_112040_Linux-x86-64.zip这种包解压后往往是一个完整目录里面包含Opatch执行脚本、修复文件、README等。因此它的应用流程也必须是“先解压再校验再opatch apply”不能像普通软件安装包一样双击运行。如果你是在CentOS 7.6上安装Oracle 19c建议先看README确定这个zip包是针对全新安装还是针对已有ORACLE_HOME的补丁。这个问题一旦搞反后面的错误会让人怀疑人生。2. 解压前的准备校验、工具和路径一个都不能少2.1 先做完整性校验别急着双击解压我在处理任何Oracle补丁包时第一件事永远是用md5sum或sha1sum做校验。Oracle Support下载页面会给出对应的checksum文件下载完成后对比一下几乎能挡住80%的“解压报错”问题。md5sum p26635834_112040_Linux-x86-64.zip sha1sum p26635834_112040_Linux-x86-64.zip输出结果和下载页面的内容一致才继续下一步。如果不一致不要试图修复直接重新下载。这里要特别提醒很多下载工具支持“断点续传”但续传过来的zip包经常出现“文件大小正确但内部字节错位”的情况。md5能查出这类问题所以校验动作一定不能省。有些朋友会问“如果Oracle页面只给了sha256怎么办”那就用sha256sum p26635834_112040_Linux-x86-64.zip道理一样。不要偷懒跳过去否则后面所有排查都建立在“地基已经歪了”的基础上。2.2 解压工具的选择Linux推荐unzipWindows避坑乱码在Linux x86-64环境上我最推荐的工具就是系统自带的unzip。原因很简单Oracle官方zip包面向的就是这种环境unzip对zip格式的兼容性最稳且命令行操作方便嵌入脚本。如果你是在Windows上下载后再传到Linux我建议不要用某些国产压缩软件直接解压更不要“解压后打成新zip再传”。压缩软件在Windows上处理zip时默认编码往往不是UTF-8可能导致Linux上中文文件名乱码。Oracle补丁包文件名基本都是英文但你自己打包的配置文件和脚本目录就很容易踩这个坑。在Linux上解压前先确认已安装unzip -v如果没有CentOS/RHEL可以用sudo yum install -y unzipWindows下如果非要本地解压预览可以用7-Zip。7-Zip对zip的兼容性不错但要注意它默认按UTF-8处理文件名对某些用GBK编码打包的旧zip仍会显示乱码。所以项目文件建议在哪个平台部署就在哪个平台解压不要跨平台倒来倒去。2.3 磁盘空间和路径设计Oracle补丁zip包通常不小解压后占用空间可能是压缩包的2到3倍。一个本地备份的ORACLE_HOME动辄几十GB补丁目录也一样。所以我建议df -h /u01确认目标分区至少有zip包大小3倍以上的空闲空间。不要解压到/tmp除非你确认/tmp空间充足。我见过很多次环境因为/tmp空间不足导致解压到一半失败最后报错指向zip文件损坏其实是空间问题。路径设计也有讲究。我习惯在$ORACLE_HOME/../patch下建一个以补丁号命名的目录比如mkdir -p /u01/app/oracle/patch/26635834然后把zip包放进去解压。这样既不会污染ORACLE_HOME又方便以后回滚时找到原包。3. Linux x86-64上解压Oracle补丁包的标准流程3.1 上传阶段最容易“压坏”zip很多时候zip文件在Oracle服务器上是完好的坏在“上传”环节。如果你用FTP上传记得一定要用binary模式。ASCII模式会把字节中的某些字符做转换zip这种二进制文件一传就废。更推荐用scp或sftpscp p26635834_112040_Linux-x86-64.zip oracle192.168.1.10:/u01/app/oracle/patch/如果你是在使用rz上传也要注意终端会话是否乱码、是否人为中断。Zmodem协议本身二进制安全但终端工具实现参差不齐大文件上传时经常断流。最稳的方式始终是先用scp或wget直接拉到目标机器上。3.2 解压、权限与文件完整性复查上传完成后用Oracle用户执行unzip -q p26635834_112040_Linux-x86-64.zip -d 26635834加-q可以安静解压避免刷屏。解压完成后先看目录结构ls -l 26635834正常情况下这个目录下会有一个README或补丁说明文档。打开README里面会有补丁适用版本、前置条件、opatch版本要求。很多字段都有用值得花两分钟读。然后做一次完整测试解压验证unzip -t p26635834_112040_Linux-x86-64.zip-t参数会逐文件测试CRC校验如果哪个文件损坏这里会明确报出来。这个过程比md5还更细粒度因为它测试的是每个内部文件的完整性。如果unzip -t全绿说明zip包本身没有问题可以放心进下一步。3.3 OPatch环境准备和应用前的最后确认解压补丁包不等于应用补丁。Oracle补丁应用依赖$ORACLE_HOME/OPatch/opatch工具。补丁包里的README通常会要求最低opatch版本。用下面命令检查当前版本$ORACLE_HOME/OPatch/opatch version如果版本太低需要先去下载对应OPatch补丁先更新OPatch再应用本次补丁。顺序颠倒会有奇奇怪怪的错误。另外应用补丁前需要设置好环境变量export ORACLE_HOME/u01/app/oracle/product/19.3.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$ORACLE_HOME/bin:$PATH然后执行$ORACLE_HOME/OPatch/opatch lsinventory这个命令会显示当前ORACLE_HOME中已安装的补丁。在没有应用新补丁之前先记录一下现在的状态。截图或重定向输出都行后面验证和回滚都要对照它。4. 遭遇 invalid zip archive: could not find eocd 的完整排查链路4.1 EOCD缺失是怎么发生的invalid zip archive: could not find eocd是Java读取zip文件时的典型报错。EOCD全称是End of Central Directory中文叫中央目录结尾记录它必须位于zip文件的最末尾。可以把它理解成zip的“目录索引尾部”记录了这个zip文件包含多少个文件、每个文件在哪个偏移位置。如果文件被截断、上传不完整、受到破坏EOCD就找不到Java会直接抛这个错误。命令行里的unzip遇到同样问题会报类似End-of-central-directory signature not found。两者本质是一个问题。出现这种报错时我的第一反应不是去修复zip而是先想这个文件有没有可能根本就没传输完整4.2 一次现场排查的逐层推进假设你在scp后直接unzip -t结果出现大量CRC错误或“cannot find zipfile directory”。不要慌按下面的链路一层层查第一步看文件大小ls -l p26635834_112040_Linux-x86-64.zip对比Oracle下载页面的字节数。只要大小对不上直接重新下载。注意少几个字节也不行zip的EOCD就在那最后几十个字节里。第二步用file命令看文件头file p26635834_112040_Linux-x86-64.zip如果输出里有Zip archive data说明文件头正常。如果没有甚至连data都识别不出来说明这个“zip”很可能压根不是zip格式可能是HTML错误页面或上传工具生成的临时文件。第三步看文件尾部tail -c 100 p26635834_112040_Linux-x86-64.zip | xxd正常的zip文件末尾应该有50 4b 05 06这组十六进制签名也就是ASCII里的PK..。如果最后一段是空的或者乱码说明EOCD已经丢失或根本没写进去。第四步检查是不是上传工具的问题。最常见的是FTP的ASCII模式其次是Windows上某些工具自动修改了文件。所以排查到最后往往不是Oracle补丁坏了而是中间某个环节破坏了二进制。4.3 从zip修复到彻底解决几种可用手段如果文件大小和checksum都对但unzip还是报错可以尝试用zip -FF修复zip -FF p26635834_112040_Linux-x86-64.zip --out p26635834_112040_Linux-x86-64-fixed.zipzip -FF会扫描zip文件中仍然存在的目录项并尝试重建中央目录。对小文件的恢复有时有效但对大型Oracle补丁包成功率不高。而且即便修复成功内部文件的CRC校验也不一定通过。所以我的建议是zip -FF只能作为“死马当活马医”的尝试不能依赖它。真正高效的解决办法就一句话删掉重新下载用scp的二进制模式上传再执行md5sum校验。如果这个流程做完仍然报错那就去Oracle Support确认下载的补丁号是否正确或者更换网络环境重新下载。我排查过的大多数could not find eocd都是下载不完整或上传过程损坏真正源文件损坏的情况极少。5. 嵌入热词密码工具、乱码、资源包导入错误这类“周边坑”5.1 Oracle补丁包没有密码谨慎对待“zip密码破解工具”网上一搜“zip压缩包密码破解工具”“zip密码恢复”搜索量很大。但针对p26635834_112040_Linux-x86-64.zip这类Oracle官方补丁包完全不需要关心密码。Oracle官方补丁包下载需要的是授权账号下载后zip本身不会二次加密。如果你在某个第三方网盘上拿到一个带密码的补丁包那八成是别人重新打包过的不建议使用。我不是说zip密码恢复技术没用它是数据恢复领域的正常工具但用在这里是找错了方向。Oracle补丁包有密码本身就是异常信号合法用法是处理自己遗忘密码的备份压缩包而不是去碰来源不明的文件。5.2 中文文件名乱码和分卷压缩的问题如果你在Linux上用unzip解压一个由Windows工具打包的zip经常看到中文文件名变成????或乱码。这是因为zip压缩包里没有强制指定文件名编码为UTF-8Windows压缩软件可能用本地语言编码写入了文件名Linux的unzip按UTF-8去解自然错乱。解决办法有几个在Windows上压缩前用7-Zip选择“UTF-8”编码再打包。在Linux解压时用支持指定解压工具比如unzip -O GBK file.zip来处理古老的GBK编码。更通用的方式是用Python的zipfile库写几行脚本按实际编码解码文件名。分卷压缩的情况也一样。有些资源提供方把一个大zip拆成z01、z02、zip多个文件解压时报“必须有下列压缩分卷z01”。Oracle官方补丁包不会分卷如果出现这种提示多半是下载工具没有自动合并或者你少下了某个分卷。去下载页面把全部分卷补齐重新解压即可。5.3 failed to copy spatial iop zip 与导入资源包失败的处理思路基于搜索热词failed to copy spatial iop zip常常伴随“导入资源包失败”“与技术支持部联系”一起出现。这个问题不完全等同于Oracle补丁包解压但它本质上仍然和zip包损坏、工具错误、权限不足有关。处理这类报错我建议从三方面入手确认要导入的资源包没有被第三方工具重新压缩过尤其是不要用手机解压、再上传到服务器这种操作。看系统日志里报错的具体文件路径定位是哪个zip复制失败然后用md5sum校验源zip和操作系统上zip的完整性。如果你在WebLogic或EM平台里导入应用包尽量使用平台自带的上传解压机制而不是手动解压后复制。遇到failed to copy spatial iop zip这类信息最忌讳的是盯着那行英文反复看。把注意力转移到文件完整性和目录权限上大部分问题都能很快定位。6. 补丁应用后不能忘了的验证与回滚6.1 opatch lsinventory 看什么应用补丁不是解压完就结束了。执行完opatch apply后第一时间用opatch lsinventory验证补丁状态。看三样东西新补丁号是否出现在已安装列表里。是否显示successfully applied。OPatch工具版本是否符合预期。如果这些都对再启动数据库或做简单功能验证。千万不要“按完补丁就交差”一次补丁安装失败在几分钟内暴露和几天后暴露性质完全不同。6.2 回滚预案比安装本身更值得演练Oracle补丁支持回滚但回滚要求使用当时应用补丁时同版本的OPatch而且可能在opatch rollback -id 26635834时提示需要输入具体子补丁号。所以在应用前保存opatch lsinventory -detail输出是一个好习惯。回滚步骤不复杂但现场操作时我建议先把$ORACLE_HOME做个冷备或者至少把涉及修改的二进制文件备份到独立目录。磁盘空间多花几个GB换来的是晚上能睡着觉。我的经验是每次补丁操作都准备好一份“失败回滚清单”内容包括回滚命令、需要恢复的目录、回滚后如何验证。这份清单在真正出问题时能让自己少掉一半头发。说到最后这类p26635834_112040_Linux-x86-64.zip的文件名我现在看到的第一反应不是解压而是先想清楚它从哪里来、校验值对不对、准备落在哪个路径。哪怕再急我也会先跑一次unzip -t。这个习惯帮我挡掉了很多次无效加班。希望这篇文章能让你在下次接到补丁任务时只解压一次就成功落地。本文还有配套的精品资源点击获取
简介这是一份适用于Linux x86-64平台的Oracle 11g R2112040补丁包面向DBA及系统运维人员用于修复Oracle数据库及相关组件的安全漏洞、性能缺陷与稳定性问题。压缩包共103个文件大小40.49MB主要包含class字节码、sql脚本、xml元数据、jar工具包以及txt说明文件其中PatchSearch.xml可辅助OPatch工具识别补丁适用性便于在既有Oracle环境中有序完成升级。目前已有262人学习下载说明该补丁在实际运维场景中有一定需求。通过该补丁包读者可定位到对应修复代码与配置变更结合Oracle官方文档完成补丁验证和部署从而提升数据库安全性与运行效率同时也能更深入理解Oracle补丁机制与OPatch操作流程。 如果你在Oracle Support上下载过数据库补丁看到p26635834_112040_Linux-x86-64.zip这种文件名一定不会陌生。这个zip包既有补丁号p26635834又有平台标识Linux-x86-64名字里的每一个字段都有实际含义。很多DBA在CentOS 7.6上安装Oracle 19c时第一步就被这个zip包卡住传上去解压报invalid zip archive: could not find eocd好不容易解出来运行opatch又报jar manifest missing最后才发现问题出在上传和解压环节而不是补丁本身。这篇文章我就从实操角度把这个zip包从下载到落地的完整过程拆开讲一遍顺便把invalid zip archive、failed to copy spatial iop zip这类报错的排查思路一并捋清楚。内容主要面向在Linux x86-64平台上维护Oracle数据库的DBA和技术运维人员对刚接触补丁管理的朋友同样适用。1. 文件名拆解p26635834、112040、Linux-x86-64分别代表什么1.1 一段补丁文件的“身份信息”拿到一个zip文件第一件事不是解压而是看懂文件名。p26635834_112040_Linux-x86-64.zip这个命名格式在Oracle官方补丁库里非常典型p26635834是补丁号。每个Oracle补丁在My Oracle Support上都有一个唯一编号后续查文档、比对手动步骤都靠它。112040是补丁包内部的版本构建标识。具体含义随补丁类型不同而不同可以理解为“同一补丁号下的一个发布物标识”。Linux-x86-64是目标平台说明这个包只能在64位Linux的x86架构上使用。哪怕看起来内容一样也不要拿它在Solaris或AIX上尝试。.zip说明它是个ZIP格式压缩包Oracle官方很多补丁都选择zip作为分发格式而不是tar.gz。实际遇到补丁时还要留意文件名里可能出现的完整版本比如19.12.0.0.0。很多DBA把p26635834和19.12混为一谈其实它们是两个维度补丁号决定“这个补丁修了什么”版本决定“这个补丁基于哪个基线”。所以下载前一定要在页面确认版本号。1.2 它属于哪一类补丁怎么跟关键版本对上以p26635834为关键字去查通常能看到这属于Database Proactive Bundle Patch或者Release Update这一类“周期性补丁”。这类补丁的作用是在一个基础版本上做月度或季度累积修复包含安全更新、回归修复和少量新功能。它和小的单次补丁one-off patch不一样。单次补丁可能只有几个文件zip包很小而p26635834_112040_Linux-x86-64.zip这种包解压后往往是一个完整目录里面包含Opatch执行脚本、修复文件、README等。因此它的应用流程也必须是“先解压再校验再opatch apply”不能像普通软件安装包一样双击运行。如果你是在CentOS 7.6上安装Oracle 19c建议先看README确定这个zip包是针对全新安装还是针对已有ORACLE_HOME的补丁。这个问题一旦搞反后面的错误会让人怀疑人生。2. 解压前的准备校验、工具和路径一个都不能少2.1 先做完整性校验别急着双击解压我在处理任何Oracle补丁包时第一件事永远是用md5sum或sha1sum做校验。Oracle Support下载页面会给出对应的checksum文件下载完成后对比一下几乎能挡住80%的“解压报错”问题。md5sum p26635834_112040_Linux-x86-64.zip sha1sum p26635834_112040_Linux-x86-64.zip输出结果和下载页面的内容一致才继续下一步。如果不一致不要试图修复直接重新下载。这里要特别提醒很多下载工具支持“断点续传”但续传过来的zip包经常出现“文件大小正确但内部字节错位”的情况。md5能查出这类问题所以校验动作一定不能省。有些朋友会问“如果Oracle页面只给了sha256怎么办”那就用sha256sum p26635834_112040_Linux-x86-64.zip道理一样。不要偷懒跳过去否则后面所有排查都建立在“地基已经歪了”的基础上。2.2 解压工具的选择Linux推荐unzipWindows避坑乱码在Linux x86-64环境上我最推荐的工具就是系统自带的unzip。原因很简单Oracle官方zip包面向的就是这种环境unzip对zip格式的兼容性最稳且命令行操作方便嵌入脚本。如果你是在Windows上下载后再传到Linux我建议不要用某些国产压缩软件直接解压更不要“解压后打成新zip再传”。压缩软件在Windows上处理zip时默认编码往往不是UTF-8可能导致Linux上中文文件名乱码。Oracle补丁包文件名基本都是英文但你自己打包的配置文件和脚本目录就很容易踩这个坑。在Linux上解压前先确认已安装unzip -v如果没有CentOS/RHEL可以用sudo yum install -y unzipWindows下如果非要本地解压预览可以用7-Zip。7-Zip对zip的兼容性不错但要注意它默认按UTF-8处理文件名对某些用GBK编码打包的旧zip仍会显示乱码。所以项目文件建议在哪个平台部署就在哪个平台解压不要跨平台倒来倒去。2.3 磁盘空间和路径设计Oracle补丁zip包通常不小解压后占用空间可能是压缩包的2到3倍。一个本地备份的ORACLE_HOME动辄几十GB补丁目录也一样。所以我建议df -h /u01确认目标分区至少有zip包大小3倍以上的空闲空间。不要解压到/tmp除非你确认/tmp空间充足。我见过很多次环境因为/tmp空间不足导致解压到一半失败最后报错指向zip文件损坏其实是空间问题。路径设计也有讲究。我习惯在$ORACLE_HOME/../patch下建一个以补丁号命名的目录比如mkdir -p /u01/app/oracle/patch/26635834然后把zip包放进去解压。这样既不会污染ORACLE_HOME又方便以后回滚时找到原包。3. Linux x86-64上解压Oracle补丁包的标准流程3.1 上传阶段最容易“压坏”zip很多时候zip文件在Oracle服务器上是完好的坏在“上传”环节。如果你用FTP上传记得一定要用binary模式。ASCII模式会把字节中的某些字符做转换zip这种二进制文件一传就废。更推荐用scp或sftpscp p26635834_112040_Linux-x86-64.zip oracle192.168.1.10:/u01/app/oracle/patch/如果你是在使用rz上传也要注意终端会话是否乱码、是否人为中断。Zmodem协议本身二进制安全但终端工具实现参差不齐大文件上传时经常断流。最稳的方式始终是先用scp或wget直接拉到目标机器上。3.2 解压、权限与文件完整性复查上传完成后用Oracle用户执行unzip -q p26635834_112040_Linux-x86-64.zip -d 26635834加-q可以安静解压避免刷屏。解压完成后先看目录结构ls -l 26635834正常情况下这个目录下会有一个README或补丁说明文档。打开README里面会有补丁适用版本、前置条件、opatch版本要求。很多字段都有用值得花两分钟读。然后做一次完整测试解压验证unzip -t p26635834_112040_Linux-x86-64.zip-t参数会逐文件测试CRC校验如果哪个文件损坏这里会明确报出来。这个过程比md5还更细粒度因为它测试的是每个内部文件的完整性。如果unzip -t全绿说明zip包本身没有问题可以放心进下一步。3.3 OPatch环境准备和应用前的最后确认解压补丁包不等于应用补丁。Oracle补丁应用依赖$ORACLE_HOME/OPatch/opatch工具。补丁包里的README通常会要求最低opatch版本。用下面命令检查当前版本$ORACLE_HOME/OPatch/opatch version如果版本太低需要先去下载对应OPatch补丁先更新OPatch再应用本次补丁。顺序颠倒会有奇奇怪怪的错误。另外应用补丁前需要设置好环境变量export ORACLE_HOME/u01/app/oracle/product/19.3.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$ORACLE_HOME/bin:$PATH然后执行$ORACLE_HOME/OPatch/opatch lsinventory这个命令会显示当前ORACLE_HOME中已安装的补丁。在没有应用新补丁之前先记录一下现在的状态。截图或重定向输出都行后面验证和回滚都要对照它。4. 遭遇 invalid zip archive: could not find eocd 的完整排查链路4.1 EOCD缺失是怎么发生的invalid zip archive: could not find eocd是Java读取zip文件时的典型报错。EOCD全称是End of Central Directory中文叫中央目录结尾记录它必须位于zip文件的最末尾。可以把它理解成zip的“目录索引尾部”记录了这个zip文件包含多少个文件、每个文件在哪个偏移位置。如果文件被截断、上传不完整、受到破坏EOCD就找不到Java会直接抛这个错误。命令行里的unzip遇到同样问题会报类似End-of-central-directory signature not found。两者本质是一个问题。出现这种报错时我的第一反应不是去修复zip而是先想这个文件有没有可能根本就没传输完整4.2 一次现场排查的逐层推进假设你在scp后直接unzip -t结果出现大量CRC错误或“cannot find zipfile directory”。不要慌按下面的链路一层层查第一步看文件大小ls -l p26635834_112040_Linux-x86-64.zip对比Oracle下载页面的字节数。只要大小对不上直接重新下载。注意少几个字节也不行zip的EOCD就在那最后几十个字节里。第二步用file命令看文件头file p26635834_112040_Linux-x86-64.zip如果输出里有Zip archive data说明文件头正常。如果没有甚至连data都识别不出来说明这个“zip”很可能压根不是zip格式可能是HTML错误页面或上传工具生成的临时文件。第三步看文件尾部tail -c 100 p26635834_112040_Linux-x86-64.zip | xxd正常的zip文件末尾应该有50 4b 05 06这组十六进制签名也就是ASCII里的PK..。如果最后一段是空的或者乱码说明EOCD已经丢失或根本没写进去。第四步检查是不是上传工具的问题。最常见的是FTP的ASCII模式其次是Windows上某些工具自动修改了文件。所以排查到最后往往不是Oracle补丁坏了而是中间某个环节破坏了二进制。4.3 从zip修复到彻底解决几种可用手段如果文件大小和checksum都对但unzip还是报错可以尝试用zip -FF修复zip -FF p26635834_112040_Linux-x86-64.zip --out p26635834_112040_Linux-x86-64-fixed.zipzip -FF会扫描zip文件中仍然存在的目录项并尝试重建中央目录。对小文件的恢复有时有效但对大型Oracle补丁包成功率不高。而且即便修复成功内部文件的CRC校验也不一定通过。所以我的建议是zip -FF只能作为“死马当活马医”的尝试不能依赖它。真正高效的解决办法就一句话删掉重新下载用scp的二进制模式上传再执行md5sum校验。如果这个流程做完仍然报错那就去Oracle Support确认下载的补丁号是否正确或者更换网络环境重新下载。我排查过的大多数could not find eocd都是下载不完整或上传过程损坏真正源文件损坏的情况极少。5. 嵌入热词密码工具、乱码、资源包导入错误这类“周边坑”5.1 Oracle补丁包没有密码谨慎对待“zip密码破解工具”网上一搜“zip压缩包密码破解工具”“zip密码恢复”搜索量很大。但针对p26635834_112040_Linux-x86-64.zip这类Oracle官方补丁包完全不需要关心密码。Oracle官方补丁包下载需要的是授权账号下载后zip本身不会二次加密。如果你在某个第三方网盘上拿到一个带密码的补丁包那八成是别人重新打包过的不建议使用。我不是说zip密码恢复技术没用它是数据恢复领域的正常工具但用在这里是找错了方向。Oracle补丁包有密码本身就是异常信号合法用法是处理自己遗忘密码的备份压缩包而不是去碰来源不明的文件。5.2 中文文件名乱码和分卷压缩的问题如果你在Linux上用unzip解压一个由Windows工具打包的zip经常看到中文文件名变成????或乱码。这是因为zip压缩包里没有强制指定文件名编码为UTF-8Windows压缩软件可能用本地语言编码写入了文件名Linux的unzip按UTF-8去解自然错乱。解决办法有几个在Windows上压缩前用7-Zip选择“UTF-8”编码再打包。在Linux解压时用支持指定解压工具比如unzip -O GBK file.zip来处理古老的GBK编码。更通用的方式是用Python的zipfile库写几行脚本按实际编码解码文件名。分卷压缩的情况也一样。有些资源提供方把一个大zip拆成z01、z02、zip多个文件解压时报“必须有下列压缩分卷z01”。Oracle官方补丁包不会分卷如果出现这种提示多半是下载工具没有自动合并或者你少下了某个分卷。去下载页面把全部分卷补齐重新解压即可。5.3 failed to copy spatial iop zip 与导入资源包失败的处理思路基于搜索热词failed to copy spatial iop zip常常伴随“导入资源包失败”“与技术支持部联系”一起出现。这个问题不完全等同于Oracle补丁包解压但它本质上仍然和zip包损坏、工具错误、权限不足有关。处理这类报错我建议从三方面入手确认要导入的资源包没有被第三方工具重新压缩过尤其是不要用手机解压、再上传到服务器这种操作。看系统日志里报错的具体文件路径定位是哪个zip复制失败然后用md5sum校验源zip和操作系统上zip的完整性。如果你在WebLogic或EM平台里导入应用包尽量使用平台自带的上传解压机制而不是手动解压后复制。遇到failed to copy spatial iop zip这类信息最忌讳的是盯着那行英文反复看。把注意力转移到文件完整性和目录权限上大部分问题都能很快定位。6. 补丁应用后不能忘了的验证与回滚6.1 opatch lsinventory 看什么应用补丁不是解压完就结束了。执行完opatch apply后第一时间用opatch lsinventory验证补丁状态。看三样东西新补丁号是否出现在已安装列表里。是否显示successfully applied。OPatch工具版本是否符合预期。如果这些都对再启动数据库或做简单功能验证。千万不要“按完补丁就交差”一次补丁安装失败在几分钟内暴露和几天后暴露性质完全不同。6.2 回滚预案比安装本身更值得演练Oracle补丁支持回滚但回滚要求使用当时应用补丁时同版本的OPatch而且可能在opatch rollback -id 26635834时提示需要输入具体子补丁号。所以在应用前保存opatch lsinventory -detail输出是一个好习惯。回滚步骤不复杂但现场操作时我建议先把$ORACLE_HOME做个冷备或者至少把涉及修改的二进制文件备份到独立目录。磁盘空间多花几个GB换来的是晚上能睡着觉。我的经验是每次补丁操作都准备好一份“失败回滚清单”内容包括回滚命令、需要恢复的目录、回滚后如何验证。这份清单在真正出问题时能让自己少掉一半头发。说到最后这类p26635834_112040_Linux-x86-64.zip的文件名我现在看到的第一反应不是解压而是先想清楚它从哪里来、校验值对不对、准备落在哪个路径。哪怕再急我也会先跑一次unzip -t。这个习惯帮我挡掉了很多次无效加班。希望这篇文章能让你在下次接到补丁任务时只解压一次就成功落地。本文还有配套的精品资源点击获取
