也顾不得查找root cause，赶紧重新启动数据库，但更糟糕的是数据库实例居然启动失败，连续多次startup才能偶尔启动成功一次，而且很快又宕机，Listener也经常启动失败。第一感觉是服务器中了病毒，应用的环境是：oracle 10.2.0.1 和windows 2003 server。因为ORA-07445通常是Oracle调用操作系统的资源出错时出现的。查看了一下oracle的参数，吃惊的发现数据库居然运行在共享模式，赶紧把它们全部改到专用模式，相关语句如下：
再重新启动数据库，已经可以启动了，但偶尔实例还会宕，不过马上重新启动就行了，就这样隔一会儿就重启一下数据库。终于熬到了下班，周围的电话也安静了下来，可以开始静下心来找root cause了。
再到metalink上查找类似问题，找到了两个文档Doc ID: 422471.1和Doc ID: 405904.1。经过分析后，采取了实施了以下两个变更：
变更一：为减少和数据库和OS的交到，封锁OS登录数据库的认证：
在sqlnet.ora中，注释了下面的语句：
# SQLNET.AUTHENTICATION_SERVICES = (NTS)
变更二：为加快数据库对登录会话的响应，修改下面监听的参数
Sqlnet.ora中增加下面的语句
SQLNET.INBOUND_CONNECT_TIMEOUT = 0 ---默认是６０秒
在listener.ora中增加
INBOUND_CONNECT_TIMEOUT_LISTENER =0 ---默认是６０秒
有以下特点：
- 有１５台机器在第一天几乎同一个时间点都出现了svchost.exe的报错，以后再出现svchost.exe的报错也基本是多台机器同时产生的。
- 和oracle的alert_log结合分析，在svchost.exe出错不久，数据库出现ora-07445的错误接着就宕机。
- 错误模块 kernel32.dll，错误地址 0x0010568f。
在windows的下面两个网页中可以找到对这个漏洞的说明和解决办法。
http://www.microsoft.com/china/technet/security/bulletin/MS08-067.mspx
http://support.microsoft.com/kb/958644/zh-cn
经过分析，极有可能是 W32.downadup.B型蠕虫病毒，需要打上KB958644的补丁，打卡补丁后问题果然解决。
总结：内网某台机器中了病毒，不断地攻击同一网段的windows系统的svchost进程，造成Oracle宕机，通过调整Oracle的参数和给windows打补丁后解决。
参考文档：
Oracle metalink Doc ID: 422471.1和Doc ID: 405904.1
Windows:
http://www.microsoft.com/china/technet/security/bulletin/MS08-067.mspx
http://support.microsoft.com/kb/958644/zh-cn
