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謙遜的態度讓我非常佩服,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

 


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com