<b>Oracle编程高手箴言,位图索引的story</b>[Oracle防范]

我想熟习Oracle数据库的人,普通对这位Oracle高手中的高手编著的《ExpertOracleDatabaseArchitecture-9iand10gprogrammingTechniquesandSolutions》,有所理解吧!同时我也倡议大家有时间的话,翻阅一下这本书,会对你在Oracle数据库的学习有很大的帮忙.

假如您有时间和爱好,激烈倡议您阅读这本书.这本书最大的特点是语言活泼活泼,说理清楚,几近每讲授一个原理,作者都给出了具体实例,让人读起来毫不气闷.

别的,Thomas谦虚的态度让我非常敬佩,Thomas在Oracle数据库方面工作了16年,并且参与了早期Oracle版本的开辟,但他仍旧谦虚地说,他每天都能从Oracle文档里学到新的东西.

下面从这本书里摘录了一些精彩片段,供您赏识,固然不免有断章取义之嫌.

位图索引(BitmapIndex)的故事

一日,一群Java开辟者找到Tom先生,说他们新开辟的系统已经上线,但性能及其低下,他们问Tom先生能不能替他们看看问题到底出在什么地方.他们奉告Tom,他们的系统采取JSP+EJB+Oracle编程的典型三层架构,此中EJB中的SQL是由第三方工具产生的.

Tom同志一听到EJB,就知道这个系统是不能采取SQL代码跟踪的办法来举行性能调优了.于是,Tom同志奉告这些心急火燎的Java开辟者,你们系统的问题必定在浏览器到数据库之间,但具体问题出在什么地方,我需求看看你们的数据库.

于是,Tom同志远程衔接到他们的测试数据库（注意不是生产数据库）,查看了几个动态性能视图(V$LOCK和V$SQL),最后终于发现了问题的所在.Tom同志发现他们的数据库中有一个位图索引(BitmapIndex)最为可疑,这个索引是成立在一个PROCESS_FLAG的字段上,PROCESS_FLAG字段表示该记录能否被处理了,大概值只有两个,一个是未处理(N),一个是已经处理(Y).

当记录初次插入数据库时,该字段的值为N,但别的进程读取并处理那些未处理的记录(值为N的记录)后,这个字段的值就更新为Y.

Tom就问这些Java开辟者,你们为什么要在这个PROCESS_FLAG字段上成立位图索引呢?

此中有一个开辟者振振有词的说,这是为了提高查找速度,一旦成立了位图索引,我们的程序就可以快速找到那些数值为N的记录,然后处理.随后,他又拿出一本大部头的Oracle数据库参考手册,对Tom同志说,这书上都是这么说的,对那些数值非常少的字段,比方,我们的PROCESS_FLAG字段只有两个值,就应当成立位图索引,这莫非有什么问题吗?

Tom同志微微一笑,没有直接答复.只见他翻开SQLPlus,衔接到他的本地Oracle编程实例,给这群开辟者演示了下面及其简单的SQL代码.

C:\DocumentsandSettings\carlwu>sqlplusscott/
tiger@carlSQL*Plus:Release11.1.0.6.0
-ProductiononWedApr2318:15:342008  
Copyright(c)1982,2007,Oracle.Allrightsreserved.  
Connectedto:  
OracleDatabase11gEnterpriseEditionRelease
11.1.0.6.0-Production  
WiththePartitioning,OLAP,
DataMiningandRealApplicationTestingoptions  
SQL>createtablet(processed_flagvarchar2(1));  
Tablecreated.  
SQL>createbitmapindext_idxont(processed_flag);  
Indexcreated.  
SQL>insertintotvalues('N');  
1rowcreated.  
SQL>    

方才那位振振有词的开辟者不平气的说,这有什么,不是很正常吗?接着Tom又翻开了一个SQLPlus窗口,并衔接到本地数据库,键入下面的SQL语句,奇特的是这条SQL并不履行,而是一向在等候.下面是这条SQL的一个截图,

'800')this.width='800';if(this.height>'600')this.height='600';"border=0> 

这些Java开辟者看到这里,惊奇得目瞪口呆.此中一个开辟者犹豫地说,好象这个位图索引只答应一个用户操作,假如别的用户想同时操作这个索引,那他必须等第一个用户的恳求处理完成,并且提交之后,才能举行,假如第一个用户不提交,那么他必须一向等候.Tom点头表示赞成,然后给他们作了一番具体的注释:

Oracle数据库的位图索引(BitmapIndex)确切是针对那些数值稀疏(low-cardinality,低基数)的字段,但是还应记着的一点是,它是针对那些值不常常改变的字段的.在实际利用中,假如某个字段的值需求频繁更新,那么就不合适在它上面成立位图索引.

在位图索引中,假如你更新或插入此中一条数值为N的记录,那么呼应表中数值为N的记录（大概成百上千条）全部被Oracle编程锁定,这就意味着别的用户不能同时更新这些数值为N的记录,别的用户必必要等第一个用户提交后,才能得到锁,更新或插入数据.

问题找到了,改正就很简单了,Tom倡议这些开辟者去掉了这个位图索引,然后在PROCESS_FLAG字段上成立一个函数索引,只为那些数值为N的记录成立简单的B树索引便可以了.这些开辟者回去后,按照Tom的指导,经过一番测试,终于办理了问题.

但故事并没有到此完毕,这些开辟者并不满意,他们给Tom写email抱怨道,Oracle数据库真“烂”,连这个简单的位图索引问题都不能处理,你看,Oracle浪费了我们大量的时间和精神调试我们的Java程序.是他们就认定,数据库B真烂.但事实并非如此,这只是因为数据库B的工作方法和原理差别于数据库A罢了.

世界上没有哪个数据库是“烂”数据库,关键是我们必须深化理解该数据库的架构和特点,这样才能避免这类问题.假如您理解位图索引的实用条件,您还会说Oracle是一个很“烂“的数据库吗?)

最后,Tom乘机倡议他们,假如你们乐意,我可以给你们做一次简单的为期3天的培训.这些Java程序员顺从了Tom同志的倡议,经过了3天的培训后,他们对Oracle能做的事情表示吃惊,他们纷纷表示,“我真傻,本来Oracle编程不合适成立暂时表呀,你看我的程序老是在那边删除和成立暂时表.”,“如果我用了物化视图(MateralizedView),我的数据备份代码就非常简单了.”,“我还不知道connectby有这么强盛的功效呢!”. 　　以上是“<b>Oracle编程高手箴言,位图索引的story</b>[Oracle防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：