zoukankan      html  css  js  c++  java
  • 【Vegas摘录】Oracle编程高手箴言:位图索引(Bitmap Index)的故事

    今天,在复习042,发现了一道关于bitmap index的题目,让我困惑许久~ 最后,就在网上查了查,发现了一篇不错的文章,转至此。

    042的这道题是:
    Which two statements are true about a bitmap index? (Choose two.) 
    A) It 
    is recommended for the columns that have unique values.
    B) It can be converted 
    to a B-tree index by using the ALTER INDEX command.
    C) It has a bitmap segment 
    for each distinct value in the key column, containing a string of bits in 
        which each 
    bit represents the presence or absence of a key column value.
    D) Updating the 
    key column locks the whole bitmap segment that contains the bit for the key value 
        to be updated.
    答案为:CD
    ================================================================
    以下为该文章:
    原文地址:http://carllgc.blog.ccidnet.com/blog-htm-do-showone-uid-4092-itemid-291252-type-blog.html 
    Vegas


    您如果熟悉Oracle数据库,我想您对Thomas Kyte的大名一定不会陌生。Tomas主持的asktom.oracle.com网站享誉Oracle界数十年,绝非幸致。最近在图书馆借到这位Oracle绝顶高手编著的《Expert Oracle Database Architecture-9i and 10g programming Techniques and Solutions》,翻阅之下,果然盛名无虚,虽然说不上字字珠玑,但作者对Oracle架构的理解和实践确实已达到出神入化的境界。如果您有时间和兴趣,强烈建议您阅读这本书。这本书最大的特点是语言生动活泼,说理清楚,几乎每讲解一个原理,作者都给出了具体实例,让人读起来毫不气闷。

    另外,Thomas谦逊的态度让我非常佩服,ThomasOracle数据库方面工作了16年,并且参与了早期Oracle版本的开发,但他仍然谦虚地说,他每天都能从Oracle文档里学到新的东西。

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

    位图索引(Bitmap Index)的故事
    一日,一群Java开发者找到Tom先生,说他们新开发的系统已经上线,但性能及其低下,他们问Tom先生能不能替他们看看问题到底出在什么地方。他们告诉Tom,他们的系统采用JSP+EJB+Oracle的典型三层架构,其中EJB中的SQL是由第三方工具产生的。Tom同志一听到EJB,就知道这个系统是不能采用SQL代码跟踪的方法来进行性能调优了。于是,Tom同志告诉这些心急火燎的Java开发者,你们系统的问题肯定在浏览器到数据库之间,但具体问题出在什么地方,我需要看看你们的数据库。

    于是,Tom同志远程连接到他们的测试数据库(注意不是生产数据库),查看了几个动态性能视图(V$LOCKV$SQL),最后终于发现了问题的所在。Tom同志发现他们的数据库中有一个位图索引(Bitmap Index)最为可疑,这个索引是建立在一个PROCESS_FLAG的字段上,PROCESS_FLAG字段表示该记录是否被处理了,可能值只有两个,一个是未处理(N),一个是已经处理(Y)。当记录初次插入数据库时,该字段的值为N,但其它进程读取并处理那些未处理的记录(值为N的记录)后,这个字段的值就更新为Y

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

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

    Tom同志微微一笑,没有直接回答。只见他打开SQL Plus,连接到他的本地Oracle实例,给这群开发者演示了下面及其简单的SQL代码。

    C:\Documents and Settings\carlwu>sqlplus scott/tiger@carl

    SQL*Plus: Release 11.1.0.6.0 - Production on Wed Apr 23 18:15:34 2008

    Copyright (c) 1982, 2007, Oracle. All rights reserved.

    Connected to:

    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

    With the Partitioning, OLAP, Data Mining and Real Application Testing options

    SQL> create table t(processed_flag varchar2(1));

    Table created.

    SQL> create bitmap index t_idx on t(processed_flag);

    Index created.

    SQL> insert into t values('N');

    1 row created.

    SQL>

    刚才那位振振有词的开发者不服气的说,这有什么,不是很正常吗?接着Tom又打开了一个SQL Plus窗口,并连接到本地数据库,键入下面的SQL语句,奇怪的是这条SQL并不执行,而是一直在等待。下面是这条SQL的一个截图:

    这些Java开发者看到这里,惊讶得目瞪口呆。其中一个开发者犹豫地说,好象这个位图索引只允许一个用户操作,如果其它用户想同时操作这个索引,那他必须等第一个用户的请求处理完成,并且提交之后,才能进行,如果第一个用户不提交,那么他必须一直等待。Tom点头表示赞同,然后给他们作了一番详细的解释:

    Oracle数据库的位图索引(Bitmap Index)确实是针对那些数值稀疏(low-cardinality低基数)的字段,但是还应记住的一点是,它是针对那些值不经常改变的字段的。在实际应用中,如果某个字段的值需要频繁更新,那么就不适合在它上面创建位图索引。在位图索引中,如果你更新或插入其中一条数值为N的记录,那么相应表中数值为N的记录(可能成百上千条)全部被Oracle锁定,这就意味着其它用户不能同时更新这些数值为N的记录,其它用户必须要等第一个用户提交后,才能获得锁,更新或插入数据。

    问题找到了,修正就很简单了,Tom建议这些开发者去掉了这个位图索引,然后在PROCESS_FLAG字段上建立一个函数索引,只为那些数值为N的记录建立简单的B树索引就可以了。

    这些开发者回去后,按照Tom的指点,经过一番测试,终于解决了问题。

    但故事并没有到此结束,这些开发者并不满足,他们给Tomemail抱怨道,Oracle数据库真“烂”,连这个简单的位图索引问题都不能处理,你看,Oracle浪费了我们大量的时间和精力调试我们的Java程序。Tom给他们回了一封email,颇有感触地对他们说:

    I have encountered issues such as this many times when an application is being moved from database A to database B. When an application that worked flawlessly in database A does not work, or works in an apparently bizarre fashion, on database B, the first thought is that database B is “bad” database. The simple truth is that database B just works differently. Neither database is wrong or “bad; they are just different. Knowing and understanding how they both work will help you immensely in dealing with these issues.
    (当人们把一个应用从一种数据库迁移到另一种数据库时,他们常常抱怨同样的问题。本来这个应用程序在数据库A上运行得很好,当迁移到数据库B时,就出问题了。于是他们就认定,数据库B真烂。但事实并非如此,这只是因为数据库B的工作方式和原理不同于数据库A而已。世界上没有哪个数据库是“烂”数据库,关键是我们必须深入了解该数据库的架构和特点,这样才能避免这类问题。如果您理解位图索引的适用条件,您还会说Oracle是一个很“烂“的数据库吗?)

    最后,Tom乘机建议他们,如果你们愿意,我可以给你们做一次简单的为期3天的培训。这些Java程序员听从了Tom同志的建议,经过了3天的培训后,他们对Oracle能做的事情表示吃惊,他们纷纷表示,“我真傻,原来Oracle不适合建立临时表呀,你看我的程序老是在那里删除和创建临时表。”,“要是我用了物化视图(Materalized View),我的数据备份代码就异常简单了。”,“我还不知道connect by有这么强大的功能呢!”。

    参考文献:
    Thomas Kyte, 2005, Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions.

  • 相关阅读:
    AtCoder Grand Contest 015 题解
    AtCoder Grand Contest 014 题解
    AtCoder Grand Contest 013 题解
    AtCoder Grand Contest 012 题解
    AtCoder Grand Contest 011 题解
    AtCoder Grand Contest 010 题解
    AtCoder Grand Contest 009 题解
    NOIP2017 Day2 题解
    博客园主题备份
    多项式全家桶
  • 原文地址:https://www.cnblogs.com/amadeuslee/p/3744313.html
Copyright © 2011-2022 走看看