当我们运持某个程序经常会出现内存为只读Read错误...点确定就自动关掉了无法运行而苦脑 时请看完下面的文章也许对你有帮助.:)
出现这个现象有方面的,一是硬件,即内存方面有问题,二是软件,这就有多方面的问题了。
一:先说说硬件:
一般来说,电脑硬件是很不容易坏的。内存出现问题的可能性并不大(除非你的内存真的是杂牌的一塌徒地),主要方面是:1。内存条坏了(二手内存情况居多)、2。使用了有质量问题的内存,3。内存插在主板上的金手指部分灰尘太多4。使用不同品牌不同容量的内存,从而出现不兼容的情况。5。超频带来的散热问题。你可以使用MemTest 这个软件来检测一下内存,它可以彻底的检测出内存的稳定度。
二、如果都没有,那就从软件方面排除故障了。
先说原理:内存有个存放数据的地方叫缓冲区,当程序把数据放在缓冲区,需要 *** 作系统提供的“功能函数”来申请,如果内存分配成功,函数就会将所新开辟的内存区地址返回给应用程序,应用程序就可以通过这个地址使用这块内存。这就是“动态内存分配”,内存地址也就是编程中的“光标”。内存不是永远都招之即来、用之不尽的,有时候内存分配也会失败。当分配失败时系统函数会返回一个0值,这时返回值“0”已不表示新启用的光标,而是系统向应用程序发出的一个通知,告知出现了错误。作为应用程序,在每一次申请内存后都应该检查返回值是否为0,如果是,则意味着出现了故障,应该采取一些措施挽救,这就增强了程序的“健壮性”。若应用程序没有检查这个错误,它就会按照“思维惯性”认为这个值是给它分配的可用光标,继续在之后的执行中使用这块内存。真正的0地址内存区储存的是计算机系统中最重要的“中断描述符表”,绝对不允许应用程序使用。在没有保护机制的 *** 作系统下(如DOS),写数据到这个地址会导致立即当机,而在健壮的 *** 作系统中,如Windows等,这个 *** 作会马上被系统的保护机制捕获,其结果就是由 *** 作系统强行关闭出错的应用程序,以防止其错误扩大。这时候,就会出现上述的内存不能为“read”错误,并指出被引用的内存地址为“0x00000000“。内存分配失败故障的原因很多,内存不够、系统函数的版本不匹配等都可能有影响。因此,这种分配失败多见于 *** 作系统使用很长时间后,安装了多种应用程序(包括无意中“安装”的病毒程序),更改了大量的系统参数和系统档案之后。
在使用动态分配的应用程序中,有时会有这样的情况出现:程序试图读写一块“应该可用”的内存,但不知为什么,这个预料中可用的光标已经失效了。有可能是“忘记了”向 *** 作系统要求分配,也可能是程序自己在某个时候已经注销了这块内存而“没有留意”等等。注销了的内存被系统回收,其访问权已经不属于该应用程序,因此读写 *** 作也同样会触发系统的保护机制,企图“违法”的程序唯一的下场就是被 *** 作终止执行,回收全部资源。计算机世界的法律还是要比人类有效和严厉得多啊!像这样的情况都属于程序自身的BUG,你往往可在特定的 *** 作顺序下重现错误。无效光标不一定总是0,因此错误提示中的内存地址也不一定为“0x00000000”,而是其它随机数字
·看内存不能为read written 解决方法(2)
首先建议:
1、 检查系统中是否有木马或病毒。这类程序为了控制系统往往不负责任地修改系统,从而导致 *** 作系统异常。平常应加强信息安全意识,对来源不明的可执行程序绝不好奇。
2、 更新 *** 作系统,让 *** 作系统的安装程序重新拷贝正确版本的系统档案、修正系统参数。有时候 *** 作系统本身也会有BUG,要注意安装官方发行的升级程序。
3、 尽量使用最新正式版本的应用程序、Beta版、试用版都会有BUG。
4、 删除然后重新创建 Winnt\System32\Wbem\Repository 文件夹中的文件:在桌面上右击我的电脑,然后单击管理。 在"服务和应用程序"下,单击服务,然后关闭并停止 Windows Management Instrumentation 服务。 删除 Winnt\System32\Wbem\Repository 文件夹中的所有文件。(在删除前请创建这些文件的备份副本。) 打开"服务和应用程序",单击服务,然后打开并启动 Windows Management Instrumentation 服务。当服务重新启动时,将基于以下注册表项中所提供的信息重新创建这些文件: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\Autorecover MOFs
下面搜集几个例子给大家分析:
例一:IE浏览器出现“0x0a8ba9ef”指令引用的“0x03713644” 内存,或者“0x70dcf39f”指令引用的“0x00000000”内存。该内存不能为“read”。要终止程序,请单击“确定”的信息框,单击“确定”后,又出现“发生内部错误,您正在使用的其中一个窗口即将关闭”的信息框,关闭该提示信息后,IE浏览器也被关闭。解决方法:
1、 开始-运行窗口,输入“regsvr32 actxprxy.dll”回车,接着会出现一个信息对话 框“DllRegisterServer in actxprxy.dll succeeded”,确定。再依次运行以下命令。(这个方法有人说没必要,但重新注册一下那些.dll对系统也没有坏处,反正多方下手,能解决问题就行。)
regsvr32 shdocvw.dll
regsvr32 oleaut32.dll
regsvr32 actxprxy.dll
regsvr32 mshtml.dll
regsvr32 msjava.dll
regsvr32 browseui.dll
regsvr32 urlmon.dll
2、 修复或升级IE浏览器,同时打上系统补丁。看过其中一个修复方法是,把系统还原到系统初始的状态下。建议将IE升级到了6.0。
例二:有些应用程序错误: “0x7cd64998” 指令参考的 “0x14c96730” 内存。该内存不能为 “read”。解决方法:Win XP的“预读取”技术这种最佳化技术也被用到了应用程序上,系统对每一个应用程序的前几次启动情况进行分析,然后新增一个描述套用需求的虚拟“内存映像”,并把这些信息储存到Windows\Prefetch文件夹。一旦建立了映像,应用软件的装入速度大大提高。XP的预读取数据储存了最近8次系统启动或应用软件启动的信息。建议将虚拟内存撤换,删除Windows\Prefetch目录下所有*.PF文件,让windows重新收集程序的物理地址。
·看内存不能为read written 解决方法(3)
例三:在XP下双击光盘里面的“AutoRun.exe”文件,显示“0x77f745cc”指令引用的“0x00000078”内存。该内存不能为“written”,要终止程序,请单击“确定”,而在Windows 98里运行却正常。 解决方法:这可能是系统的兼容性问题,winXP的系统,右键“AutoRun.exe”文件,属性,兼容性,把“用兼容模式运行这个程序”项选择上,并选择“Windows 98/Me”。win2000如果打了SP的补丁后,只要开始,运行,输入:regsvr32 c:\winnt\apppatch\slayerui.dll。右键,属性,也会出现兼容性的选项。
例四:RealOne Gold关闭时出现错误,以前一直使用正常,最近却在每次关闭时出现“0xffffffff”指令引用的“0xffffffff”内存。该内存不能为“read” 的提示。 解决方法:当使用的输入法为微软拼音输入法2003,并且隐藏语言栏时(不隐藏时没问题)关闭RealOne就会出现这个问题,因此在关闭RealOne之前可以显示语言栏或者将任意其他输入法作为当前输入法来解决这个问题。
例五:我的豪杰超级解霸自从上网后就不能播放了,每次都提示“0x060692f6”(每次变化)指令引用的“0xff000011”内存不能为“read”,终止程序请按确定。 解决方法:试试重装豪杰超级解霸,如果重装后还会,到官方网站下载相应版本的补丁试试。还不行,只好换就用别的播放器试试了。
例六:双击一个游戏的快捷方式,“0x77f5cd0”指令引用“0xffffffff”内 存,该内存不能为“read” ,并且提示Client.dat程序错误。解决方法:重装显卡的最新驱动程序,然后下载并且安装DirectX9.0。
例七:一个朋友发信息过来,我的电脑便出现了错误信息:“0x772b548f”指令引用的“0x00303033”内存,该内存不能为“written”,然后QQ自动下线,而再打开QQ,发现了他发过来的十几条的信息。 解决方法:这是对方利用QQ的BUG,发送特殊的代码,做QQ出错,只要打上补丁或升级到最新版本,就没事了
还有一种可能:
在控制面板的添加/删除程序中看看你是否安装了微软NET.Framework,如果已经安装了,可以考虑卸载它,当然如果你以后在其它程序需要NET.Framework时候,可以再重新安装。
另外,如果你用的是ATI显卡并且你用的是SP2的补丁(一些ATI的显卡驱动需要在NET.Framework正常工作的环境下)。这种情况你可以找一款不需要NET.Framework支持的ATI显卡驱动。
如果以上两种方法并不能完全解决问题,你试着用一下“IE修复”软件,并可以查查是否有病毒之类的。
〔微软NET.Framework升级到1.1版应该没问题了
·看内存不能为read written 解决方法(4)
解决方法其中一种:
运行regedit进入注册表, 在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks下,应该只有一个正常的键值", 将其他的删除。
解决方法其中一种:
删除NET.Framework。
解决方法其中一种:
微软新闻组的朋友指点:开始--运行:regsvr32 jscript.dll
开始--运行:regsvr32 vbscript.dll
解决方法其中一种:
运行 输入cmd 回车在命令提示符下输入
for %1 in (%windir%\system32\*.dll) do regsvr32.exe /s %1
技巧:如果怕输入错误的话,可以复制这条指令,然后在命令提示框点击左上角的c:\,使用下面的“编辑-粘贴”功能就不容易输错了。在飞速滚屏完全静止之后,别着急启动其他程序,先耐心等一会儿,因为此时dll们还在找位置。直到你的指示灯不闪了再做别的.
以上这些方法是偶在网上整理的,和大家共享一下.
给软件打补丁相当于给人打预防针,对系统的稳定运行至关重要。本文详细、系统地介绍了Oracle数据库补丁的分类、安装、管理等问题。厂商提供给用户的软件补丁的形式多为编译后的库函数,所以安装软件补丁实际上就是把这些库函数拷贝到相应目录,并在需要时进行联接 *** 作。软件公司一般在一段时间后会把针对某一版本的所有补丁进行整理:合并融合,解决冲突,进行整体测试,并使文件拷贝和联接 *** 作自动执行,得到一个软件补丁“包”。不同的公司使用不同的名称,现在一般计算机用户都熟悉的Windows Service Pack就是这样的补丁包。Oracle公司给出的补丁包的名称是Patch Set,安装Patch Set后的版本称Patch Set Release(PSR)。
Oracle公司对处于标准技术支持的产品不定期地提供PSR,例如在完成本文时,版本10.2的最新PSR是10.2.0.2;版本10.1的最新PSR是10.1.0.5版本9.2的最新(也极可能是最终)PSR是9.2.0.8。
在安装最新PSR后新发现的Bug,其相应补丁当然会收录到下一个PSR中。PSR是累积型的,即下一个PSR中会包括当前PSR中所有补丁和新发现Bug的补丁。同时存在几个PSR时,只需安装最新版本一次就可以了。但是由于PSR的发行有一定间隔,如果这些Bug对用户有比较大的影响,那么 Oracle公司也会向用户公开和提供这些补丁,这些补丁被称为个别补丁(Interim Patch,one-off patch 或 Patch Set Exception)。而对于最终补丁发行版而言,由于不再有下一个PSR,所以当发现影响系统的新Bug时,个别补丁成为惟一选择。
此外,Oracle公司还定期发布安全补丁,称之为CPU(Critical Patch Updates)。安全补丁用来修复软件的易受攻击性(vulnerability)或通常说的安全漏洞。这类问题本来不属于软件错误,在正常使用中不会出现任何问题。但是别有用心的人可以通过运行非常精巧设计的代码,绕过数据库系统的安全管理机制,达到非授权存取的目的。
另外还存在一类补丁:诊断用补丁(diagnostic patch)。顾名思义,这类补丁不是用来解决问题的,而是用来寻找问题的原因的。这类补丁只在Oracle技术支持部门要求安装时,才需要安装。在得到需要的诊断信息后,应立即卸载这一补丁。
利弊及时机选择
负责管理支撑大型应用系统的数据库的DBA会容易理解安装软件补丁的代价。安装PSR需要停止数据库服务,关闭数据库,对于许多应用系统安排这样的停机时间本身就是一件比较困难的事情。事实上,更为严重的是由于安装PSR可能“引入”新的Bug,反而影响应用系统的正常运行。软件补丁本来是修正 Bug,怎么会带来新的Bug?虽然有些让人匪夷所思,但很不幸这是现实存在的。
对于每一个PSR,其中都包括了少则几百多则上千个严重Bug的修正。即便是如此,在PSR发布后,很快就又会在安装PSR后的数据库中发现一些新问题。其中一部分Bug是以前就一直存在的只是以前没有发现,而现在偶尔被发现,或者是由于PSR修正了某一错误从而将其“激活”或容易发现。但是确实有一些Bug是由这一PSR造成的,Oracle技术支持部门称其为倒退(Regression)。对于每一PSR,在metalink中有两个重要的与之有关的文档,一个是“List of fixes added in XXXX”,是这一PSR修复的Bug的清单,是一本“修复列表”;另一个是“Known issues and alerts affecting XXXX”,是安装PSR后发现的问题,可以称其为“悔过列表”。由于大型软件的复杂性,Bug几乎是不可避免的。重要的是能够及时提供信息,DBA可以结合自己系统的情况做出正确的判断。读者不必因为知道还存在着Bug,就对Oracle数据库产品失去信心。PSR修复的上千个Bug中绝大多数是在一些很少见的环境中,或者是若干个组件的复杂组合使用的情形中发生的。
如果系统在运行中出现过某种问题,由Oracle技术支持部门或第三方的专家确认原因是PSR中的某一Bug,这样就必须尽早安装如果系统一直运行正常,并且在PSR已发现的问题中涉及的组件或功能(如Logical Standby, JVM,RAC等)在系统中并不使用,此时可以选择安装也可以选择不安装。
另一个需要考虑的因素是安装补丁的时机。上述这些考虑的一个重要前提是系统已经投入运行,担心“倒退”的Bug影响系统。如果系统还处在开发和测试阶段,不需要有任何犹豫,安装最新的PSR,并在此基础上测试应用系统是否工作正常。如果发现异常,要及时请Oracle技术支持部门确认是否新Bug,如果是请其提供个别补丁。目的就是在一个尽可能完善稳定的数据库平台上测试应用系统。我们可以把这种安装补丁的策略概括为“补丁补新不补旧”。
以上都是针对PSR的安装,对于个别补丁,由于补丁修复的Bug单一,容易判断是否需要安装。需要注意的是,如果在当前PSR之上安装了若干个个别补丁,那么在下一个PSR发布后,在安装下一个PSR之前,需要卸载所有个别补丁。为便于管理,现在Oracle技术支持部门要求必须使用工具 opatch安装管理个别工具,而尽量避免手动拷贝文件等 *** 作。
最后是安全补丁安装的判断。虽然安全漏洞这个词看上去让人觉得非常严重,但是还要冷静综合分析这些漏洞在系统中的危害程度。事实上,不安装安全补丁的危险性可能远远小于始终不渝地使用scott/tiger这样人人都知道的用户名和口令的“标准缺省”做法。
安装PSR
使用oui工具安装PSR时只需要用鼠标做几个选择就可以进入自动执行的阶段, *** 作过程本身非常简单。但是如果要求必须一次安装成功;要求必须在凌晨2点到4点这个有限的停机时间段完成 *** 作;要求安装过程不出差错,以后出现问题时能够完全排除此次 *** 作失误的可能性,那么就需要在启动oui之前做一些准备工作。
1. 收集信息
有关PSR的信息中,一个最重要的文档就是软件补丁说明,这个文件相当于技术手册中的安装指南和发行说明。文件本身包含在下载的软件补丁文件之中,文件名是patchnote.htm或README.html。需要注意的一个问题是在软件补丁文件之中找到的这一Patch Set Notes可能不是最新版,可以根据文件内的提示信息在metalink中检索最新版。
另外两个重要文件就是前面已经提及的“修复列表”和“悔过列表”,相对于“修复列表”更应该仔细阅读“悔过列表”中的每一项内容。另外,在Patch Set Notes的已知问题(Known Issues)一节内列出了安装PSR后出现的一些问题。
除去这三个主要文件外,还应在metalink中检索,寻找是否还有其他涉及这一PSR的技术文章,寻找其他用户在安装这一PSR时或安装后遇到问题时所发的救助的帖子,前车之鉴更应重视。
2. 做出判断
在认真阅读收集到的文章之后,根据自己系统的实际情况,做出是立即安装PSR,或是等待下一PSR的决定。如果是暂缓安装,则要记录原因,以便以后跟踪Bug的修复进程。
3. 制订实施计划
在决定安装PSR后,需要制订一个实施计划。在计划中不仅要包括正常的 *** 作步骤,更要考虑在出现意外时的应急处理(如果安装PSR失败,则在正常应用开始时间之前,要恢复系统到安装之前的状态)。如果可能,在对正式系统开始实施之前,应在测试系统中进行演练和应用处理的测试,保证在安装PSR后不会影响应用系统的运行。
安装PSR的计划大致有以下几个部分:停止数据库服务关闭数据库;备份DBMS软件和数据库以备恢复之用;安装PSR软件;更新数据库数据字典升级PSR版本;正常启动数据库开始数据库服务。
看似简单的关闭数据库的 *** 作,在系统构成复杂时也会变得不容易。另外,如果夜间作业时间不允许在完成数据库完全备份之后再安装PSR,则安装PSR的日期应该选择在例行的数据库完全备份的下一个晚上,只备份重做日志。
在安装PSR之前备份DBMS软件的目的是,由于安装PSR会对许多程序和库函数进行更新,如果安装PSR中途失败(虽然可能性非常小),有可能造成DBMS软件出现不一致。另外一种可能的情形是,在安装PSR,更新数据字典后,测试应用系统时,出现了某种异常,原因不明,最终决定放弃PSR。如果 *** 作之前没有备份,则此时只有重新安装软件一种选择(PSR不同于完整软件安装,在oui中无法单独卸载PSR软件)。
对文件、目录和文件系统的备份,最简单的方式可以使用cp、tar、dump等命令完成。如果希望缩短文件拷贝时间,可以考虑分区备份的方法。分区备份常用的命令是dd。但是,分区拷贝比文件拷贝速度快的前提是良好的分区设计:Oracle软件单独占一个大小适中(如4GB)的分区,这样扇区拷贝才会体现优势,这也就是为什么在安装软件时,Oracle建议单独使用一个分区安装软件的原因之一。
在制定实施计划时,应认真阅读Patch Set Notes中有关 *** 作前准备工作一节。在这节内会介绍对于一些特殊系统构成,如果你的系统属于文档中提到的构成,一定要首先阅读文内提示的相关技术文章,找到正确的安装步骤。
使用oui, PSR软件安装完成后,一定不要忘记更新数据字典这一步骤。如果在这一ORACLE_HOME下生成了多个数据库,则每个数据库都必须更新数据字典。
. 实施 *** 作
制订一个详细的计划后,实施 *** 作就可以“照本宣科”,是一个简单的体力劳动。要认识到“忙中出错”的概率远比“急中生智”大得多, *** 作时尽量减少失误的可能性。例如,需要执行的复杂命令,尽可能从一个文件拷贝到终端执行,而不要现场输入。另外,在实施过程中,要记录各个阶段实际的执行时间,以供以后制订类似计划时参考。
5. 检查 *** 作结果并记录备案
执行一个 *** 作, *** 作是否成功,一定要进行检查,不能简单认为没有出错信息就是成功。要知道验证的方法。除去极个别极费时间的验证(分区备份的内容是否可以成功恢复系统,必须恢复分区,启动数据库,测试应用系统后才能确认),其余 *** 作都应进行验证。所有屏幕输出信息和日志文件都应保留,作为安装报告的附件提交给上级或客户。
在屏幕输出或日志文件中出现异常/错误信息时,应即时分析,决定马上采取的措施。出现严重错误时,可能需要重新执行某一SQL程序,或者重新安装PSR。所以在制订实施计划时应在时间上留出异常情况处理的时间。
下面给出一个在Linux平台上安装10.1的PSR的实例,给从未安装PSR的读者有一个感性认识。
*** 作系统是RHEL AS4.0 Update3,Oracle的当前版本是10.1.2。在metalink中检索,找到10.1版的最新PSR10.1.0.5。下载压缩文件。在压缩文件中找到Patch Set Notes,该文档的完成日期是2006年1月。而按照文档内的提示在metalink中检索得到的此文档的最新版本完成日期是2006年4月。使用文件比较工具进行比较,两个版本没有实质性差别,只有语句措词的修改,但是养成总是检索最新文档的习惯有益无害。
根据Patch Set Notes中的说明,有一些特殊系统构成需要额外的步骤,本例中由于全部没有涉及到,所以可以按标准步骤执行。
另外,检查“Known issues and alerts affecting 10.1.0.5”文档后,发现10.1.0.5引入的影响最大的一个Bug是执行SELECT MAX()在某些特定条件下结果不正确。而这一Bug可以通过设置事件(event)关闭FIRST ROW优化而避免。最后的结论是这一BUG不会对本系统有影响,可以安装PSR10.1.0.5。
1. 检查数据库表空间和初始化参数是否需要调整。
System表空间要求有一定未使用空间:初始化参数SHARED_POOL_SIZE 和 JAVA_POOL_SIZE不能低于最小值150MB。
2. 关闭数据库,停止listener和agent等进程。
3. 解压缩下载文件至某一目录,执行oui。
在压缩文件中附带的oui的版本要比已经安装的版本高,应总是使用新版本的oui。在oui窗口中,要求选择本次安装的软件的位置,正确的位置是解压缩目录下的子目录Disk1/stage/, 选中products.xml即可开始文件拷贝。
要注意窗口中会出现本次安装的日志文件的文件路径和文件名。文件的位置是在Oracle的inventory所在目录的子目录logs中,文件名由前缀InstallActions和安装日期时间组成,如: InstallActions2006-08-30-11-32-48AM.log。
正常结束后,退出oui。打开日志文件,检索是否出现error 或“ORA-”的错误信息。本次安装产生的日志文件内,没有任何此类的信息,表明PSR软件安装成功。如果此时再次启动oui,点击“已安装软件”,则可以看到在原有的10.1.0.2软件之下,新出现了10.1.0.5一项,这也证实PSR软件安装成功。
4.更新数据库数据字典
更新数据字典时,必须以特殊的升级方式打开数据库。
$ sqlplus /nolog
SQL>CONNECT / AS SYSDBA
SQL>STARTUP UPGRADE
SQL>SPOOL patch.log
SQL>@?/rdbms/admin/catpatch.sql
执行结束后,关闭重定向:
SQL>SPOOL OFF
打开文件patch.log检查是否有错误“ORA-”。(这一文件在启动sqlplus时的当前目录中,当然也可以在“SPOOL patch.log”语句中显式指定文件路径。)如果出现错误要分析原因,在解决问题后,需要再次执行catpatch.sql程序。
更新数据字典时,由于对某些PL/SQL包删除后又重新生成,造成相关PL/SQL包的状态为异常(invalid)。在以后调用这些包时,检测到其状态为非法,会自动执行编译命令,使状态成为正常(valid)。虽然不会出错,但会造成个别处理第一次执行时变慢。显然,与其留到应用系统运行时再一个个编译,不如之前集中一次重编译所有异常包。
SQL>SHUTDOWN
SQL>STARTUP
SQL>@?/rdbms/admin/utlrp.sql
最后,根据Known Issues中的指示,完成与本系统有关的 *** 作。例如,修改Pro*C的配置文件。这里执行一个修改文件存取权限的“后 *** 作”,以便非同组用户和程序可以存取客户端工具和库函数。
$ cd $ORACLE_HOME/install
$ ./ changePerm.sh
个别补丁管理工具opatch
如前所述,在发布一个PSR后发现的新BUG,只能把其补丁收入到下一个PSR中。如果对数据库有实质性影响,则这一补丁以个别补丁的形式向用户提供。个别补丁是与某一个特定的PSR关联,是安装在这一PSR之上的。另外,如同其名字表明的,个别补丁只是单一Bug的补丁,不会包含其他个别补丁,即不是累积型的。
在9.2版之前,安装个别补丁的 *** 作完全是手工的。这种手工方式的缺点不仅在于加重DBA的负担,容易造成 *** 作失误,更严重的是无法对已安装的个别补丁进行管理。
为解决手工方式的缺陷,从9.2版开始,Oracle公司设计实现了个别补丁安装管理工具opatch。opatch使用一个称为 inventory的系统数据结构(严格说是与oui共享inventory),集中管理所有已安装的个别补丁;个别补丁的安装和卸载都使用opatch 命令完成,冲突检测也由opatch在安装时自动完成;提供列表命令可以很方便得到已安装个别补丁的信息。
10g(10.1和10.2)版本中,opatch作为一个标准工具,在软件安装时自动安装。(安装在$ORACLE_HOME/OPatch 下。)而对于9.2版,需要从metalink下载opatch。无论数据库是哪一个版本,系统中是否已经安装opatch,在使用之前,应从 metalink下载最新版本的opatch。很遗憾,由于系统实现的问题,10.2使用的opatch与之前版本(10.1和9.2)使用的 opatch不兼容,不能混用,这一点必须注意。
opatch是使用perl编写的脚本程序(其中也使用JAVA API)。编程使用的perl版本是5.6版,虽然在5.6之前的版本中也可运行,但应尽可能安装5.6或以上的版本的perl。对于DBA来说一个好消息是,如果安装9.2版软件时保留了HTTP服务器,则在$ORACLE_HOME/Apache下会自动安装perl。(10g会自动安装配置perl 和opatch。)
opatch命令格式为:
opatch <command >[<command_options >] [ -h[elp] ]
命令有:apply(安装个别补丁)、rollback(卸载个别补丁)、lsinventory(对inventory进行列表)、query (显示某一个别补丁的详细信息)、version(显示opatch版本信息)。在opatch目录下,有用户使用指南文件(Users_Guide.txt),其中有详细的命令格式和使用示例,读者可以参考。Opatch执行 *** 作时,除在屏幕输出结果外,还生成日志文件。日志文件的路径和文件名格式如下:
$ORACLE_HOME/.patch_storage/<patch_id >/<action >-<patch_id >_<mm-dd-yyyy_hh-mi-ss >.log
其中“patch_id”是Oracle技术支持部门为个别补丁分配的编号。
4. 个别补丁安装实例
沿用安装PSR实例中的环境。在安装PSR10.1.0.5后,检索metalink,发现若干在其之上的个别补丁。选择其中之一安装。
个别补丁Patch 4518443修复BUG4518443,这一BUG的主要问题是TNS LISTENER在注册ONS(Oracle Notification Services)的同时如果创建子进程,那么LISTENER会挂起(HANGUP)。
安装时,首先,从metalink下载补丁的压缩文件p4518443_10105_LINUX.zip。将此文件解压缩至某一目录中。解压缩后,这一补丁的所有文件都在子目录4518443下,目录名就是个别补丁的补丁号,opatch依据目录名获得信息,所以一定不要重命名子目录。
然后,在终端窗口中,执行cd命令移动到4518443子目录中,执行以下命令:
$ $ORACLE_HOME/OPatch/opatch apply
对inventory列表,确认安装 *** 作:
$ $ORACLE_HOME/OPatch/opatch lsinventory
执行卸载命令时,也必须使4518443子目录成为当前目录。其中,Rollback命令需要两个参数:-id给出个别补丁号;-ph 给出个别补丁解压缩后的路径。
$ $ORACLE_HOME/OPatch/opatch rollback -id 4518443 -ph /…/4518443
随后再对inventory列表,则会看到这一个别补丁已经被移去。
4. 使用opatch显示已安装的版本信息
不需要启动数据库,执行加选项的对inventory的列表命令,可以得到已安装的软件的各个组件的详细版本信息。
$ $ORACLE_HOME/OPatch/opatch lsinventory -detail
安全补丁CPU
一个CPU内包含了对多个安全漏洞的修复,并且也包括相应必需的非安全漏洞的补丁。CPU是累积型的,只要安装最新发布的CPU即可,其中包括之前发布的所有CPU的内容。事实上,在CPU之前的安全漏洞修改除去个别例外也被包括在CPU中。Oracle公司只对处于标准技术支持和延长支持期间的产品提供CPU更新,对处于维持支持范围的产品不提供新的CPU。(对于9.2以前的版本,只对处于ECS和EMS期间的版本提供CPU更新。)一般对当前补丁发行版及前一个版本提供CPU,但也有只限于当前补丁发行版的例外情形。也就是说,一般需要先安装最新PSR后才可能安装CPU。由于是累积型的定期发布,所以对于某一平台的某一版本,如果两次CPU发布期间没有发现新的安全漏洞,则新发布的CPU与前一版本完全相同。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)