项目在进行过程中，免不了会产生这样那样的问题。解决问题的关键是发现问题出在什么地方。

    首先，要从自己的身上找问题，看是不是自己想得不周到，分配工作不合适。如果主要问题在这里，就要勇于承担，要重新分配任务或采取一些必要的方法进行补救。

    其次，再从公司方面找问题，是不是给了员工太多不切实际的工作。如果是这样的话，那大部分人都会出问题，整个项目也必然会产生延期、质量很差等问题。 这类的问题在外包性质的公司也许比较多，也比较难已解决，这就需要大家好好座下来谈谈，如何提高员工素质，如何改进项目流程。

    最后，如果不是上述两方面的问题，那就要让对方好好想想他自己身上犯了那些错误了。做为一个员工，最重要的是责任心，如果没有了责任心，那其它都不用谈了。如果是其它问题，如家庭或个人方面出了问题，应当尽力帮助别人去解决。

    总之，产生问题就必须要解决的，处理问题的方式一定要先沟通，有时候是要给别人一些犯错的空间的。如果有了好的沟通，那大多问题基本上都解决了。如果沟通处理不了的事情，就一定要搞制度来办，而且是必须按制度来办。

    在lunix系统下,删除是没有提示的, 所以经常有删除数据文件的事情发生,导致数据库无法启动. 可以使用下面方法进行处理.

用系统用户进入系统.

在归档模式ARCHIVELOG下.

SQL>alter database datafile '/opt/oracle/data/SRV_BSS001' offline;

非归档模式UNARCHIVELOG下.

SQL>alter database datafile '/opt/oracle/data/SRV_BSS001' offline drop;

可以查询数据文件联、脱机状态.
SQL> select file#,name,status from v$datafile;

最后删除数据库表空间.

SQL> drop tablespace tablespace_name;

这里只是可以重新启动数据库, 但数据是没有办法恢复的, 所以大家在删除文件的时候一定要多加注意. 尤其是在删除LOG日志时,最容易发生误删事件了.

    在执行数据库脚本时常常在建完用户后没有切换用户, 导致在系统用户下建立过多无用对象. 如何删除这些对象就比较麻烦,一个个手动删除费时而且有可以删除错误. 今天研究出一个比较好的方法.

    在ORACLE系统用户下, 有一张DBA_OBJECTS表, 里面有所有用户的所有对象. 执行下面语句.

SQL> spool c:\drop.txt

SQL> select 'drop' || ' ' || t.object_type || ' ' || t.object_name || ';'

     from dba_objects t

     where t.created > sysdate -3 and t.owner='sys';

SQL> spool off

     这样可以生成一个文件, 包含所有要删除的对象语句, 执行便可以了.

     因为t.created > sysdate -3 指定了最近三天建立的对象, 系统对象是在建数据库的时候建立的,一般都很久了. 所以这里只是错误建立的对象

    一个项目，从测试方案到测试用例的编写，再到测试执行，测试报告的编写。所以光靠TC的力量是完全不够的，那怎么才能把握成员的工作是否到位呢？

    多开交流会议。

    首先、在项目初期，让每个人对自己所做的模块进行描述，如果他可以流利的说清楚自己的东西，那说明他对需求已经有了基本的了解。

    其次、在测试用例阶段，让每个人对自己所做的模块进行描述，要求可以在不查询文档的情况下说清楚功能使用了那些表，通知了那些部件。

    再次、在测试执行阶段，让每个人对自己的模块进行评估，他可以自信的说他的模块基本上没有问题了、没有遗漏。

    最后、可以查看他们的测试小结，如果是自己认真做完一个项目，一定有一些独到的见解和心得。

    如果上面每步骤都很顺利，恭喜你，你的项目是比较成功的，如果做不到，要越早发现越好，如果到了测试小结还有问题，那就需要重新考虑软件质量是否过硬了。

服务器前后台均为SUSE LINUX9.0 双CPU 8G内存 tomcat服务器

tomcat使用最小512M 最大1024M内存

最大进程数为200

使用spring连接沲，最大连接数目为150，最大空闲数为120。

数据库为oracle9i   AIX 四CPU 4G内存

最大连接数为300

使用LR进行性能测试, TPS在50的情况下

问题1  性统占用内存达到100%,

问题2  服务所后台提示"no more process",

问题3  服务器前台提示"open too many file"

问题4  某存贮过程执行时间达到了5秒钟

问题5  数据库所在机器CPU达到100%

解决过程: 因为有前后面服务, 先排除前后台通信问题. 因为是SOAP进行通信的, 所以建两个工程只进得简单的SOAP协议交互.

结论,TPS达到300, 前后台均在正常范围之内,可以说明SOAP并没有问题.

1、检查代码，发现记录日志模块每次都new一个对象出来， 没有释放。 造成内存占用过多，同时也打开了很多系统线程。

修改为单实例模式。

问题1及问题2解决。

2、检查代码，发现在写文件时，没有关闭文件连接。

关闭连接。

问题3解决

4、在该存贮过程中发现有SQL进行了大表的全表扫描。

 对该表根据些SQL建立合适的索引。

问题4解决

5、在检查了所有SQL都进行了索引查询， 但TOP5事件是还是有序列读占很多资源。

索引不合理，不应当使用联合索引， 这样大大影响了数据库性能。 对索引分开建立。

问题5解决

另外，如果TOMCAT没有足够的内存空间，会导致TOMCAT挂掉。数据库连接沲配置过小也会导致系统与数据库之单频繁建立连接，使数据库变化用户数过多，影响性能。

维护一个连接大约需要3M的内存，可以根据实际情况配置。 但够用就好，不是越大越好，维护这些连接也是有资源开销的。

可以发现，从配置到代码， 从代码到SQL，只要有小小的出入，都会造成严重的性能问题