学习《Oracle 9i10g编程艺术》的笔记 (一)

1.位图索引
最近我参与了一个项目。开发人员正饱受性能问题之苦，看上去他们的系统中许多事务在串行
进行。他们的做法不是大家并发地工作，而是每个人都要排一个长长的队，苦苦等着前面的人完成后才能
继续。应用架构师向我展示了系统的体系结构，这是经典的三层方法。他们想让Web 浏览器与一个运行JSP
（JavaServer Pages）的中间层应用服务器通信。JSP 再使用另一个EJB（Enterprise JavaBeans）层，在
这一层执行所有SQL。EJB 中的SQL 由某个第三方工具生成，这是采用一种数据库独立的方式完成的。
现在看来，对这个系统很难做任何诊断，因为没有可测量或可跟踪的代码。测量代码（instrumenting
code）堪称一门艺术，可以把开发的每行代码变成调试代码，这样就能跟踪应用的执行，遇到性能、容量
甚至逻辑问题时就能跟踪到问题出在哪里。在这里，我们只能肯定地说问题出在“浏览器和数据库之间的
某个地方”。换句话说，整个系统都是怀疑对象。对此有好消息也有坏消息。一方面，Oracle 数据库完全
可测量；另一方面，应用必须能够在适当的位置打开和关闭测量，遗憾的是，这个应用不具备这种能力。
51
/ 849
所以，我们面对的困难是，要在没有太多细节的情况下诊断出导致性能问题的原因，我们只能依靠从
数据库本身收集的信息。一般地，要分析应用的性能问题，采用应用级跟踪更合适。不过，幸运的是，这
里的解决方案很简单。通过查看一些Oracle V$表（V$ 表是Oracle 提供其测量结果或统计信息的一种方
法），可以看出，竞争主要都围绕着一个表，这是一种排队表。结论是根据V$LOCK 视图和V$SQL 做出的，
V$LOCK 视图可以显示阻塞的会话，V$SQL 会显示这些阻塞会话试图执行的SQL。应用想在这个表中放记录，
而另外一组进程要从表中取出记录并进行处理。通过更深入地“挖掘”，我们发现这个表的PROCESSED_FLAG
列上有一个位图索引。
注意第12 章会详细介绍位图索引，并讨论为什么位图索引只适用于低基数值，但是对频繁更新的列不
适用。
原因在于，PROCESSED_FLAG 列只有两个值：Y 和N。对于插入到表中的记录，该列值为N（表示未处
理）。其他进程读取和处理这个记录时，就会把该列值从N 更新为Y。这些进程要很快地找出PROCESSED_FLAG
列值为N 的记录，所以开发人员知道，应该对这个列建立索引。他们在别处了解到，位图索引适用于低基
数（low-cardinality）列，所谓低基数列就是指这个列只有很少的可取值