顯式激活數據庫( ACTIVATE DATABASE)

        某天值班員聯繫我說，我負責的一套報送系統沒有按時生成報文，由於此報警提早量比較大，加上系統常常發生未按時生成報文的事件，也就是沒在乎，而後不急不慢的到公司，打開系統頁面，發現其中一個存儲過程跑了將近8小時還沒結束。以往這個存儲過程最長的運行記錄也就不到2小時，這確定有問題。查看前一天的運行記錄也是10個小時左右，在之前的記錄就都是半小時左右了，並且接着這個存儲過程運行的下一個批做業（一個JAVA程序），前一天也運行了1個小時，以往也就幾分鐘。爲了保證業務使用，聯繫了項目組，諮詢此存儲過程能夠先跳過不運行，因而force掉數據庫鏈接，接着就運行那個JAVA程序，但是運行也至關慢，tail輸出日誌，發現程序每處理一條記錄，都先數據庫鏈接，而且關閉，而後再處理一下條記錄（上次出現JAVA鏈接不能正常CLOSED，致使JAVA鏈接池耗盡，項目組修改了鏈接方式）。這種方式確定是不高效的，可是應該也至於這麼慢，10幾秒才處理一條記錄，確定有問題，由於這個JAVA程序已經上線好些日子了，爲何就這兩天才慢。        這個時候想起各位大神常常說的問題分析方法論了，方法論之一：最近系統有沒有作過改動，確實有，上週重啓過服務器，而且DB2進程使用雙機軟件拉起的，在拉起DB2進程的時候，沒有顯式激活數據庫，而這個系統沒有前臺應用，也就是說沒有長鏈接的數據鏈接到數據庫，數據庫在無鏈接狀況下，會釋放部分資源，只保留必要的一些資源，當在再次有應用鏈接到數據庫的時候，會從新導入相關資源，完成數據處理，這個初始化過程是一個比較耗時的操做（當執行db2start操做，若是沒顯式激活數據庫，第一次執行db2 conncet to dbname時候是否是感受很慢），分析到這來就馬上執行了ACTIVATE DATABASE操做，那個JAVA程序瞬間完成，至於以前的那個存儲過程，從新運行也是20分鐘左右完成，按推理，顯示激活數據庫應該不會影響到存儲過程的運行，可是事實就是影響了，以後日子沒有發生相似的問題。        建議對於沒有長鏈接的數據庫，若是此數據庫沒有運行其餘軟件，或者系統資源比較充足的狀況下，最好顯式激活數據庫