復原段的常見錯誤及解決方案

(1).復原段空間不夠
ORA-01562 - failed to extend rollback segment number string
復原段空間不夠的原因一般有以下幾種情況:
A. 復原段所在資料表空間剩餘的空閑空間太小, 無法分配下一個EXTENT.
B. 復原段擴充次數已經達到MAXEXTENTS限制

解決方案:
A. 擴大復原段所在資料表空間
B. 設定較大的MAXEXTENTS參數
C. 為復原段設定OPTIMAL參數
D. 用較大的EXTENT參數重新建立復原段
C. 將導致ORA-1562錯誤的DML語句改為分段執行:
例如: 語句為：
DELETE FROM CHENFENG WHERE condition;
可用如下語句代替:
BEGIN
LOOP
DELETE FROM CHENFENG
WHERE condition
AND ROWNUM<10000;
EXIT WHEN SQL%NOTFOUND;
COMMIT;
END LOOP;
END;

(2). ORA-01552 cannot use system rollback segment for non-system tablespace 'string'
原因: 沒有可用的非系統復原段. 分為以下情形:
A. 除了系統復原段, 未建立其它復原段
B. 只建立了PRIVATE復原段, 但INITsid.ORA的ROLLBACK_SEGMENTS中未列出這些復原段
C. 建立了PUBLIC復原段, 但這些復原段都處於OFFLINE狀態
解決方案: 根據以上原因相應解決即可

(3).ORA_01555 snapshot too old: rollback segment number string with name "string" too small
原因可分為以下情形：
A. 復原段太少/太小
資料庫中有太多的事務修改資料並提交, 就會發生已提交事務曾使用的空間被重用, 從而造成一個延續時間長的查詢所請求的資料已經不在復原段中.
解決方案: 建立更多的復原段, 為復原段設定較大的EXTENT以及較大的MINEXTENTS

B. 復原段被破壞
由於復原段被破壞, 造成事務無法將修改前的內容(read-consistent snapshot) 放入復原段, 也會產生ORA-01555錯誤.
解決方案: 將被破壞的復原段OFFLINE, 刪除重建.

C. FETCH ACROSS COMMIT
當一個進程開啟一個CURSOR, 然後迴圈執行FETCH, UPDATE, COMMIT, 如果更新的表與FETCH的是同一個表, 就很可能發生ORA-01555錯誤.

解決方案:

a. 使用大的復原段

b. 減少提交頻率(可參見本論壇"如何避免一個PROCEDURE被重複調用"一貼中, 無名朋友的回帖)
以上兩種方法只能減少該錯誤發生的可能, 不能完全避免. 如果要完全避免, 須從執行方法著手, 可以用以下兩種方法:

c. 建立一個暫存資料表, 存放要更新的表的查詢列(如主鍵及相關的條件列), 從暫存資料表FETCH, 更新原來的表.

d. 捕獲ORA-01555錯誤, 關閉並重新開啟CURSOR, 繼續執行迴圈.

D. 其它原因:
* Delayed logging block cleanout是ORACLE用來提高寫效能的一種機制: 當修改操作(INSERT/UPDATE/DELETE)發生時, ORACLE將原有的內容寫入復原段, 更新每個資料區塊的頭部使其指向相應的復原段, 當該操作被COMMIT時, ORACLE並不再重新訪問一遍所有的資料區塊來確認所有的修改, 而只是更新位於復原段頭部的事務槽來指明該事務已被COMMIT, 這使得寫操作可以很快結束從而提高了效能接下來的任何訪問該操作所修改的資料的操作會使先前的寫操作真正生效, 從而訪問到新的值. Delayed logging block cleanout 雖然提高了效能, 但卻可能導致ORA-01555. 這種情況下, 在OPEN/FETCH前對該表做全表掃描(保證所有的修改被確認)會有所協助.

有兩種delayed cleanout的情況：

1. 因為相應的復原段資訊還沒有被重用，訪問這些沒有被cleanout的資料區塊的進程可以確定commit時的SCN.

2. 由於時間太久，不能獲得精確的SCN，這個資料區塊會被標記一個‘best guess' SCN或'upper bound commit' number.

如果進行cleanout的這個事務已耗用時間太久，Oracle無法根據復原段的資訊來獲得'upper bound commit' number(在該事務執行期間復原段被重用的次數太多)，就會發生著名的ORA-1555.

* 不適當的OPTIMAL參數: 太小的OPTIMAL參數會使復原段很快被SHRINK, 造成後續讀取操作訪問時, 先前的內容已丟失. 仔細設計OPTIMAL參數, 不要讓復原段過於頻繁的EXTEND/SHRINK有助於問題的解決.

* DB BLOCK BUFFER太小: 如果讀一致性所請求的塊的先前內容在緩衝區中, 那麼就不用去訪問復原段. 而如果緩衝區太小, 使得先前版本的內容在CACHE中的可能性變小, 從而必須頻繁的訪問復原段來擷取先前的內容, 這將大大增大ORA-01555發生的可能.

產生ORA-1555的可能情況：
(1).一個長時間啟動並執行查詢，並同時針對查詢需要的塊有DML處理
當一個長時間的查詢開始執行時，查詢所需要的一個資料區塊被修改並遞交了，這個塊是需要一致讀的，但因為該DML事務已遞交了，所以保留前映像的復原段SLOT可以被另外的事務使用，這個查詢事務耗時非常長，在這個時間段中，很可能該SLOT被另外的事務使用而把原值給覆蓋了，所以當查詢執行到該塊時，該塊的SNAPSHOT SCN時的值已經找不到了，報ORA-1555錯誤。
解決方案：
業務控制，禁止對同一個表的長時間查詢和更新處理同時進行，要分開執行
增加復原段的個數
增大復原段的大小，記住產生ORA-1555的錯誤可能是最小的復原段造成的，所以每個復原段的大小應該一致。
不使用OPTIMAL選項
延遲對DML語句的COMMIT
縮短查詢的時間，修改查詢語句，比如並行查詢
為要查詢的表建立唯讀SNAPSHOT，這樣對錶記錄的修改就不會影響到查詢，但該表不能是太大的表
(2).交叉遞交
通過一個遊標建立一個迴圈來迴圈讀取表的資料，但又在迴圈中對錶的進行修改並遞交。如果正好多次修改並遞交，將一個資料區塊在復原段的前映像給覆蓋了，當迴圈又要取該資料區塊的值時，報ORA-1555錯誤。這是個經常出ORA-1555錯誤的操作。
解決方案：
修改程式，避免這種情形出現
盡量在迴圈讀取中，不要做遞交處理
在查詢語句中，增加“ order by 1 ”的語句，這樣會在臨時段中保留ORDER BY的結果，而不在需要一致讀了。
(3).延遲塊清除
延遲塊清除是指當一個DML事務發生並遞交了，ORACLE在復原段做了一個快速COMMIT標記該事務已遞交了，但在DATA BUFFER中修改過的資料區塊並沒有標記，（ORACLE一次只清除DATA BUFFER10%的修改的資料區塊）這些未清除但已遞交的資料區塊要在下一次事務訪問才清除掉，這就是延遲塊清除。在這個過程中有可能出現ORA-1555的錯誤，但一般是非常難得的，因為出現這個錯誤需要滿足以下幾個條件：
①已做了修改並遞交，但又未做清除的資料區塊
②這些塊在被下一個要出錯的事務使用前，沒有被其他事務使用
③查詢期間，系統中又發生了大量的其他DML處理，這些DML處理不涉及到這些塊。
④因為這些大量的DML事務，產生了頻繁的遞交，造成事務表被多次WRAP，最初保留未清除事務的事務條目也被迴圈的使用，原來的UPDATE COMMIT SCN已經不存在了。
⑤復原段的最小SCN已經超過查詢SCN了
⑥當查詢執行到該塊的時候，發現該塊的UPDATE COMMIT SCN已經不存在了，而且現在復原段的最小SCN也比查詢SCN要大，UPPER BOUND SCN都無法估算了，所以無法確定查詢是否能使用這個塊，造成ORA-1555錯誤。
解決方案：
一般這種情況很難出現，可以不考慮，如果確實要解決，可以在DML操作後，做一次FULL TABLE SCAN來清除上次未清除的塊。
可以設定DELAYED_LOGGING_BLOCK_CLEANOUTS = true （預設）
(4).復原段有壞塊

總結，從上面說明中可以看出，防止ORA-1555問題出現，最根本的一點就是保證復原段中已COMMIT的事務資訊不被覆蓋了。9I中，ORACLE提供一個更加有效方法來保證這點，用參數UNDO_RETENTION來保證COMMIT的事務多長時間不被覆蓋。具體說明，可以參見ORACLE9I的自動復原段管理說明(SMU)。