oracle位图索引引发的系统问题
客户反映情况：**系统的个人信息维护模块响应时间太长，一个新增(或修改)操作要等上10分钟到30分钟才能完成。(注：在用户数大的时间这种情况更突出)
硬件环境：IIS服务器，IBM服务器(8个双核CPU，16GB内存)；数据库服务器，IBM小型机(8CPU，7328MB内存)
数据库服务器软件环境：AIX5.3操作系统；oracle 10.2.0.1.0
根据用户反映的情况，问题可能出现在两个方面：一是程序上的问题；另一是服务器的问题。通过与软件工程师了解之后，确定了程序上不存在性能的问题，那很有可能问题就出在服务器上。远程查看了IIS服务器，CPU的使用率(15%左右)与内存的使用率(20%左右)都是比较低的。可见IIS服务器引发问题的可能性也很小。再查看数据库服务器情况：通过ps -ef|grep LOCAL='NO'|wc -l发现当前的用户数为350，也是比较低的一个数；通过 iostat -t 1 10查询显示：%iowait值也在5至20之间，不存在IO问题；通过topas统计显示得到的CPU使用情况：
CPU User% Kern% Wait% Idle%
ALL 13.8 3.5 14.7 68.1
CPU使用情况也正常。
通过PLSQL工具查看当前用户的操作及等待情况：
由上图可见有很多Insert into...操作在等待锁，且引起锁等待的对象都为TBL_QY_DATABASE表(即个人信息模块用到的数据表)，问题总算清晰了许多，从ASH报告中的Top DB Objects可以更清楚看到JSQUANYUAN.INDEX_ISDELETE_BASE (INDEX)引起enq：TX-row lock contention。在数据库中表TBL_QY_DATABASE中查到INDEX_ISDELETE_BASE是一个位图索引，问题得到了进一步的解决，因为对于位图索引，只要有一个事务(用户操作)更新它，其它事务(用户操作)将被阻塞。所以造成了用户的操作被挂起，一直处于等待锁。反应到系统也就是用户所描述的慢。
经用户同意后kill用户的操作，删除INDEX_ISDELETE_BASE位图索引，用户再次使用系统，用户问题得以解决，再次查看当前用户的session，没有发现等待事件。
位图索引(位图索引，一个键指向多行，有时候是数以百计甚至更多。如果更新了一个位图索引键，那么这个键指向的数以百计的记录会与你实际更新的那一行一同被锁定。)虽然在某些情况下能够起到比B树索引更好的效果，但是需要注意的是，并不是在任何场合都有效，就像上述的情况，集中并发写入的环境中极度的糟糕，严重抑制并发性。所以在使用位图索引时应慎重考虑。