可变大小区（Variable-Size Extents）
6.8? 可變大小區（Variable-Size Extents）（4）
也就是該磁盤組有8塊磁盤，A、B、C表示不同的Stripe Chunk，每個chunk為128K大小。某ASM file的第一個chunk分配在disk1的第1個ASM file extent中，第2個chunk分配在disk2的第一個extent中，按此規律，一直分配到第8個chunk在disk8的第一個extent中，接下來第9個chunk（也就是上圖中的I）又分配在disk1的第一個extent中，依次分配，直到該ASM file被完全條帶化。
至于條帶分配的寬度（如上例中是8），則由隱含參數_asm_stripewidth來決定，該參數默認值為8，通常我們不會修改該參數值。
由前面所講述的背景知識我們知道，oracle在database instance的shared pool里存儲extent map block，且extent map block和extent是一一對應的關系（在默認AU大小的情況下，一個extent的大小就是1M），如果我現在庫的大小是1T，則我們可以計算出現在share pool里需要維護100萬個extent map block。
Oracle意識到如果用ASM管理一個1T的庫就需要維護100萬個extent map block話，那隨著所管理的庫的容量越來越大，效率問題不容忽視。
MOS文檔365468.1中這樣寫到：ASM metadata storage requirements for databases greater than 10TB can be very high introducing inefficiencies in opening ASM files and increasing memory used for ASM metadata。
于是在11g中，Oracle改變了extent的大小，extent的大小將不再永遠是1MB，而是會隨著分配extent數量的遞增而改變。在Oracle Database 11gR1中的具體規則如表6-1所示。
表6-1?Oracle 11gR1中的規則
| 區??編??號 | AU數量 | 區大小（au=1MB） |
| 0～19 999 | 1 | 1MB |
| 20 000~39 999 | 8 | 8MB |
| > 40 000 | 64 | 64MB |
其示意圖如圖6-27所示（引自Oracle Database Storage Administrator's Guide 11g），可以看到自第20000個Extent開始，分配了8個AU單位。
| ? |
| 圖6-27? Oracle Database 11gR1中的規則示意圖 |
我們可以稍微計算一下在Oracle 11gR1中相應的extent分配的情況。
AU=1MB，庫的大小為1TB，則按照上述算法，oracle現在僅需分配53572個extent
AU=64MB（在Oracle 11g中在創建disk group時可以手工指定AU的大小），庫的大小為1TB時，則按照上述算法，oracle現在僅需分配16384個extent：
AU=64MB（在Oracle 11g中在創建disk group時可以手工指定AU的大小），庫的大小為100TB，則按照上述算法，oracle現在僅需分配62788個extent：
在Oracle 11gR2中，規則又有所變化，具體如表6-2所示。
表6-2?Oracle 11gR2中的規則變化
| 區??編??號 | AU數量 | 區大小（au?=?1MB） |
| 0～19 999 | 1 | 1MB |
| 20 000～39 999 | 4 | 4MB |
| ＞?40 000 | 16 | 16MB |
使用1MB的AU和固定大小區，對于10TB的數據庫，大約需要90M來存儲Extent Map；而對于16MB的AU，Extent Map僅占用大約5.5MB內存。Oracle在11g里引入了"可變的區大小"技術，可以顯著縮短數據庫的啟動時間、降低Shared Pool的內存消耗，并且一舉解決了以前在10g里用ASM來管理海量數據時候的效率問題（因為extent map block的數量再也不會像以前那樣動輒上百萬了）。
總結
以上是生活随笔為你收集整理的可变大小区（Variable-Size Extents）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ORACLE:Health Monito
- 下一篇： 用户资源管理DBMS_RESOURCE_