Oracle中关于bitmap index的使用问题

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

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

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

位图索引 (Bitmap Index) 的故事

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

于是, Tom 同志远程连接到他们的测试数据库(注意不是生产数据库),查看了几个动态性能视图 (V$LOCK 和 V$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/[email protected]
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 的指点,经过一番测试,终于解决了问题。

但故事并没有到此结束,这些开发者并不满足,他们给 Tom 写 email 抱怨道, 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 有这么强大的功能呢!”。

文章转自:http://www.linuxidc.com/Linux/2011-10/45487.htm

时间: 2024-10-01 03:00:49

Oracle中关于bitmap index的使用问题的相关文章

Oracle中synonym和index

笔记: Oracle-同义词--通过用户名(模式名).表名       --授权:grant create synonym to test1(system用户下授权))     --私有  create or replace synonym sy_test1 for gcs95.test1;  --共有  create public synonym public_sy_test1 for gcs95.test1;  /*私有:其他用户无法访问*/  select * from sy_test1;

Oracle中查询时候使index索引失效的限制条件

昨天,由于最近的项目需要进入到测试人员进行测试的阶段.因此,自己搭建好了测试环境---进行了测试.但是,奇怪的事情就发生了.以前在我自己本地开发的环境的时候却没有碰到这个问题. 由于在测试环境执行的查询的时候,不管怎么做,总是会查询失败,并且前台抛出"无法连接,请联系系统管理员"异常,开始,我就不断的跟踪这个异常, 第一:在前台找了好久  也设置了相应的response====timeout时间参数为60s.再去执行,还是查询失败.因此,否定了这个原因. 第二:我使用Debug模式去调

【Bitmap Index】B-Tree索引与Bitmap位图索引的锁代价比较研究

通过以下实验,来验证Bitmap位图索引较之普通的B-Tree索引锁的“高昂代价”.位图索引会带来“位图段级锁”,实际使用过程一定要充分了解不同索引带来的锁代价情况. 1.为比较区别,创建两种索引类型的测试表1)在表t_bitmap上创建位图索引[email protected]> create table t_bitmap (id number(10), name varchar2(10),sex varchar2(1)); Table created. [email protected]>

Oracle中的索引详解(转载)

一. ROWID的概念 存储了row在数据文件中的具体位置:64位 编码的数据,A-Z, a-z, 0-9, +, 和 /, row在数据块中的存储方式 SELECT ROWID, last_name FROM hr.employees WHERE department_id = 20; 比 如:OOOOOOFFFBBBBBBRRR OOOOOO:data object number, 对应dba_objects.data_object_id FFF:file#, 对应v$datafile.fi

[转]Oracle中的索引详解

原文地址:http://www.oschina.net/question/30362_4057 一. ROWID的概念 存储了row在数据文件中的具体位置:64位 编码的数据,A-Z, a-z, 0-9, +, 和 /, row在数据块中的存储方式 SELECT ROWID, last_name FROM hr.employees WHERE department_id = 20; 比 如:OOOOOOFFFBBBBBBRRR OOOOOO:data object number, 对应dba_o

ORACLE中死锁

ORACLE中死锁的知识点总结   死锁的概念 什么是死锁呢? 其实我们生活中也有很多类似死锁的例子. 我先举一个生活中的例子:过年回家,父亲买了一把水弹枪,儿子和侄子争抢着要先玩,谁也不让谁,拆开包装后,一个抢了枪, 一个逮住了子弹和弹夹.两个都争着要先玩,但是都互不相让.结果两个人都玩不了.如果儿子要先玩,就必须让侄子把子弹和弹夹给他,如果侄子要先玩,就必须让儿子把枪给侄子.他们就这样对峙了十几分钟,互不相让. 我出来调停,让儿子把枪先给侄子玩,每个人玩十分钟.然后两个人开开心心一起玩起来.

Oracle中常见的Hint(一)

Oracle中的Hint可以用来调整SQL的执行计划,提高SQL执行效率.下面分类介绍Oracle数据库中常见的Hint.这里描述的是Oracle11gR2中的常见Hint,Oracle数据库中各个版本中的Hint都不尽相同,所以这里讲述的的Hint可能并不适用于Oracle早期的版本. 一.与优化器模式相关的Hint 1.ALL_ROWS ALL_ROWS是针对整个目标SQL的Hint,它的含义是让优化器启用CBO,而且在得到目标SQL的执行计划时会选择那些吞吐量最佳的执行路径.这里的"吞吐量

索引优化原则及Oracle中索引总结

索引建立原则 确定针对该表的操作是大量的查询操作还是大量的增删改操作. 尝试建立索引来帮助特定的查询.检查自己的sql语句,为那些频繁在where子句中出现的字段建立索引. where语句中不得不对查询列采用函数查询,如upper函数,最好建立相应函数索引: 在SQL语句中经常进行GROUP BY.ORDER BY的字段上建立索引 用于联接的列(主健/外健)上建立索引: 在经常存取的多个列上建立复合索引,但要注意复合索引的建立顺序要按照使用的频度来确定: 尝试建立复合索引来进一步提高系统性能.修

Oracle中分区表的使用

   查询分区:Select *From user_extents WHERE partition_name='分区名'; 1)创建表空间 create tablespace HRPM0 datafile '/oradata/misdb/HRPM0.DBF' size 5m autoextend on next 10m maxsize unlimited 2)删除表空间(同时把数据文件也删除) DROP TABLESPACE data01 INCLUDING CONTENTS AND DATAF