性能调优step by step (三) --遇到的问题(数据库)
1. Webtrace 分析sql 性能，发现

userPermissionService.listVAccountIdsByUserIdAndProductCode

是数据库未分析数据，执行方案是基于开销的方式，导致执行计划未走到索引。后来是走的索引，但是仍然较慢。

分析：
kill -3后查看jboss 日志发现很多都在执行listVAccountIdsByUserIdAndProductCode 这个代码
由于apache 线程池都进行了调整，有足够多的等待线程，不太会导致BLOCKED，这样runnble 的较多都集中在这个代码上，就说明线程在这里比较占用时间。（用vi 不要用 tail）
这个sql有问题：

select pup.vaccount_id
    from pc2_user_permission pup
   where pup.product_code = #productCode#
     and pup.user_id = #userId#
     and pup.acl = '1'

没有走正确的索引，目前只有product_code  +user_id的索引，需要建立
product_code  +user_id + acl的索引


解决方法：DBA 进行oracle 的数据分析，然后再跑，或者delete掉数据，这和应用进行delete一样，数据库会自动进行数据分析和重建索引等。
对于走了索引仍然较慢的情况，加上含有acl的索引，这样就不用查询数据库了，速度会快比较多。







2. 测试apache 和jboss 性能对比情况时，发现和QA使用jmeter测试的结果不一致，本机测试apache 较好，QA测试 jboss反而更优。
本机测试，多数情况是apache 较好，QA使用jmeter做大并发时，数据库连接数是个瓶颈，经常over-load。
解决办法：需要让DBA 再把数据最大连接数调大些， process给调成250。


3.       不断执行压力测试，表空间占满。
分析：不停的delete 和insert时会有碎片产生，这样oracle自己的回收机制来不及做，就会导致原来占一个G的数据，现在就要占5G并且会增加insert的成本，导致插入数据时非常慢。
处理方法：正常情况下是会自动回收的。只要在高并发情况下才会出现这种情况,原来表空间6G，目前增加到10G， DBA进行碎片整理。


4. DBA调整了事务管理块及insert预分配空间，调整后性能有所提高，大概提高10%左右
因为PC2中有大量的insert操作，DBA认为insert操作时，若有较多的磁盘碎片，会对insert性能产生影响 ，所以为此预分配了一定空间，所有的插入操作都是往预分配空间插入，这样省去了寻址的时间。

5. 报数据库已经关闭异常，jboss log 报出

ERROR com.mchange.v2.resourcepool.BasicResourcePool :: com.mchange.v2.resourcepool.BasicResourcePool@5b553d28 -- Unexpectedly broken!!!
com.mchange.v2.resourcepool.ResourcePoolException: Unexpected Break Stack Trace!

解决方法：修改pc2-spring-common.xml  中C3P0配置，将其如下值修改

<property name="breakAfterAcquireFailure" value="false" />

此问题较为普遍，在UDB和原来PCC都有发生，发生场景为不少连接被占用（本次是被预发环境占用）资源发生竞争时，如果设置为true,已经被占用的连接，就会直接报出异常，如果为false ，他会去尝试再获取下，短链接的情况下会很快释放的，这样就不会报出异常了。




6. 多次fetch的数据问题

  webtrace是一个很不错的SQL跟踪工具
  通过查看trace得到的SQL执行情况，问题一可以很容易查到原因，问题三的原因也由此可以看出来。
  虽然走到索引，但fetch次数太多（ibatis是以object来传输的，查到了这么多数据，取了这么多次，肯定是耗费很大性能的）。数据存在问题。