一、恢復解決方案

錯誤型別及解決方案

錯誤分類	恢復解決方案
介質失敗	如果是少量的塊損壞，使用塊介質恢復；如果是大量的塊、資料檔案、表空間的損壞，可能需要對損壞的資料檔案或者表空間執行完全恢復；如果是歸檔Redo日誌檔案或者聯機Redo日誌檔案的丟失，那麼只需要不完全恢復方式。
邏輯損壞	如果是程式設計師錯誤導致出現的問題，可透過補丁應用修復問題。對於無法修復的問題，也可採用介質恢復手段來恢復資料。
使用者錯誤	根據不同使用者錯誤，選擇不同的Flashback技術恢復，使用Flashback技術恢復使用者錯誤是首選方案。如果Flashback不能很好的恢復資料再考慮使用介質恢復或者表空間時間點恢復。

注意：恢復依賴於備份，當生產環境中部署完成就應該確保有一次資料庫的全庫備份，且確保歸檔Redo日誌被開啟。

二、SCN時間機制

SCN（System Change Number，系統改變號）是Oracle內容非常重要的時間機制，一致性、資料恢復都與SCN有著非常密切的關係。Oracle啟動時，也是透過SCN的驗證來確認資料庫是否需要執行例項恢復的。雖然RAC有多個例項，但是隻有一個資料庫，SCN是對應資料庫級別的改變號，所以在不同的例項產生的SCN都必須是唯一的、有序的，這是由SCN生成器完成的工作。系統時間和SCN之間可以非常容易的相互轉換，下面是系統時間和SCN相互轉換的例子：

SQL> select timestamp_to_scn(sysdate) from dual;

TIMESTAMP_TO_SCN(SYSDATE)

-------------------------

6980593

SQL> select scn_to_timestamp(6980593) from dual;

SCN_TO_ TIMESTAMP (6980593)

-------------------------

02-DES-13 11.12.21.000000000 PM

SQL>

以下為幾種常見的SCN：

? 檢查點SCN

查詢當前最近的檢查點SCN：

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

------------------

3.6555E+12

SQL>

每執行一次檢查點就由CKPT程式來更新，這個SCN儲存在控制檔案中。檢查點的執行能夠確保檢查點執行時刻資料的完整性和一致性。例項恢復也是從上一次檢查點開始進行恢復，檢查點執行的頻率決定了Crash恢復或者例項恢復需要花費的時間。當發生日誌切換或者請求的SGA空間不足等情況時就會觸發檢查點。發生檢查點，DBWn程式會將所有的髒資料寫回磁碟，從而能夠確保已提交的一致性資料被寫回磁碟。單個聯機Redo日誌檔案越大，發生檢查點的間隔時間可能越長，例項恢復的時間也相應地增長，日誌檔案的丟失也會導致更多的資料丟失。

? 最新SCN

執行以下SQL語句檢視資料庫最新的SCN：

SQL> select current_scn from v$database;

CURRENT_SCN

------------

3.6555E+12

SQL>

該SCN是最新生成的全域性SCN，它在不斷更新，並且只會增大不會減小。

? 資料檔案SCN

執行以下SQL檢視所有資料檔案的SCN：

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

------------------

3.6555E+12

6 rows selected.

SQL>

每個資料檔案都有一個資料檔案SCN，每執行一次檢查點便由CKPT程式來更新一次，該SCN儲存在控制檔案中。

? 啟動SCN

執行以下SQL語句查詢所有資料檔案的啟動SCN：

SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

------------------

3.6555E+12

6 rows selected.

SQL>

每個資料檔案都有一個啟動SCN，沒執行一次檢查點都由CKPT程式來更新一次，該SCN儲存在資料檔案頭中。

? 終止SCN

執行下面SQL語句查詢所有資料檔案的終止SCN：

SQL> select last_change# from v$datafile;

LAST_CHANGE#

------------

6 rows selected.

SQL>

每個資料檔案都有一個終止SCN，沒執行一次檢查點都由CKPT程式更新一次。該SCN儲存在控制檔案中，當資料庫開啟時，由於沒有終止SCN存在，所以看到的是空，表示無窮大。

資料庫啟動過程中，首先會檢查控制檔案和資料檔案的檢查點執行次數是否一致，如果不一致需要對資料檔案進行介質恢復。如果一致，進一步檢查資料檔案的啟動SCN和終止SCN是否相同。如果資料庫是非正常關閉，那麼終止SCN肯定是空，這個時候需要執行Crash恢復或例項恢復的過程。Crash恢復或例項恢復過程需要用到聯機Redo日誌和UNDO表空間執行前滾和回滾操作，如果聯機Redo日誌或者UNDO表空間被損壞，那麼資料庫可能無法正常開啟。如果啟動SCN和終止SCN相同，那麼資料庫就可以正常開啟。

? 日誌SCN

執行以下SQL語句查詢與日誌相關的SCN：

SQL> select status,first_time,first_change#,next_time,next_change# from v$log;

STATUS FIRST_TIME FIRST_CHANGE# NEXT_TIME NEXT_CHANGE#

-------------------- -------------- ------------- -------------- ------------

INACTIVE 02-12鏈13 3.6555E+12 02-12鏈13 3.6555E+12

CURRENT 02-12鏈13 3.6555E+12 2.8147E+14

INACTIVE 02-12鏈13 3.6555E+12 02-12鏈13 3.6555E+12

SQL>

在上面查詢中，first_time表示該日誌組開始的時間，first_change#表示該日誌組開始的SCN。可以看到，狀態為current的日誌組的first_change#值與前面討論到的檢查點的SCN值相同，說明發生日誌切換的時候會觸發檢查點生成一致的檢查點SCN。Next_time表述結束日誌組的時間，next_change#表示結束日誌組的SCN，該SCN值等於下一個日誌組的first_change#值。當前日誌組的next_time為空，next_change#是一個很大的值。

三、日誌執行緒與聯機Redo日誌

Redo日誌記錄了資料的所有操作，以及操作的順序。Redo日誌主要包括聯機Redo日誌、歸檔Redo日誌和Standby Redo日誌三種型別，這三種型別的日誌在結構上是完全相同的，只有用途不同而已。

Redo資料只有在資料庫恢復時才能體現出它的價值。在RAC環境中，每個例項的歸檔Redo日誌可以存放在本地檔案系統，但是恢復的時候需要將所有節點的歸檔Redo日誌放在一起，確保恢復的例項能夠訪問到所有例項的歸檔Redo日誌。

每個例項都對應一個維護日誌的日誌執行緒（Redo thread），單例項只有一個執行緒號為1的日誌執行緒。對於RAC來說，日誌執行緒與例項的關係可以透過以下SQL語句查詢得到。

1）查詢來自控制檔案的執行緒資訊：

SQL> select thread#,checkpoint_change#,last_redo_change# from gv$thread;

THREAD# CHECKPOINT_CHANGE# LAST_REDO_CHANGE#

---------- ------------------ -----------------

1 3.6555E+12 3.6555E+12

2 3.6555E+12 3.6555E+12

1 3.6555E+12 3.6555E+12

2 3.6555E+12 3.6555E+12

SQL>

2）查詢執行緒與例項之間的關係：

SQL> select thread#,instance_name from gv$instance;

THREAD# INSTANCE_NAME

---------- ------------------------------------------------

1 PROD1

2 PROD2

SQL>

3）查詢執行緒與日誌組之間的關係：

SQL> select group#,thread# from v$log;

GROUP# THREAD#

---------- ----------

1 1

2 1

3 2

4 2

SQL>

四、UNDO表空間

UNDO表空間存放的是資料塊的前映象，是塊的多版本資料，用於資料庫恢復、一致性讀和事務回滾，對資料庫併發下讀一致性起著重要的作用。

在RAC環境中，與連線Redo日誌一樣，每個例項都有自己的UNDO表空間，UNDO表空間必須放在共享儲存上，每個例項都能訪問到所有例項的UNDO表空間，以便任一活動例項都能執行所有例項的恢復操作。每個例項都有自己獨立的UNDO表空間還能減少例項間對UNDO表空間的爭用。

例項對應的Redo日誌組由Redo執行緒來指定，例項對應的UNDO表空間是直接透過初始化引數檔案中的引數指定。下面是引數檔案中指定UNDO表空間對應例項的引數：

Prod01.undo_tablespace = ‘UNDOTBS1’

Prod02.undo_tablespace = ‘UNDOTBS2’

1. UNDO引數

l UNDO_MANAGEMENT初始化引數

UNDO_MANAGEMENT指定系統使用的UNDO空間管理模式。設定為AUTO，例項開啟自動化UNDO管理模式；設定為MANUAL表示使用回滾段的手動管理模式自動UNDO管理（AUM）是從Oracle9i開始引入，以代替回滾段，也可以稱為系統管理UNDO（SMU）。自動UNDO管理自動分配和管理DML操作所需空間的UNDO表空間，代替分配很多不同大小的回滾段。

l UNDO_RETENTION初始化引數

UNDO_RETENTION指定的是事務提交之後UNDO資料保留的時間。事務提交之後，UNDO資料不再需要用於回滾或者事務恢復，但一致性讀可能還需要用到這些UNDO資料。

l UNDO_TABLESPACE初始化引數

每個資料庫可以有多個UNDO表空間，但是對於每個例項只有一個活動的UNDO表空間。在RAC環境中，每個例項都對應一個UNDO表空間，UNDO_TABLESPACE用於指定例項對應的UNDO表空間。UNDO表空間無法進行收縮，如果UNDO表空間過大，只有透過替換的方式縮小UNDO表空間的大小。

l GUARANTEED UNDO RETENTION特性

預設guaranteed undo retention特性是禁用的，如果啟動這個特性意味著資料庫不能覆蓋已提交但保留時間為超過undo_retention指定時間的UNDO資料。啟用這個特性需要更大的UNDO表空間來支撐，如果UNDO表空間沒有足夠的空間會導致DML操作分配UNDO段失敗。啟用這個特效能夠緩解出現ORA-01555錯誤機率，確保在一定的時間內能夠使用部分Flashback特性閃回資料。執行以下SQL語句啟用UNDO表空間的RETENTION特性：

SQL> alter tablespace undotbs1 retention guarantee;

2. UNDO檢視

l V$undostat檢視

V$undostat是v$rollstat的代替和提升，包含很多對UNDO空間的監控和統計資訊。這個檢視對於瞭解例項對UNDO空間的使用情況非常有用，能夠透過監控估算出當前負載需要的UNDO表空間大小，能夠根據統計資訊提供建議調整UNDO_RETENTION，還能夠找出長時間執行的SQL語句。在系統中，資料也使用這個檢視提供的資訊調整UNDO表空間的使用。只有自動化UNDO管理模式才能使用該檢視。

l dba_undo_extents檢視

dba_undo_extents描述了在資料中所有undo表空間包含的區間。這個檢視顯示UNDO中每個區間大小。執行以下SQL語句顯示UNDO表空間中不同區間狀態的統計資訊。

l v$transaction

l dba_rollabck_segs檢視

Oracle恢復基礎概述

相關文章