Oracle編程高手箴言，位圖索引的story
我想熟悉Oracle數(shù)據(jù)庫的人，一般對這位Oracle高手中的高手編著的《ExpertOracleDatabaseArchitecture-9iand10gprogrammingTechniquesandSolutions》，有所了解吧！同時我也建議大家有時間的話，翻閱一下這本書，會對你在Oracle數(shù)據(jù)庫的學(xué)習(xí)有很大的幫助。
如果您有時間和興趣，強烈建議您閱讀這本書。這本書最大的特點是語言生動活潑，說理清楚，幾乎每講解一個原理，作者都給出了具體實例，讓人讀起來毫不氣悶。
另外，Thomas謙遜的態(tài)度讓我非常佩服，Thomas在Oracle數(shù)據(jù)庫方面工作了16年，并且參與了早期Oracle版本的開發(fā)，但他仍然謙虛地說，他每天都能從Oracle文檔里學(xué)到新的東西。
下面從這本書里摘錄了一些精彩片段，供您欣賞，雖然不免有斷章取義之嫌。
位圖索引(BitmapIndex)的故事
一日，一群Java開發(fā)者找到Tom先生，說他們新開發(fā)的系統(tǒng)已經(jīng)上線，但性能及其低下，他們問Tom先生能不能替他們看看問題到底出在什么地方。他們告訴Tom，他們的系統(tǒng)采用JSP+EJB+Oracle編程的典型三層架構(gòu)，其中EJB中的SQL是由第三方工具產(chǎn)生的。
Tom同志一聽到EJB，就知道這個系統(tǒng)是不能采用SQL代碼跟蹤的方法來進(jìn)行性能調(diào)優(yōu)了。于是，Tom同志告訴這些心急火燎的Java開發(fā)者，你們系統(tǒng)的問題肯定在瀏覽器到數(shù)據(jù)庫之間，但具體問題出在什么地方，我需要看看你們的數(shù)據(jù)庫。
于是，Tom同志遠(yuǎn)程連接到他們的測試數(shù)據(jù)庫（注意不是生產(chǎn)數(shù)據(jù)庫），查看了幾個動態(tài)性能視圖(V$LOCK和V$SQL)，最后終于發(fā)現(xiàn)了問題的所在。Tom同志發(fā)現(xiàn)他們的數(shù)據(jù)庫中有一個位圖索引(BitmapIndex)最為可疑，這個索引是建立在一個PROCESS_FLAG的字段上，PROCESS_FLAG字段表示該記錄是否被處理了，可能值只有兩個，一個是未處理(N)，一個是已經(jīng)處理(Y)。
當(dāng)記錄初次插入數(shù)據(jù)庫時，該字段的值為N，但其它進(jìn)程讀取并處理那些未處理的記錄(值為N的記錄)后，這個字段的值就更新為Y。
Tom就問這些Java開發(fā)者，你們?yōu)槭裁匆谶@個PROCESS_FLAG字段上建立位圖索引呢？
其中有一個開發(fā)者振振有詞的說，這是為了提高查找速度，一旦建立了位圖索引，我們的程序就能快速找到那些數(shù)值為N的記錄，然后處理。隨后，他又拿出一本大部頭的Oracle數(shù)據(jù)庫參考手冊，對Tom同志說，這書上都是這么說的，對那些數(shù)值非常少的字段，比如，我們的PROCESS_FLAG字段只有兩個值，就應(yīng)該建立位圖索引，這難道有什么問題嗎？
Tom同志微微一笑，沒有直接回答。只見他打開SQLPlus，連接到他的本地Oracle編程實例，給這群開發(fā)者演示了下面及其簡單的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>
剛才那位振振有詞的開發(fā)者不服氣的說，這有什么，不是很正常嗎？接著Tom又打開了一個SQLPlus窗口，并連接到本地數(shù)據(jù)庫，鍵入下面的SQL語句，奇怪的是這條SQL并不執(zhí)行，而是一直在等待。下面是這條SQL的一個截圖，
- '800')this.width='800';if(this.height>'600')this.height='600';"border=0>
這些Java開發(fā)者看到這里，驚訝得目瞪口呆。其中一個開發(fā)者猶豫地說，好象這個位圖索引只允許一個用戶操作，如果其它用戶想同時操作這個索引，那他必須等第一個用戶的請求處理完成，并且提交之后，才能進(jìn)行，如果第一個用戶不提交，那么他必須一直等待。Tom點頭表示贊同，然后給他們作了一番詳細(xì)的解釋：
Oracle數(shù)據(jù)庫的位圖索引(BitmapIndex)確實是針對那些數(shù)值稀疏(low-cardinality，低基數(shù))的字段，但是還應(yīng)記住的一點是，它是針對那些值不經(jīng)常改變的字段的。在實際應(yīng)用中，如果某個字段的值需要頻繁更新，那么就不適合在它上面創(chuàng)建位圖索引。
在位圖索引中，如果你更新或插入其中一條數(shù)值為N的記錄，那么相應(yīng)表中數(shù)值為N的記錄（可能成百上千條）全部被Oracle編程鎖定，這就意味著其它用戶不能同時更新這些數(shù)值為N的記錄，其它用戶必須要等第一個用戶提交后，才能獲得鎖，更新或插入數(shù)據(jù)。
問題找到了，修正就很簡單了，Tom建議這些開發(fā)者去掉了這個位圖索引，然后在PROCESS_FLAG字段上建立一個函數(shù)索引，只為那些數(shù)值為N的記錄建立簡單的B樹索引就可以了。這些開發(fā)者回去后，按照Tom的指點，經(jīng)過一番測試，終于解決了問題。
但故事并沒有到此結(jié)束，這些開發(fā)者并不滿足，他們給Tom寫email抱怨道，Oracle數(shù)據(jù)庫真“爛”，連這個簡單的位圖索引問題都不能處理，你看，Oracle浪費了我們大量的時間和精力調(diào)試我們的Java程序。是他們就認(rèn)定，數(shù)據(jù)庫B真爛。但事實并非如此，這只是因為數(shù)據(jù)庫B的工作方式和原理不同于數(shù)據(jù)庫A而已。
世界上沒有哪個數(shù)據(jù)庫是“爛”數(shù)據(jù)庫，關(guān)鍵是我們必須深入了解該數(shù)據(jù)庫的架構(gòu)和特點，這樣才能避免這類問題。如果您理解位圖索引的適用條件，您還會說Oracle是一個很“爛“的數(shù)據(jù)庫嗎？)
最后，Tom乘機建議他們，如果你們愿意，我可以給你們做一次簡單的為期3天的培訓(xùn)。這些Java程序員聽從了Tom同志的建議，經(jīng)過了3天的培訓(xùn)后，他們對Oracle能做的事情表示吃驚，他們紛紛表示，“我真傻，原來Oracle編程不適合建立臨時表呀，你看我的程序老是在那里刪除和創(chuàng)建臨時表。”，“要是我用了物化視圖(MateralizedView)，我的數(shù)據(jù)備份代碼就異常簡單了。”，“我還不知道connectby有這么強大的功能呢！”。
【編輯推薦】
