上周我們的dms系統出問題，并發用戶數一多，數據庫的連接就會不斷往上升，一會就把數據庫給跑死了。這個系統是原來另一個項目經理負責的，現在要走人，結果就丟給我了。
才拿到這個系統就發現很多文檔和資料都不齊，此外已經用了3年，真可謂是補丁疊補丁，怎一個亂字了得！而且原來這個項目的人基本已經都走光了！直接跑去跟副總說，結果一通教育回來就是死活都由你負責了（后來才知道那個系統是出來名的亂，沒人肯接），說是我新做的一個doms系統跟這個系統在業務上有很多聯系，就只有我合適接這個任務……等等。
唉！！命苦，這種事就來找我，發錢怎么總不先想到我
抱怨歸抱怨，出來問題總的搞定。dms這個系統是給大眾的經銷商用來賣車的，才停了2個小時，客服和大眾總公司哪邊就快炸鍋了。
還好從周一到周四天天通宵，總算搞定。期間請了不少高手，也算是學到不少，算是沒有白白通宵那么多天！
總結一下教訓：
1、對于這樣的大系統，并發用戶那么多，設計時候就應該考慮到，做一些總體上的優化設計。至少統計報表不要跑在業務系統的服務器上吧！！
2、服務器應定期維護，否則功能再強勁也經不起幾年大負荷的折騰啊。這個系統的服務器據我所致，3年才停過一次，還是停電，而且沒有日常維護！
3、對于需求變化，應該盡量做到重構系統，包括代碼和數據庫；業務數據沒用的應設置計劃定期備份出業務系統。
4、數據庫優化。由于系統的sql應該優化過多次，基本已經沒有什么直接優化的余地了。這次請了一個比較資深的高手過來，對于ORACLE玩的很熟，分析完數據表后，用hint直接指定rule作為sql的優化器，竟然將幾句原來運行幾十秒的sql一下子優化成幾百ms級，而且只在sql前加了/*+rule*/這一句。看來自己這塊是太菜鳥了，想想要是我的組里能有這樣一位……
（hint這塊確實要好好研究一下了）
上面幾條看起來好像都很簡單，但是真的能做到確實很難，在進度壓力和資源戲缺的情跨下，常常是能保證完成任務就算萬事大吉拉～～～～～唉！