一次windows漏洞导致的ora-07445错误整修记录

前段时间,有客户反应他们的oracle数据库监听起不来了,发来的系统报错日志为:

错误应用程序 TNSLSNR.EXE,版本0.0.0.0,错误模块orahasgen10.dll,版本10.2.0.1,错误地址0x0000000000353d0

客户做的是MSCS双机,但是主机的监听起不来之后,它也不自动切到备机上。最后客户关掉主服务器后,所有资源才切到备机上,之后就是数据库在备机上运行,主服务器待修。

于是我远程到客户那边,让客户重新启动主机,修改了主机的配置信息后,直接启动监听,竟然成功起来了。于是,我让客户主机先运行着(不挂载库,只是跑着实例和监听)。之后,我查看了oracle监听的日志和数据库的日志,没有发现有价值的错误信息。只是在oracle的警告日志中发现了连续多条这样的信息:

ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x78EE1CD6] [ADDR:0x15A0] [UNABLE_TO_READ] []

我通过查询http://ora-07445.ora-code.com/以及其他的帖子得出,这是一个由于操作系统错误引发的错误或者是跟ora-0600一样属于oracle的内部错误。

我首先怀疑的是oracle的bug问题,于是我跟应用商联系,确认他们应用使用的oracle版本是否是10.2.0.1,因为同事告诉我oracle10g的10.2.0.4版本是比较稳定的。我得到的答案是他们应用的客户使用的数据库版本都是10.2.0.1。

看了半天的日志,依旧不能确定问题在哪。

后来去了客户现场,发现主服务器监听还显示正在运行状态。但是我刷新服务,发现监听处于停止状态,于是我手动启动监听,没有任何报错,但是立刻刷新服务,则监听重新显示为停止状态。看来,监听确实存在问题。

首先怀疑orahasgen10.dll模块有问题,于是从网上下载这个模块,当时不清楚放到哪个位置,于是直接放到了c:\windows\system32\目录下,并且使用regsvr32 /s “c:\windows\system32\orahasgen10.dll”进行注册。

之后,我删除当前监听,重启重新建立监听服务。然后把集群资源切到主服务器上,让主服务器挂载上数据库运行。这样运行了大约18个小时,主服务器监听又宕掉了,还是一样的报错:

错误应用程序 TNSLSNR.EXE,版本0.0.0.0,错误模块orahasgen10.dll,版本10.2.0.1,错误地址0x0000000000353d0

这次问题发生的时间我正好在现场观察,我发现这包TNSLSNR.EXE错误之前,首先出现了这样一条错误:

错误应用程序 svchost.exe,版本 5.2.3790.1830,错误模块 netapi32.dll,版本 5.2.3790.1830,错误地址 0x000521a2

于是检查上次服务宕机时间的系统日志,发现确实在包TNSLSNR.EXE.错误之前也报了这样一个错误。后来又查看了数据库cdump目录下的”实例名core.log”文件,通过此文件对错误发生时内存信息的记录,发现orahasgen10.dll模块存在于“$ORACLE_HOME\BIN\”目录下。原本对dll模块的操作都是无用功。

在网上查了关于netapi32.dll报错的信息。发现是微软的漏洞,具体信息参考:

http://social.microsoft.com/Forums/zh-CN/540fdce5-abac-4c80-85f7-5a258dd314fa/-svchostexe-5237901830-netapi32dll-5237901830-0x000521a2?forum=windowsserversystemzhchs

http://support.microsoft.com/kb/958644/zh-cn

解决办法就是打补丁:KB958644。

http://www.microsoft.com/zh-cn/download/details.aspx?id=7605

打完这个补丁,将数据库重新迁回主服务器运行,观察,现在过去一周左右了,未发现错误。

重新梳理下整个过程,应该确实是由于netapi32.dll导致windows溢出的漏洞,使得网络功能不能正常使用,网络的失常使得监听报错,造成数据库宕机,并报ora-07445的错误。

 

 

 

 

 


一次windows漏洞导致的ora-07445错误整修记录

上一篇:Android 面试题--Activity


下一篇:Deeplab v3+的结构代码简要分析