上周我们的dms系统出问题，并发用户数一多，数据库的连接就会不断往上升，一会就把数据库给跑死了。这个系统是原来另一个项目经理负责的，现在要走人，结果就丢给我了。
才拿到这个系统就发现很多文档和资料都不齐，此外已经用了3年，真可谓是补丁叠补丁，怎一个乱字了得！而且原来这个项目的人基本已经都走光了！直接跑去跟副总说，结果一通教育回来就是死活都由你负责了（后来才知道那个系统是出来名的乱，没人肯接），说是我新做的一个doms系统跟这个系统在业务上有很多联系，就只有我合适接这个任务……等等。
唉！！命苦，这种事就来找我，发钱怎么总不先想到我
抱怨归抱怨，出来问题总的搞定。dms这个系统是给大众的经销商用来卖车的，才停了2个小时，客服和大众总公司哪边就快炸锅了。
还好从周一到周四天天通宵，总算搞定。期间请了不少高手，也算是学到不少，算是没有白白通宵那么多天！
总结一下教训：
1、对于这样的大系统，并发用户那么多，设计时候就应该考虑到，做一些总体上的优化设计。至少统计报表不要跑在业务系统的服务器上吧！！
2、服务器应定期维护，否则功能再强劲也经不起几年大负荷的折腾啊。这个系统的服务器据我所致，3年才停过一次，还是停电，而且没有日常维护！
3、对于需求变化，应该尽量做到重构系统，包括代码和数据库；业务数据没用的应设置计划定期备份出业务系统。
4、数据库优化。由于系统的sql应该优化过多次，基本已经没有什么直接优化的余地了。这次请了一个比较资深的高手过来，对于ORACLE玩的很熟，分析完数据表后，用hint直接指定rule作为sql的优化器，竟然将几句原来运行几十秒的sql一下子优化成几百ms级，而且只在sql前加了/*+rule*/这一句。看来自己这块是太菜鸟了，想想要是我的组里能有这样一位……
（hint这块确实要好好研究一下了）
上面几条看起来好像都很简单，但是真的能做到确实很难，在进度压力和资源戏缺的情跨下，常常是能保证完成任务就算万事大吉拉～～～～～唉！