分區系列篇：
關於oracle分區技術--初瞭解 http://blog.csdn.net/wanghui5767260/article/details/39158873
關於分區技術的索引： http://blog.csdn.net/wanghui5767260/article/details/39181027
關於分區技術---索引 Index
一、 分區索引分類：
本地前綴分區索引(local prefixedpartitioned index)
全局分區索引(global partitionedindex)
本地非前綴分區索引(localnon-prefixed partitioned index)
1.1 表和索引的組合：
第一種:表和索引都不分區
最簡單的方式 就是常見的索引
第二種：表分區了，但索引沒分區
這導致了：“我們已經做了分區表了，怎麼性能沒有提高?”的主要原因之一。
在很多系統中，特別是交易系統裏面，是通過索引訪問數據庫的。如果索引沒有分區，索引樹的高度沒有變，因此訪問性能當然沒有提高。如果按索引訪問表，與表是否分區關係不大。
第三種：表沒有分區，但索引分區了
索引只能是全局分區索引。
第四種：表分區了，索引也分區了(重點！！！)
全局分區索引
本地前綴分區索引
二、 具體介紹分區索引
本地分區索引
是指索引的分區方法與對應表的分區方法一樣。
2.1本地前綴分區索引（local prefixed partitioned index）
是指分區字段是索引字段的前綴。
一張交易流水錶(TXN_CURRENT)，並且以交易日期字段(TXN_DATE)按年度進行了範圍分區。在TXN_DATE 字段創建索引。
Createindex idx_txn_current_1 on txn_current(txn_date) local;
或者複合分區索引
Createindex idx_txn_current_2 on txn_current(txn_date,area) local;
好處：
a. 由於分區索引和表分區對應，因此查詢數據直接到對應的索引分區去查詢，索引樹的高度肯定低於非分區情況下的那棵大索引樹了，也就是說性能更高了。
b. 當某個分區進行刪除（DROP）或合併（MERGE）操作之後，oracle自動對所對應的索引分區進行相同的操作，整個本地前綴索引依然有效，不需要重建(rebuild)操作，這樣大大保障了表的可用性。
2.2 全局分區索引(global partitioned index)
索引的分區與表分區無關
分區表按年份進行分區，在地區(AREA)字段上建立分區索引，
也就是說：杭州交易數據肯定可分佈在各年份，湖州、嘉興交易數據同樣如此。
假如有這樣的查詢需求：
Select* from TXN_CURRENT where area=’05711001’;
--假設查詢杭州西湖區
好處：
a. 此時oracle會很聰明地知道杭州的分區索引樹上去檢索，索引高度肯定低於非分區情況下的大索引樹了，也就是性能更高了。
b. 在分區粒度比較細的情況下，性能甚至高於本地前綴分區索引。
不足：
a. 主要體現在高可用方面。如果該表的03年數據通過分區刪除全部刪除了。則全局分區索引(包括普通非分區索引)則全部失效(INVALID)，這些索引不可用了，除非重建(rebuild)操作。數據量越大，索引量也越大，重建索引時間也越長，無法通過該類索引訪問數據的時間也越長。因此，大大降低數據的可訪問性。
2.3 本地非前綴分區索引
可能導致性能會下降的情況，本地非前綴分區索引的性能可能還不如不分區。
優點：
a. 提高按索引訪問的可用性！我們假設要通過刪除分區技術，進行03年數據的清理，如果area字段索引建立成普通索引，或者是全局分區索引，都會面臨一個問題：在分區刪除(DROP)操作之後，普通索引和全局分區索引都會失效(INVALID)，必須重建。而本地非前綴分區索引的好處在於，在分區刪除操作後，該本地非前綴分區索引依然有效。
三、 整理思路
理解分區索引藏寶圖：
描述藏寶圖：找寶藏
(1)如果表分區字段正好是索引字段或者是其前綴。例如：上述TXN_CURRENT 表分區字段是TXN_DATE，則TXN_DATE正好是索引字段（TXN_DATE），或者正好是索引字段（TXN_DATE,AREA）的前綴，則此時應建立local profixedpartitioned index.
(2)否則，如果欲將非分區字段建立爲唯一索引，例如：假設在TXN_CURRENT 表的某個字段建立唯一索引，oracle要求必須global prefixed index.
否則報錯：
ORA-14039:partitioning columns must form a subset of key columns of a UNIQUE index
(3)流程圖再往下，此時要判斷“是否性能在可承受範圍，而分區的管理性、可用性更重要?”。如果是，就應建立local non-profixed index。也就是上面所描述的：如果歷史數據的整理非常頻繁，而且不能承受全局分區索引重建的長時間帶來的索引不可用，同時日常交易性能尚能接受，則建議設計爲本地非前綴分區索引。
(4)流程圖再往下，最後判斷系統是否爲交易系統或者是數據倉庫系統。因爲通常情況下，數據倉庫會有頻繁的大批量數據導入（ETL）操作，以及歷史數據清理操作，此時分區索引可用性更重要，因此建議設計爲Localnon-profixed index 。而在交易系統中，日常查詢性能要求更高，歷史數據清理操作頻度相對較低，因此建議設計爲global profixed index。
注：oracle沒有global non-profixed index概念。
四、 分區表設計建議 只是建議：更多看實際！！！
(1) 表的大小：當表的大小超過1.5G—2GB時，或對於OLTP系統，表的記錄超過1000萬條時，都應考慮對錶進行分區。
(2) 數據訪問特徵：基於表的大部分查詢應用，只訪問表中的少量數據。對於這樣的表進行分區，可充分利用分區技術排除無關數據查詢的特徵。
(3) 數據維護：按時間段刪除成批的數據，例如按月刪除歷史數據。對於這樣的表需要考慮進行分區，以滿足維護的需求。
(4) 數據備份和恢復：按時間週期進行表空間的備份時，在分區與表空間之間建立起對應關係。
(5) 只讀數據：如果一個表中的大部分數據都是隻讀數據，通過對錶進行分區，可將只讀數據存儲在只讀表空間中，對於數據庫的備是非常有益的。
(6) 並行數據操作：對於經常執行並行操作（如parallelinsert、parallel update等）的表應考慮進行分區。
(7) 表的可用性：當對錶中部分數據的可用性要求很高時，應考慮進行表分區。
2014/9/10 tyger
本文整理自：羅敏《品悟性能優化》