学习《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）列，所谓低基数列就是指这个列只有很少的可取值
相关文档：
虽然学习Java很久了，自己也连接过一些数据库，比如mysql之类的，如今呢，也学习了一段时间的Oracle，然而呢，今天是我第一次连接Oracle，嘿嘿，应该还不算太迟吧。
今天呢，有点笨拙，大家莫笑！
我这是一个查询例子
首先，� ......
--1:无ORDER BY排序的写法。(效率最高)
--(经过测试，此方法成本最低，只嵌套一层，速度最快！即使查询的数据量再大，也几乎不受影响，速度依然！)
SELECT *
from (Select ROWNUM AS ROWNO, T.*
from k_task T &s ......
数学函数
1.绝对值
S:select abs(-1) value
O:select abs(-1) value from dual
2.取整(大)
S:select ceiling(-1.001) value
O:select ceil(-1.001) value from dual
3.取整（小）
S:select floor(-1.001) value
O:select floor(-1.001) value from dual
4.取整（截取）
S:select cast(-1.002 as in ......
SELECT max(SYS_CONNECT_BY_PATH(COLUMN_NAME, ','))
from (SELECT A.COLUMN_NAME, ROWNUM AS ROWNO
from USER_TAB_COLUMNS A
WHERE TABLE_NAME = 'A_USER'
......
select to_char(sysdate + 1 / (24 * 60),'yyyy/mm/dd hh24:mi:ss') from dual
SQL> ;
1 select to_char(sysdate, 'hh:mi:ss')
2 &nbs ......
