UNDO資料表空間的估算

標籤：空間   undo   估算   

UNDO資料表空間和TEMP空間類似，都是迴圈使用的，其使用原理大致如下：

當我們使用AUM（自動UNDO管理），並設定了undo_retention以後，undo塊就存在四種狀態。

Active：表示正在使用該undo的事務還沒有提交或復原。

Inactive：表示該undo上沒有活動的事務，該狀態的undo可以被其他事務覆蓋。

Expired：表示該undo持續inactive的時間超過undo_retention所指定的時間。

Freed：表示該undo塊內容是空的，從來沒有被使用過。

當活動的事務使用undo segment時，在AUM模式下，事務可以在不同的undo segment之間動態交換undo空間，也就是在不同的undo segment裡交換extents。當一個正在執行的事務需要更多的undo空間時，首先會重用當前undo segment裡的可用空間；如果當前undo segment裡的可用空間（也就是extents）不足時，則會按照下面的步聚獲得所需要的extent：

擷取undo資料表空間裡可用的、空的extents；

擷取其他undo segment裡的expired狀態的extents；

如果undo資料表空間裡的資料檔案啟用了自動擴充（autoextend on），則資料檔案進行自動擴充；

如果undo資料表空間裡的資料檔案沒有啟用自動擴充，則擷取其他undo segment裡的INACTIVE狀態的extents；

如果以上步驟均無法獲得可用空間時，報空間不足的錯誤訊息。

這種動態方式使得空間的使用最為高效。我們來舉例說明，7-2所示。

650) this.width=650;" class="fit-image" height="163" src="http://new.51cto.com/files/uploadimg/20080603/144119722.jpg" width="286" border="0" style="border:medium none;" />

圖7-2  undo擷取可用空間的機制

在圖7-2中，假設undo資料表空間中總共存在5個undo segment（US1、US2、US3、US4和US5）。每個undo segment中包含7個extent，其中每個extent的狀態採用A、I、X和F來表示。那麼當使用US5的事務還需要額外的可用空間時，首先會使用US5中兩個狀態為F的extents；如果不夠用，則使用US4中的3個狀態為F的extents；如果還不夠用，則使用US3中的3個狀態為X的extents；如果仍然不夠用，則使用US1中的3個狀態為I的extents；如果再不夠用，則報空間不足的錯誤訊息。

對於UNDO空間多大合適，有一個計算方法：

每秒平均（或最大）產生的UNDO資料區塊的數量*塊尺寸*UNDO資料儲存的最短時間（或最長的SQL已耗用時間）

其中“每秒平均（或最大）產生的UNDO資料區塊的數量”可以通過v$undostat字典視圖來計算，計算方法如下：

每秒平均產生的UNDO資料區塊的數量：

SELECT (SUM(undoblks))/ SUM((end_time - begin_time) * 86400) FROM v$undostat;

每秒最大產生的UNDO資料區塊的數量：

SELECT max(undoblks / ((end_time - begin_time) * 24 * 3600)) FROM v$undostat;

其中“塊尺寸”可以通過系統參數db_block_size查詢得知（一般預設為8192）。

show parameter db_block_size

其中“UNDO資料儲存的最短時間”可以通過系統參數undo_retention查詢得知 (預設為900秒）

show parameter undo_retention

而“最長的SQL已耗用時間”可以通過以下方法確定：

SELECT max(SUM(elapsed_seconds)) FROM v$session_longops GROUP BY sid,serial#,sql_id

將以上得出的數字代入公式，就可以計算出UNDO所需空間的大小了。

例如，我們得出

每秒平均產生的UNDO資料區塊數量為100，每秒最大產生的UNDO資料區塊的數量為200;

塊尺寸為8192;

undo資料儲存的最短時間為900秒，最長的SQL已耗用時間為2400秒。

則以“每秒平均產生的UNDO資料區塊的數量*塊尺寸*UNDO資料儲存的最短時間”來計算，得出

100塊/秒*8192位元組/塊*900秒=737280000位元組，約等於703M。

若以“每秒最大產生的UNDO資料區塊的數量*塊尺寸*最長的SQL已耗用時間”來計算，得出

200塊/秒*8192位元組/塊*2400秒=3932160000位元組，約等於3750M。

因此，若將UNDO空間大小設定為703M，則可以基本保證在900秒前發生的改變，是可以查到的，或者說，在對於一個已耗用時間不超過900秒的SQL語句來說，是不太會遭遇“ORA-01555 快照過舊”這種錯誤的。

而若將UNDO空間大小設定為3750M，則可以基本保證在2400秒（範例系統中可以查到的SQL最長已耗用時間）前發生的改變，是可以查到的，或者說，在對於一個已耗用時間不超過2400秒的SQL語句來說，是不太會遭遇“ORA-01555 快照過舊”這種錯誤的。

參考：

http://book.51cto.com/art/200806/75648.htm

本文出自 “大臉貓” 部落格，請務必保留此出處http://bfc99.blog.51cto.com/265386/1431070