忙乎了將近兩周，終于搞定了。從一開始懷疑是網(wǎng)絡(luò)的問題，后來覺得不是，可能是應(yīng)用的問題，發(fā)現(xiàn)很可能是數(shù)據(jù)庫的問題，最后真相大白又回到原點(diǎn)，原來是網(wǎng)絡(luò)防火墻在搗鬼。 行為非常詭異，怎么想也想不明白，我都沒多少信心預(yù)備放棄了，沒想到原因竟然如此簡單。 事情是這樣的，我們開發(fā)的系統(tǒng)需要保持和Oracle數(shù)據(jù)庫的持續(xù)連接，假如因?yàn)榫W(wǎng)絡(luò)或者其它原因非正常斷開的話，必須重新啟動(dòng)應(yīng)用程序，否則將會(huì)出錯(cuò)無法使用。在測試環(huán)境運(yùn)行很穩(wěn)定，一搬到機(jī)房機(jī)架上就出現(xiàn)希奇的現(xiàn)象，第二天早上來看服務(wù)器，所有的數(shù)據(jù)庫連接都斷掉了，有時(shí)候白天也斷，而且一個(gè)應(yīng)用斷的次數(shù)非凡頻繁，其它應(yīng)用白天不怎么斷。因?yàn)槲覀兊膽?yīng)用服務(wù)器網(wǎng)段是192.168.x.x，而數(shù)據(jù)庫服務(wù)器在10.x.x.x網(wǎng)段，剛開始我懷疑是中間的路由器有這種問題，假如網(wǎng)絡(luò)持續(xù)一段時(shí)間沒有流量自動(dòng)把網(wǎng)絡(luò)斷開。并且和網(wǎng)管說了這事，他說不可能有這種問題。因?yàn)槲覀円郧白鲞^另外一個(gè)系統(tǒng)也存在這種問題，似乎是這個(gè)原因，不過后來怎么解決的不是很清楚了。找知情人士了解后原來是數(shù)據(jù)庫網(wǎng)卡的原因，從應(yīng)用服務(wù)器ping數(shù)據(jù)庫服務(wù)器一個(gè)晚上有幾次丟包現(xiàn)象，換數(shù)據(jù)庫服務(wù)器網(wǎng)卡就沒事了。 于是我們用ping -t server-IP > ping.txt 來檢查網(wǎng)絡(luò)是否有丟包現(xiàn)象，持續(xù)幾個(gè)晚上都沒有一次丟包的，網(wǎng)絡(luò)狀況非常好。我檢查網(wǎng)卡屬性的電源屬性卡上有一個(gè)復(fù)選框是否答應(yīng)計(jì)算機(jī)閑置時(shí)關(guān)閉該設(shè)備，默認(rèn)是選中的。于是我懷疑是網(wǎng)卡被計(jì)算機(jī)關(guān)掉了，于是所有連接均斷開了，但是白天之?dāng)嚅_一個(gè)解釋不同啊。應(yīng)用程序有問題？為什么測試環(huán)境中沒發(fā)現(xiàn)問題？有可能是某一塊數(shù)據(jù)有問題，他們測試時(shí)亂調(diào)圖碰到雷區(qū)了，于是我檢查所有的數(shù)據(jù)，沒有那種問題。真是讓人費(fèi)解，而且我持續(xù)ping，網(wǎng)卡也不可能被關(guān)閉的啊。 有可能是某個(gè)端口關(guān)閉了，于是我們寫了一個(gè)小程序，打開一個(gè)數(shù)據(jù)庫連接，每隔一定時(shí)間查一下數(shù)據(jù)庫，保持端口是打開的。問題依舊存在，這個(gè)小程序的連接沒斷，其它的全斷了。是什么原因呢？其實(shí)現(xiàn)在想起來問題已經(jīng)很明朗了，但是當(dāng)時(shí)就是不明白怎么回事。而且那天老是打電話過來，連接又?jǐn)嗔耍衔鐢鄡纱危挛缬謹(jǐn)嗔藘纱巍Ｒ徽煳覀兌紱]想出什么好辦法，怎么會(huì)這么變態(tài)，為什么會(huì)只斷掉一個(gè)？我當(dāng)時(shí)懷疑是我們應(yīng)用程序有點(diǎn)問題，在絞盡腦汁想辦法怎么檢測應(yīng)用程序的錯(cuò)誤。為了檢測斷開的規(guī)律，我寫了兩個(gè)觸發(fā)器，用戶登陸時(shí)網(wǎng)一個(gè)表中插入一條記錄，注銷是把注銷時(shí)間填入表中。后來發(fā)現(xiàn)根本一點(diǎn)用也沒有，非正常退出時(shí)根本不會(huì)觸發(fā)LOGOFF事件，白忙乎了！下班了，騎車回家，忽然想到一個(gè)辦法，定時(shí)激活連接，保持活動(dòng)狀態(tài)看它還斷不斷。很多好的想法都是在我離開辦公室回家的路上想出來了，在辦公室怎么想也想不出來，離開辦公室就想出了。第二天馬上行動(dòng)，果真有效，連接沒有再斷過。但是這樣不是個(gè)辦法，為什么連接一段時(shí)間不活動(dòng)就會(huì)被殺掉了呢？在我們的應(yīng)用程序中看不到原因，只是說連接丟失，在sqlplus中提示說end-of-file communication channel。 今天一整天我都在網(wǎng)上狂找相關(guān)內(nèi)容，oracle connection lost, oracle session lost，oracle session timeout等等，看到也有人碰到類似我這種情況的人，但是沒有好的辦法。我把Oracle net service得文檔翻了一遍，看到sqlnet.ora有一個(gè)關(guān)于超時(shí)的參數(shù)SQLNET.EXPIRE_TIME簡直如獲至寶，后來發(fā)現(xiàn)原來沒用。服務(wù)器端自動(dòng)殺掉客戶端進(jìn)程的情況還可以通過Profile來實(shí)現(xiàn)，限制IDLE_TIME，但是我檢查數(shù)據(jù)庫根本沒有相關(guān)的設(shè)置。 好不輕易找到一溜很長的帖子，也是關(guān)于我這種問題的，最后他說解決了是防火墻的問題。但是以前我印象中防火墻只是針對(duì)端口的，怎么會(huì)保持某些活動(dòng)連接，殺掉不活動(dòng)的連接呢？后來我去網(wǎng)上查了查防火前的有關(guān)原理，好象它能處理到TCP/IP連接一級(jí)，也就是可以只斷開某一個(gè)不活動(dòng)的連接。但我還是不很確定，但是我知道在數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器之間有防火墻，把機(jī)器搬過去的那天，能ping通數(shù)據(jù)庫服務(wù)器，但是不能連數(shù)據(jù)庫，后來網(wǎng)管把Oracle數(shù)據(jù)庫的兩個(gè)端口打開就可以了。我們找到網(wǎng)管，他說是有這種問題，防火墻就是這樣的，假如一個(gè)連接長時(shí)間不活動(dòng)就會(huì)自動(dòng)殺掉的。假如不這樣的話，防火墻的內(nèi)存很快會(huì)用完，還說我們違反了TCP/IP的設(shè)計(jì)原則。但是沒辦法，我們的應(yīng)用程序需要持續(xù)而穩(wěn)定數(shù)據(jù)庫連接，只能把我們的應(yīng)用服務(wù)器放到防火墻后面去。于是他把我們的服務(wù)器跳了線，變成一個(gè)網(wǎng)段的，從此不再有連接斷開的問題了。終于徹底解決這個(gè)問題，長舒一口氣！ ！！其實(shí)主要原因還是網(wǎng)絡(luò)規(guī)劃有問題，怎么能把我們應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器隔開呢？;