SQLException:關(guān)閉的連接如何解決？好象來(lái)將，Connection在DB端有大的空閑時(shí)間的限制。如：mysql默認(rèn)Connection在8個(gè)小時(shí)少有使用(即有線程用Connection正在發(fā)

SQLException:關(guān)閉的連接如何解決？

好象來(lái)將，Connection在DB端有大的空閑時(shí)間的限制。如：mysql默認(rèn)Connection在8個(gè)小時(shí)少有使用(即有線程用Connection正在發(fā)送了SQL)，變會(huì)自動(dòng)已斷開(kāi)。而此時(shí)，你本地配置的數(shù)據(jù)庫(kù)再連接池，卻還可不知道該連接早被數(shù)據(jù)庫(kù)連接斷開(kāi)了。那樣的話就出現(xiàn)了，雖說(shuō)懷中掏出了Connection卻在在用時(shí)，一拋巳經(jīng)關(guān)掉的異樣。該怎么解決是為再連接池加測(cè)定Connection有效性的配置。這個(gè)我就不大好提出具體看的配置了，畢竟得看你用的是什么數(shù)據(jù)庫(kù)連接上池利用。

sql2012事務(wù)日志已滿永久解決？

DB右擊屬性-》文件-》添加一個(gè)log文件，下面就應(yīng)該不會(huì)異常，只不過(guò)以免以后異樣還需需要收索下log日志文件

為什么數(shù)據(jù)庫(kù)操作時(shí)總是未響應(yīng)？

1、并且對(duì)的的維護(hù)操作

很多的數(shù)據(jù)庫(kù)無(wú)做出反應(yīng)故障是由于不對(duì)的的維護(hù)不能操作過(guò)多的。應(yīng)盡量減少在業(yè)務(wù)高峰期做快的以維護(hù)操作，例如像MOVE、加主外鍵管理和約束等會(huì)長(zhǎng)時(shí)間鎖表的操作。要是確實(shí)是不需要，注意建議使用真確的操作方法。諸如用online重建索引；建主鍵、同樣鍵加以約束時(shí)先建索引，后再待建強(qiáng)制力時(shí)委托新建的索引等等。也就是只要系統(tǒng)的并發(fā)性、可伸縮性，盡量減少系統(tǒng)串行操作的出現(xiàn)。

2、優(yōu)化應(yīng)用設(shè)計(jì)、優(yōu)化數(shù)據(jù)庫(kù)性能

為盡量避免性能問(wèn)題導(dǎo)致在業(yè)務(wù)高峰期數(shù)據(jù)庫(kù)肯定不能趕快管用一次性處理依附業(yè)務(wù)的請(qǐng)求，以至于完全HANG住。對(duì)于數(shù)據(jù)庫(kù)中存在的串行訪問(wèn)網(wǎng)絡(luò)的部分通過(guò)系統(tǒng)優(yōu)化，比如latch、enqueue，還除了不合理的sequence設(shè)計(jì)等。特別是在RAC數(shù)據(jù)庫(kù)中，嚴(yán)重串行不能訪問(wèn)等待并不一定更很難紊亂十分嚴(yán)重的性能問(wèn)題。優(yōu)化系統(tǒng)應(yīng)用設(shè)計(jì)，使數(shù)據(jù)庫(kù)具備更合適的可伸縮性和并行處理能力，也能比較有效地以免性能問(wèn)題影起的數(shù)據(jù)庫(kù)HANG住。

3、憑借監(jiān)控系統(tǒng)時(shí)刻遠(yuǎn)程監(jiān)控系統(tǒng)負(fù)載端

遇見(jiàn)系統(tǒng)負(fù)載過(guò)低，內(nèi)存不足，OS中虛擬內(nèi)存自動(dòng)換行很很頻繁等情況時(shí)，及時(shí)采取措施；監(jiān)控ORACLE數(shù)據(jù)庫(kù)的核心進(jìn)程，如pmon、smon等，看有無(wú)有異常，如過(guò)熱的CPU消耗。又出現(xiàn)十分應(yīng)立玄一次性處理；監(jiān)控歸檔空間的日志直接切換；監(jiān)控?cái)?shù)據(jù)庫(kù)中的靜靜的等待事件，例如是否有大量的enqueue、logfileswitch(archivingneeded)、resmgr:becomeactive靜靜的等待事件等。

4、為數(shù)據(jù)庫(kù)打上補(bǔ)丁

很多的無(wú)做出反應(yīng)故障是因此ORACLE的BUG引起的，數(shù)據(jù)庫(kù)DBA應(yīng)參與當(dāng)前版本中有哪些BUG會(huì)可能導(dǎo)致數(shù)據(jù)庫(kù)HANG住，最好不要為數(shù)據(jù)庫(kù)打上解決這些BUG的補(bǔ)丁。