174
運維經驗：回滾段異常的特殊救急方法
跟著恩墨一起讀好書運動開始啦！咱們作為DBA不僅要外部打扮自己，更要從內部武裝。近期，小編將分享冷菠老師的《Oracle高性能自動化運維》一部分精選章節分享給大家。如果你對內容很感興趣，還是要去買一本比較好哦。
購買：https://item.jd.com/12128635.html
冷菠
冷菠，資深DBA，著有《Oracle高性能自動化運維》，有近10年的數據庫運維、團隊管理以及培訓經驗。擅長數據庫備份恢複、數據庫性能診斷優化以及數據庫自動化運維等。目前致力於大數據、智能一體化、開源雲計算等領域的佳實踐探索。
當Oracle回滾段異常時，將會影響CR重構、事務鎖定、塊清除等與回滾段緊密相關的數據庫功能，甚至可能會導致數據庫無法正常啟動。
因此，在回滾段出現異常後，需要對回滾段進行（特殊）恢複，遵循以下原則：
1、介質恢複（Media Recovery）是首要的恢複方式，能保證數據恢複的一致性和完整性；
2、當介質恢複不能解決問題時，可以考慮使用隱藏參數來進行特殊恢複；
3、特殊恢複作為最後的恢複手段，需要對特殊恢複帶來的風險、特殊恢複時間以及恢複失敗回退機製等要點進行綜合評估，盡可能減少數據的丟失。
NOTE
隱藏參數比較危險，需慎重使用。
Oracle回滾段特殊恢複相關的隱藏參數主要有：
參數_offline_rollback_segments，如下所示：
參數_corrupted_rollback_segments，如下所示：
其中：
1、隱藏參數_offline_rollback_segments在init.ora初始化參數文件中的格式如下：
*._offline_rollback_segments=(r01,r02,r03)
回滾段r01、r02及r03為需要離線（offline）的回滾段。
2、隱藏參數_corrupted_rollback_segments在init.ora初始化參數文件中的格式如下：
*.rollback_segments=(r01,r02,r03)
*._corrupted_rollback_segments=(r04)
回滾段r01、r02及r03為需要在線使用（onffline）的回滾段，r4為強製異常的回滾段。
Oracle 回滾段隱藏參數用於回滾段異常導致數據庫無法正常工作的特殊恢複場景，主要包括：數據庫打開、一致讀和塊清除、回滾段刪除。
一、回滾段隱藏參數與數據庫打開
在數據庫打開的過程中，處於_offline_rollback_segments/_corrupted_rollback_segments參數列表中的回滾段有以下特點：
1、數據庫不會檢查回滾段頭事務表信息，同時，回滾段頭的活躍事務也不會被標記為“DEAD”或者“已回滾”狀態；
2、回滾段處於離線（Offline）狀態；
3、回滾段不能分配給新事務使用。
二、回滾段隱藏參數與一致性讀和塊清除
對於一致性讀與塊清除而言，隱藏參數_offline_rollback_segments與_corrupted_rollback_segments在特殊恢複中的作用是不同的。
隱藏參數_offline_rollback_segments：當事務槽處於開啟狀態（ITL Open）的Block與_offline_rollback_segments參數列表上的回滾段相關時，數據庫在重新打開過程中需要檢查_offline_rollback_segments列表上的回滾段頭事務表信息，獲取事務的狀態：
1、事務提交（Inactive），塊清除；
2、事務未提交（Active），其他Session讀取該Block時，則需要應用Undo Record來重構CR Copy。
NOTE
盡管offline_rollback_segments列表上的回滾段被Offline，Oracle仍然會讀取這些回滾段來檢查事務狀態，在回滾段Online後應用Undo Record實現回滾。如果offline_rollback_segments列表中存在與事務相關的回滾段壞塊，那麼Oracle回滾操作就會失敗
隱藏參數_corrupted_rollback_segments：當事務槽處於開啟狀態（ITL Open）的Block與_corrupted_rollback_segments參數列表上的回滾段相關時，數據庫在重新打開過程中不會讀取_corrupted_rollback_segments列表上的回滾段事務表信息，這樣就可以利用這個特性越過係統對回滾段的檢查來嚐試啟動數據庫。
1、如果活躍事務沒有提交，將會出現邏輯異常錯誤，可以使用參數_corrupted_rollback_segments來越過係統檢查，嚐試啟動數據庫；
2、當_corrupted_rollback_segments列表中的回滾段被刪除後，係統會將“DEAD”狀態的事務當作已經被提交，進行延遲塊清除。
NOTE
隱藏參數_offline_rollback_segments與_corrupted_rollback_segments的最大區別是：
1、_offline_rollback_segments列表中的回滾段頭事務表在數據庫打開過程中需要被讀取；
2、_corrupted_rollback_segments列表中的回滾段事務表在數據庫打開過程中不需要被讀取，Oracle會將_corrupted_rollback_segments列表中的回滾段當作已經“Drop”處理。這樣的好處就是可以在回滾段異常時，將異常回滾段添加到_corrupted_rollback_segments參數列表中，越過係統檢查，從而打開數據庫。
如果在ITL被清除前，標記為“corrupted”狀態的回滾段被Oracle重用（從_corrupted_rollback_segmens參數列表中移除），這時就需要回滾之前已經提交事務，導致Block邏輯異常。為了避免這些問題，因此建議在使用隱藏參數_corrupted_rollback_segments後，將參數列表中的回滾段刪除。
三、回滾段隱藏參數與回滾段刪除
在一般情況下，Oracle 回滾段是不能被刪除（Drop）的，這是因為回滾段中包含了活動事務（Active）信息，保存了事務恢複的回滾記錄。為了保護數據的一致性，Oracle不允許刪除有活動事務的回滾段。
在特殊情況下，將存在活動事務的回滾段添加到_corrupted_rollback_segments列表中，就可以忽略回滾段保護機製。也就是說，在數據庫啟動過程中，處於_corrupted_rollback_segments列表中包含有活動事務的回滾段可以被刪除。方法就是將該回滾段添加到_corrupted_rollback_segments列表中。刪除活動事務回滾段示例如下：
NOTE
在使用_corrupted_rollback_segments參數後，數據庫運行可能比較正常，但是出現問題的潛在風險將增大；刪除_corrupted_rollback_segments列表中包含有活動事務的回滾段時，存在邏輯錯誤的風險以及數據字典異常的風險，這可能將是一種災難，因此需要慎用該參數；建議在大多數情況下保持數據庫的正常啟動，盡可能少地使用隱藏參數，規避風險。
當存在活動事務的回滾段表空間出現異常時，可以通過以下步驟進行特殊恢複。
1、創建新的init.ora初始化參數文件（pfile），語法格式如下：
create pfile=<path> from spfile;
2、修改新init.ora初始化參數文件，將異常回滾段表空間的回滾段添加_corrupted_rollback_segments參數列表中，如下所示：
NOTE
一般情況下，隻需要將異常回滾段添加到_corrupted_rollback_segments列表中即可，如果回滾段表空間中所有回滾段都異常，則需要將所有異常的回滾段都添加到_corrupted_rollback_segments列表中。
3、使用修改後的init.ora初始化參數文件啟動數據庫：
startup restrict pfile='<pfile_path>';
NOTE
在數據庫啟動過程中，可以根據需要使用open resetlogs的方式打開數據庫（隻有部分數據丟失）。
4、在啟動成功的數據中創建新的回滾段表空間，語法如下：
create undo tablespace undotbs2 datafile '<path>' size 16384mautoextend retention noguarantee;
5、刪除異常的回滾段表空間，使用以下命令：
alter tablespace undotbs1 offline immediate;
drop tablespace undotbs1 including contents and datafiles;
NOTE
當刪除異常的回滾段表空間完成後，_corrupted_rollback_segment列表中隻有與活動事務相關的回滾段存在部分數據丟失。這樣就保證了數據庫正常啟動的同時，也盡可能地減少了數據的丟失。
6、使用以下命令，關閉數據庫：
shutdown immediate；
7、修改init.ora初始化參數文件，重新配置新的回滾段表空間，如下所示：
8、正常啟動數據庫，並重建spfile：
startup;
create spfile from pfile=<path>;
至此，基於隱藏參數的回滾段特殊恢複就告一段落。
原文發布時間為：2017-09-13
本文作者： 冷菠
本文來自雲棲社區合作夥伴“數據和雲”，了解相關信息可以關注“數據和雲”微信公眾號
最後更新：2017-09-14 16:03:02