[轉載]《Oracle 9i&10g 程式設計藝術》——分割槽表

13.1 分割槽概述
“分而治之”的思想體現。

分割槽的好處：
1.提高資料的可用性：這點是可以肯定的，要出現問題僅僅可以侷限在某個或某幾個分割槽上，不會影響其他的分割槽資料
2.由於從中取出了大段，相應地減輕了的負擔：（個人認為也得從兩方面來將，因為分割槽本身的維護也需要成本）
3.改善某些查詢的效能：大型資料倉儲上使用，在OLTP上不適用，因為OLTP本身就是訪問比較少的資料量
4.可以把修改分佈到多個單獨的分割槽上，從而減少大容量OLTP系統上的競爭：只有出現大的競爭的時候才會有效

13.1.1 提高可用性
可用性的提高來源於每個分割槽的獨立性。

最佳化器可以感知到分割槽的存在。

使用雜湊分割槽，我們可以讓Oracle隨機地（很可能是均勻地）將資料分佈到多個分割槽上。
我們無法控制資料會分佈到哪個分割槽，需要根據生成的雜湊鍵值來確定

可用性的兩個方面：
1.最佳化器能夠消除分割槽，這意味著許多使用者可能甚至從未注意到某些資料是不可用的。
2.出現錯誤時的停機時間會減少，因為恢復所需要的工作量會大幅的減少。

13.1.2 減少管理負擔
原理：在小物件上執行同樣的維護操作從本質上將更為容易、速度更快，而且恢復所需要的資源也更少。

對線上重定義超大的索引（）帶來的好處是巨大的！！！
所需要的維護空間更小，效率更高。
線上索引重建期間發生的事務修改會更少。

如果在重建過程中出現了問題，分割槽後重做的內容也會大大的減少。 Good。

也許任務僅僅是：重建最新加入的那個分割槽的索引。分割槽有意義。

很有可能因為臨時表空間太小無法完成超大表的move維護操作。
因為在move過程中，需要同時保留一份原表的一個副本。即在很短的時間內需要大約兩倍的儲存空間。

簡單的說：利用分割槽，原先讓人畏懼的操作，有時甚至是不可行的操作，會變得像在小資料庫中完成的一樣。

13.1.3 改善語句效能

1.OLTP系統
在OLTP系統中使用分割槽，大多情況下不能提高資料訪問的效能。不過某些情況下可以減輕管理的負擔以及會有更高的可用性。
因為OLTP中都是操作非常小的資料集合，而且在OLTP系統中不會存在對大物件全面掃描的情況發生————如果存在，說明程式設計需要改進。

在OLTP系統中唯一的一種可以提高效率的情況：利用分割槽來減少競爭，從而提高併發度。
原理：可以利用分割槽將一個表的修改分佈到多個物理分割槽上。並不是只有一個表段和一個索引段。

在一個OLTP系統最好不要出現並行查詢！

2.資料倉儲系統
資料倉儲和決策支援系統中，分割槽是非常強大的管理工具，可以加快處理的速度。

對即席查詢的輔助支援。如：對要查詢的欄位進行分割槽，可以提速。

資料倉儲中會頻繁的使用到並行查詢，並行索引掃描或並行快速全面索引掃描等在此顯得非常重要。

OLAP和DSS系統中，分割槽就意味著很可能會加快處理速度。

13.2 表分割槽機制
4種分割槽方法：
1.區間分割槽
2.雜湊分割槽
3.列表分割槽
4.組合分割槽

13.2.1 區間分割槽
“對映”概念。

13.2.2 雜湊分割槽
Oracle建議雜湊分割槽的個數是2的冪（2、4、8、16），有助於得到最佳的總體分佈。這一點非常的重要！！！
Tom的實驗很清晰的展示了這個過程。Good.

1.雜湊分割槽如何工作。

2.雜湊分割槽數使用2的冪

13.2.3 列表分割槽
9iR1的新特性。

ORA-14323: cannot add when DEFAULT partition exists

13.2.4 組合分割槽
組合分割槽中，頂層分割槽機制總是區間分割槽（注：11g中不是這樣了，提供了更多的排列組合方式，得到了非常大的擴充套件，Oracle很重視分割槽技術）

分割槽成為一個邏輯容器，或者是一個指向實際子分割槽的容器。

13.2.5 行移動
為防止資料操作過程中的報錯，需要啟用行移動特性。
alter table range_example enable row movement;

行移動的開銷比正常的update昂貴得多。所以，如果構建的系統會頻繁修改分割槽鍵，而且這種修改會導致分割槽移動，這種設計方法是要堅決抵制的。

13.2.6 表分割槽機制小結
區間分割槽是最常用的分割槽形式。

如果不能按自然的區間進行分割槽，可以使用雜湊分割槽。目的是為了提供管理、效能和可用性提升等諸多好處的情況下使用。在where條件中使用完全相等或in子句時，雜湊分割槽可以利用分割槽消除，但是，如果使用區間時，雜湊分割槽無法利用分割槽消除。

如果資料中的一列有一組離散值，而且根據應用使用這一列的方式來看，按這一列分割槽很有意義（例如可以輕鬆地利用分割槽消除）。適合使用列表分割槽。例如，許多“”型屬性都很適合應用列表分割槽。（這次專案中評估後，我打算採用這中分割槽技術來實現）

如果某些資料邏輯上可以進行區間分割槽，但是得到的區間分割槽還是很大，不能有效地管理，就可以使用組合分割槽。

總體建議：如果按某個屬性自然地對資料完成區間分割槽，就應該使用區間分割槽，而不是雜湊分割槽和列表分割槽。
因為後者在分割槽消除方面都不如區間分割槽好用。

13.3 索引分割槽
1.隨表對索引完成相應的分割槽————區域性分割槽索引(locally partitioned index)，每個表都有一個索引分割槽，而且只索引該表分割槽。
2.按區間對索引分割槽————全域性分割槽索引(globally partitioned index)，在此，索引按區間或雜湊分割槽，一個索引分割槽可能指向任何表分割槽。

對於全域性分割槽索引，要注意，實際上，索引分割槽數可能不同於表分割槽數。

全域性索引只能按區間或雜湊分割槽，索引如果希望有一個列表或組合分割槽索引，就必須使用區域性索引。區域性索引會使用與底層相同的機制完成分割槽。

全域性索引的雜湊分割槽是在10gR1才有的功能。

13.3.1 區域性索引與全域性索引

經驗如下：
資料倉儲   ----採用區域性索引
OLTP     ----採用全域性索引
這取決於是否需要在索引結構上執行分割槽消除來維護分割槽後與分割槽前有同樣的查詢響應時間。

區域性索引有其自己的特有的性質：支援一個更可用的環境，停機時間更少，因為問題會被隔離到一個區間或資料雜湊上。

然而全域性索引可以指向多個表分割槽，因此可能會成為一個故障點，對於某些查詢來說，一旦全域性索引出故障，則所有分割槽都不可訪問。

從維護角度看，區域性索引更為靈活。移動一個表分割槽，只需要重建和維護相關的區域性索引分割槽。
注意全域性索引的重建問題的嚴重性。

Oracle可以利用索引隨表進行區域性分割槽這一事實，開發最優的查詢計劃。而對於全域性索引，索引和表分割槽之間就沒有這種關係。

區域性索引還有利於分割槽時間點恢復操作。

全域性索引也很重要的，但是在使用之前要評估一下它會帶來的影響。

13.3.2 區域性索引
兩類區域性索引
1.區域性字首索引local prefixed index：分割槽鍵在索引的前幾列上
2.區域性非字首索引local nonprefixed index：這些索引不以分割槽鍵作為其列表的前幾列，索引可能包含分割槽鍵，也可能不包含分割槽鍵

如果查詢中將索引用作訪問表的初始路徑，那麼從本質來講，區域性字首索引並不比區域性非字首索引更好。如果查詢把"掃描一個索引"作為第一步，那麼字首索引和非字首索引之間並沒有太大的差別。

1.分割槽消除行為
重點是：要儘可能保證查詢包含的謂詞允許索引分割槽消除。
使用字首區域性索引可以保證這一點，使用非字首索引則不能保證。

還要考慮如何使用索引，如果將索引引用作查詢計劃中的第一步，那麼這兩種型別的索引沒有多少差別。

2.區域性索引和唯一約束
如果想使用一個區域性索引來保證這個約束，那麼分割槽鍵必須包括在約束本身中。Tom認為這是區域性索引的最大限制。

Oracle只保證索引分割槽內部的唯一性，而不能跨分割槽。
意味著：不能一方面在一個timestamp欄位上執行區間分割槽，而另一方面在ID上有一個主鍵。Oracle會利用全域性索引來保證唯一性。

對分割槽表中的某個分割槽做truncate或者move，shrink等，可能會影響到n個全域性索引分割槽，正因為這一點，區域性分割槽索引具有更高的可用性。

13.3.3 全域性索引

全域性索引只有一類，就是：字首全域性索引。

全域性索引的一個需求：最高分割槽必須有一個值為MAXVALUE的分割槽上界。確保底層表中的所有行都能放在這個索引中。

應用全域性索引的場景：
1.資料倉儲和全域性索引
原先的資料倉儲系統中很抵制使用全域性索引。

資料倉儲意味著：大量資料的錄入、大量資料的刪除
滑動視窗（sliding window）來完成上面的工作：刪除表中最舊的分割槽，併為新載入的資料增加一個新分割槽。

8i及以前版本資料倉儲系統都會避免使用全域性索引，原因是：全域性索引缺乏可用性。大多數分割槽操作都會使全域性索引無效，除非重建全域性索引，否則無法使用，這會嚴重地影響可用性。

新的方法：資料滑動視窗（sliding window of ）
如何繞過全域性索引的影響。
（1）滑動視窗和索引
滑動視窗過程如下：
1.去除老資料：刪除資料，或與一個空表交換
2.載入新資料並建立索引：在一個“工作表”中載入新資料
3.關聯新資料：“工作表”中的資料與分割槽表的一個空分割槽交換

透過簡單的資料字典更新實現的滑動過程，速度超快。

這種方法好處：能非常快的完成任務
缺點：索引會失效，在重新建立索引過程中，對應用有很大的衝擊，而且重新建立全域性索引的時間會非常的長，而且會使用非常多的資源。

（2）“活動”全域性索引維護
在9i版本之後，可以使用update global indexes子句來維護全域性索引。
這個特性對於需要提供資料連續訪問的系統來說是必行之舉！

原理：犧牲分割槽操作的速度，換取100%的資料可用性。
如果系統不允許有停機時間，那麼只能使用這個技術來保障。

需要權衡的地方：在整個過程中，因為要維護全域性索引，所以會帶來大量的開銷（insert、delete）。
注意對redo和undo產生的評估，可能的話需要提前進行調整。

2.OLTP和全域性索引
OLTP特點：頻繁地出現許多小的讀寫事務。首要要求是：快速的獲得所需行的資料。
具體特點總結羅列如下：
1）快速訪問，速度至上，快速得到所需的資料行
2）資料完整性要求高
3）可用性要求高
4）OLTP不適合並行查詢
5）必須使用到索引分割槽消除
6）需要適當的提供索引，以便利用某些欄位上的全域性索引

13.4 再論分割槽和效能
資料倉儲中使用分割槽利多害少！
OLTP系統中使用分割槽害多利少！因為OLTP型別的系統獲取的資料量很少。

OLTP使用分割槽僅有的一些好處：
1.高度併發環境中資料修改有利，分割槽可以提供顯著的好處。
2.大數量的可管理性。
3.大數量的可用性。
4.需要在語句中使用分割槽鍵，顯示的指定去哪個分割槽找資料，可以提高效能。

必須使用order by語句來保證資料的有序性。
group by也不會執行排序！ order by是無可替代的！

13.5 審計和段空間壓縮
大環境對資料庫的審計需求越來越重。

實現審計資料的儲存需求時往往會使用到分割槽技術。

審計跟蹤信表空間建議：
1.一個當前線上的讀寫表空間：不會被壓縮，只向其中插入資訊。
2.一個只讀表空間：包含“當前這一年”的審計跟蹤資訊分割槽，採用壓縮格式。每個月的月初，置這個表空間為可讀寫，向這個表空間中移入上個月的審計資訊，並進行壓縮，再使之成為只讀表空間，並完成。
3.用於去年、前年等的一系列表空間。都是隻讀的。

採用這種方式可以很容易的實現“淨化”（刪除一個分割槽）的目的。

13.6 小結
分割槽是擴充套件資料庫中大物件的有效途徑。大物件可以被分成更小、更可管理的部分。

效能擴充套件   ---- 系統的終端使用者關心這一點。
可用性擴充套件  ---- 系統所有者關心這點，因為停機時間就意味著金錢損失。
管理擴充套件   ---- 維護DBA重視這一點。

OLTP中使用分割槽技術不太合適。

分割槽可能會提高某些型別查詢的效能，但是這些常用的OLAP/DSS查詢型別通常不會在OLTP系統中使用。

不能想當然的把分割槽和“效能提升”聯絡到一起。

法律方面的原因，審計需求可能很重，所以不可迴避的需要用到分割槽技術。

http://space.itpub.net/519536/viewspace-613449