OCP認證考試指南（18）：配置數據庫的備份與恢復（1）

1、備份與恢復問題

考慮業務需求、性能以及資金成本的最終結果通常是一個折衷的方案。記錄這個方案極其重要，記錄的形式通常是一個服務級別協議（service level agreemenet）。

服務級別協議與備份和恢複相關的3個方面爲：

• 平均失敗時間（mean time betwwen failures，簡寫MTBF）
• 平均恢復時間（mean time to recover，簡寫MTTR）
• 數據損失量

DBA的目標就是減少MTTR和數據損失的同時增加MTBF。

MTBF指的是數據庫出現失敗的頻繁度。Oracle提供兩種有助於百分之百可用性的高級選項：RAC和Streams。
MTTR指的是數據庫出現失敗後的停機時間。
第三個目標將數據的損失量最小化。

2、失敗類別

2.1、語句失敗

導致語句失敗的4個常見原因爲：
無效數據（invaild data）：這種情況通常是由於違反了格式或完整性約束所造成的。
缺少權限（space management）：
空間分配問題：相關的語句失敗原因包括：由於表空間已滿而無力擴展某個段；耗盡撤銷空間；運行使用磁盤排序的查詢時臨時空間不足；某個用戶達到配額；某個對象達到最大區間限制。
邏輯錯誤（logic error）：在某些情況下，編程人員完全可能開發數據庫無法運行的代碼。

2.2、用戶進程失敗

用戶進程可能由於多種原因而失敗，包括：用戶並非登出的異常退出；終端的重新啓動；導致地址違規的程序。

2.3、網絡失敗

需要考慮3個方面：偵聽器、網絡接口卡以及路由。

2.4、用戶錯誤

解決用戶錯誤的理想方式是首先防止這些錯誤的出現。閃回查詢是針對過某時存在的數據所運行的查詢。通過使用撤銷數據，就可以只爲當前會話構造讀一致的數據庫。

^?[Copy to clipboard]View Code SQL

SQL> conn scott/tiger
Connected.
SQL> delete from emp;
 
14 rows deleted.
 
SQL> commit;
 
Commit complete.
 
SQL> select count(*) from emp;
 
  COUNT(*)
----------
         0
 
################################################
# 這裏的時間1/24是1小時，1/24/60是1分鐘，恢復2分鐘前被delete的記錄
################################################
 
SQL> insert into emp select * from emp as of timestamp(sysdate - 2/24/60);
 
14 rows created.
 
SQL> commit;
 
Commit complete.
 
SQL> select count(*) from emp;
 
  COUNT(*)
----------
        14
 
SQL> drop table emp;
 
Table dropped.
 
SQL> select count(*) from emp;
select count(*) from emp
                     *
ERROR at line 1:
ORA-00942: table or view does not exist
 
SQL> flashback table emp to before drop;
 
Flashback complete.
 
SQL> select count(*) from emp;
 
  COUNT(*)
----------
        14

Log Miner是一種從聯機和歸檔的重做日誌中抽取信息的高級工具。重做包含數據塊發生的所有變化。通過抽取表數據塊的變化，可以重新構造所做的變化，所以重做能夠用於早先時間的還原備份。如果具有相關日誌的副本，那麼Log Miner能夠返回至先前的任意時刻，閃回查詢只能返回至撤銷表空間所允許的時刻。

對於修正用戶錯誤來說，不完全恢復與閃回數據庫是作用更爲顯著的方法。

2.5、介質失敗

介質失敗意味着對磁盤的損壞，因此磁盤上存儲的文件會受到損壞。爲了應對介質失敗，必須生成控制文件、聯機重做日誌以及歸檔的重做日誌文件的多個副本，此外還必須對控制文件、數據文件以及歸檔日誌文件進行備份。不必備份重做日誌，事實上，重做日誌在被複制至歸檔日誌時會進行備份。複用並不能保護數據文件，數據文件必須通過硬件冗餘受到保護。

2.6、實例失敗

實例失敗（instance failure）是實例的無序關閉，通常稱爲崩潰（crash）。斷電、關閉或重啓服務器以及許多至關重要的硬件問題都會導致實例失敗。在後臺進程可能失敗的某些情況下，也會觸發即時的實例失敗。其結果都與執行SHUTSOWN ABORT命令的結果相同。

實例失敗後，數據庫完全可能丟失已提交的事務以及存儲未提交的事務，從而使數據庫會出現訛誤。這是因爲服務器進程在內存中進行工作，進程更新了數據庫高速緩存區內的數據塊與撤銷塊。而這時候，DBWn進程並沒有完全將更新後的數據塊寫至數據文件。不過LGWR進程儘可能實時地進行寫操作。

3、實例恢復

3.1、實例恢復的過程

實例恢復只不過是使用聯機日誌文件的內容將數據庫高速緩存區重新構建至崩潰之前的狀態。這個過程將重演從崩潰時未被寫至磁盤的數據塊的相關重做日誌中抽取出的所有變化。完成上述操作後，就能打開數據庫。此時，數據庫仍然存在訛誤，但由於用戶看到的實例已被修復，因此允許用戶進行連接。實例恢復的這個階段稱爲前滾，該階段將恢復所有變化。每條重做記錄都具有重新構造一個變化所需的最少信息：數據塊的地址以及新值。前滾期間，會讀取每條重做記錄，相應的數據塊從數據文件載入數據庫高速緩存區，並且應用相應的變化。之後，數據塊會被寫回磁盤。

實例恢復是自動的和不可避免的，使用STARTUP調用實例恢復。首先，數據庫過度到加載模式時，SMON進程會讀取控制文件。之後，數據庫過度到打開模式時，SMON進程會查看所有數據文件和聯機重做日誌文件的文件頭。此時，如果已經出現實例失敗，由於文件頭沒有全部同步，SMON進程會發現實例失敗，從而進入實例恢復例程，數據庫只能在前滾階段結束之後才能被真正地打開。

如果執行了STARTUP命令，那麼決不會丟失任何數據。在發生任何崩潰之後，都應當嘗試執行STARTUP命令並查看崩潰的程度。

3.2、實例恢復不可能導致數據庫出現訛誤

因爲LGWR進程總是先於DBWn進程進行寫操作，並且在提交的同時進行實時的寫操作，所以在重做流中始終存在足夠的信息，從而能重新構建任何未被寫入數據文件的已提交變化以及回滾任何已被寫入數據文件的未提交變化。重做與回滾的這種實例恢復機制能夠使Oracle數據庫絕對不可能出現訛誤。

3.3、調整實例恢復

MTTR（各種事件出現之後的平均恢復時間）是許多服務級別協議的一個重要部分。實例恢復能夠保證不產生訛誤，但是在數據庫打開之前需要耗費大量的時間來完成實例恢復的前滾。這個時間取決於兩個因素：需要讀取的重做數，以及應用重做時需要在數據文件上完成的讀/寫操作數。這兩個因素都受檢查點的控制。

檢查點（）保證了某個特定的時間，DBWn進程將構成一個特定系統更改號（System Change Number，簡寫爲SCN）的所有數據變化都已寫入數據文件。在一個實例崩潰事件中，只有SMON進程需要重演從上一個檢查點位置開始生成的重做。無論是否被提交，在這個檢查點位置之前的所做的全部變化都已被寫入數據文件。因此，顯然不需要使用重做來重新構造在該檢查點位置之前已提交的事務。此外，在這個檢查點之前未提交事務所做的變化也會被寫入數據文件，因此也不需要重新構造該檢查點之前的撤銷數據，回滾需要使用的這些數據已經存在於磁盤上的撤銷段內。

檢查點位置越近，實例恢復就越快。

參數FAST_START_MTTR_TARGET使得實例恢復時間的控制變得十分容易。以秒爲單位指定該參數，Oracle隨後將確認DBWn進程在實例崩潰後能夠以足夠快的速度將數據塊寫至磁盤，從而不會超過指定的秒數。因此，設置的FAST_START_MTTR_TARGET參數值越小，DBWn進程將會更努力的嘗試最小化檢查點位置與實際時間之間的間隔。須要注意，如果設置了一個不實際的較小值，那到DBWn進程無論如何也不可能達到要求。

^?[Copy to clipboard]View Code SQL

SQL> conn system/oracle
Connected.
 
################################################
# fast_start_mttr_target參數設置爲0，從而禁用檢查點調整功能
################################################
 
SQL> alter system set fast_start_mttr_target = 0;
 
System altered.
 
################################################
# 建表和啓動事務，模擬工作負荷
################################################
 
SQL> create table t1 as select * from all_objects where 1 = 2;
 
Table created.
 
SQL> insert into t1 select * from all_objects;
 
11185 rows created.
 
################################################
# 查詢顯示實例恢復期間需要在數據文件上進行的讀/寫操作數以及必須處理的重做數據塊
# estimated_mttr顯示了以秒爲單位的實例恢復時間
################################################
 
SQL> select recovery_estimated_ios, actual_redo_blks, estimated_mttr
  2  from v$instance_recovery;
 
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR
---------------------- ---------------- --------------
                  1311            17326             16
 
SQL> commit;
 
Commit complete.
 
################################################
# 這是提交後的查詢，可以看見結果變化不大，因爲COMMIT不會對DBWn進程產生影響
################################################
 
SQL> select recovery_estimated_ios, actual_redo_blks, estimated_mttr
  2  from v$instance_recovery;
 
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR
---------------------- ---------------- --------------
                  1311            17343             16
 
################################################
# 手動執行檢查點進程，可以看到，recovery_estimated_ios、actual_redo_blks已經清零
# estimated_mttr不會變小因爲該列的內容不會被實時更新
################################################
 
SQL> alter system checkpoint;
 
System altered.
 
SQL> select recovery_estimated_ios, actual_redo_blks, estimated_mttr
  2  from v$instance_recovery;
 
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR
---------------------- ---------------- --------------
                    10                6             13