ORA-07445通常是Oracle調用操作系統的資源出錯時出現的[@more@]
事前沒有任何征兆，下午5點左右某個關鍵應用的17台oracle數據庫上的數據庫實例陸續宕機，趕緊查看alert_log，發現此文件中記錄了大量的0RA-07445錯誤代碼：
ORA-07445: exception encountered: core dump [] [] [] [] [] []
也顧不得查找root cause，趕緊重新啟動數據庫，但更糟糕的是數據庫實例居然啟動失敗，連續多次startup才能偶爾啟動成功一次，而且很快又宕機，Listener也經常啟動失敗。第一感覺是服務器中了病毒，應用的環境是：oracle 10.2.0.1 和windows 2003 server。因為ORA-07445通常是Oracle調用操作系統的資源出錯時出現的。查看了一下oracle的參數，吃驚的發現數據庫居然運行在共享模式，趕緊把它們全部改到專用模式，相關語句如下：
alter system set dispatchers=' ;
alter system set shared_servers=0;
再重新啟動數據庫，已經可以啟動了，但偶爾實例還會宕，不過馬上重新啟動就行了，就這樣隔一會兒就重啟一下數據庫。終於熬到了下班，周圍的電話也安靜了下來，可以開始靜下心來找root cause了。
從前面的症狀分析，一個明顯的感覺是OS出了問題，Oracle數據庫在調用windows 2003 server的資源時出錯，
因為專用模式減少了Oracle和OS之間的交互，所以減少了宕機的現象發生。
再到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