前段时间，有客户反应他们的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的错误。