有個誤區：Oracle的表分區會增加查詢性能，因為只需要在部分數據里查了；會增加降低插入性能，因為多了一步指定分區的操作。實際情況并非如此，至少在OLTP系統中，分區不一定會增加查詢性能，但很可能會增加插入性能。

　　引用Tom大神的《Oracle編程藝術》的一段話，很好地解釋了分區對OLTP系統的性能影響：

　　在OLTP系統中，不應該把分區當作一種大幅改善查詢性能的方法。實際上，在一個傳統的OLTP系統中，你必須很小心地應用分區，提防著不要對運行時性能產生負面作用。在傳統的OLTP系統中，大多數查詢很可能幾乎立即返回，而且大多數數據庫獲取可能都通過一個很小的索引區間掃描來完成。因此，以上所列分區性能方面可能 的主要優點在OLTP系統中表現不出來。分區消除只在大對象全面掃描時才有用，因為通過分區消除，你可以避免對對象的很大部分做全面掃描。不過，在一個OLTP環 境中，本來就不是對大對象全面掃描（如果真是如此，則說明肯定存在嚴重的設計缺陷）。即使對索引進行了分區，就算是真的能在速度上有所提高，通過掃描較小 索引所得到的性能提升也是微乎其微的。如果某些查詢使用了一個索引，而且它們根本無法消除任何分區，你可能會發現，完成分區之后查詢實際上運行得反而更慢 了，因為你現在要掃描5、10或20個更小的索引，而不是一個較大的索引。稍后討論各種可用的分區索引時還會更詳細地討論這個內容。盡管如此，有分區的OLTP系統確實也有可能得到效率提示。例如，可以用分區來減少競爭，從而提高并發度。可以利用分區將一個表的修改分布到多個物理分區上。并不是只有一個表段和一個索引段，而是可以有10個表分區和20個索引分區。這就像有20個表而不是1個表，相應地，修改期間就能減少對這個共享資源的競爭。事實上在一個OLTP系統中，查詢已經有以下特點：即索引訪問相當快，因此，分區不會讓索引訪問的速度有太大的提高（甚至根本沒有任何提高）。這并不是說要絕對避免在OLTP系統中使用分區；而只是說不要指望通過分區來提供大幅的性能提升。盡管有效情況下分區能夠改善查詢的性能，但是這些情況在大多數OLTP應用中并不成立。不過在OLTP系統中，你還是可以得到另外兩個可能的好處：減輕管理負擔以及有更高的可用性

　　上面這段話在實際項目中得到了驗證。項目中使用了Oracle RAC環境，在原先的AWR報表的Top Timed Event中，gc buffer busy高達70%，而DB CPU只有5%，buffer nowait只有93%，然后很快鎖定到TOP等待對象均為索引對象。當時另一個有趣的現象，單機的響應時間只有RAC的40%。

　　解決上面問題的方法有：

• 去除不必要的索引
• 全局索引分區，并把分區分散到多個表空間中，每個表空間又有多個數據文件
• 自增長序列索引改為反向索引

　　這么做以后，效果顯著，Top Timed Event中，gc buffer busy已經看不到了，其他集群等待時間的總和也不超過總時間的10%，DB CPU已經超過了50%，提交SQL的執行時間提高了10倍，buffer nowait也提高到了99.99%。再通過autotrace觀察查詢性能，發現對于查詢單值的情況，響應時間幾乎沒有變化，而且也不必在查詢時指定分區。

轉載于:https://www.cnblogs.com/todsong/archive/2012/10/10/2719098.html

總結

以上是生活随笔為你收集整理的OLTP系统的Oracle RAC性能调优，索引分区极大提升提交性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。