Oracle資料庫備份和恢復配置詳解

本文Oracle講述了資料庫備份和恢復配置的詳解過程，可能的失敗及其解決方法。

失敗型別

遇到的失敗或錯誤分為兩大類：物理和邏輯。物理錯誤一般是硬體錯誤或使用資料庫的應用程式中的軟體錯誤，而邏輯錯誤一般在終端使用者級別（資料庫使用者和管理員）。

按從輕到重、易恢復到難恢復排列：

• 陳述句失敗：使用者的SELECT或DML陳述句因許可權、語法或資源限制而失敗。
• 使用者錯誤：使用者誤刪了一個表或表中的行。
• 使用者行程失敗：與資料庫的連線因為客戶端斷開或未預料的停機而失敗。
• 網路失敗：客戶機和伺服器（資料庫）之間的網路連線因為網路硬體或協議錯誤而失敗。
• 實體失敗：資料庫實體因為bug、作業系統錯誤、記憶體崩潰甚或伺服器的功率損失而崩潰。
• 媒介失敗：磁碟驅動物理錯誤或控制器硬體失敗。

Oracle備份和恢復方法

1. 恢復管理器（Recovery Manager，RMAN）是用於在表級別（12c新增）、資料檔案、表空間和資料庫級別上備份、還原和恢復資料庫物件的主要工具。除了備份和恢復之外，RMAN還有許多用途，包括把資料庫克隆或複製到另一個位置。RMAN的一個主要元件是備份和恢復物件的一個特定位置，稱為快速恢復區（Fast Recovery Area，FRA）。這個區在理想情況下是ASM中的一個磁碟組，但也可以位於作業系統的檔案系統上。無論位置在哪裡，它都是所有備份和恢復物件的集中儲存位置。FRA根據大小和恢復標的來管理，這是指根據恢復視窗或需要保留的備份數。使用FRA是可選的，但這是最佳實踐方式。

2. Oracle安全備份（Oracle Secure Backup，OSB）與RMAN一起提取RMAN備份，把它們複製到磁帶裝置或運儲存中，以防止資料中心的災難性故障而導致的資料丟失。OSB還提供了OS級別上的RMAN擴充套件，來備份Linux伺服器和任何附加的儲存，例如網路附加儲存（NAS）裝置。

3. Oracle Data Guard是Oracle的一個可用性（HA）很高的解決方案，用於確保接近實時（因為主資料庫失敗）的可用性，或防止資料庫崩潰。從主資料庫的副本中實體化一個獨立資料庫（可以建立好幾個獨立資料庫），從資料庫中接收重做資料，來更新其資料檔案。因此，獨立資料庫就與主資料庫保持同步。獨立資料庫還可以臨時用作資料庫的只讀副本，以用於生成報表，因此釋放主資料庫上的資源，在聯機事務處理（OLTP）環境中有更短的響應時間。另一種獨立資料庫稱為邏輯獨立資料庫。它不是持續不斷地把重做資料應用於主資料庫的物理副本，而是把重做操作轉換為等價的DML SQL。因此，獨立資料庫在邏輯上等價於獨立資料庫，但幾乎肯定沒有與主資料庫相同的物理結構。邏輯獨立資料庫並不是容錯環境的一部分，而是一個最佳化為資料倉儲的獨立資料庫，其中包含了與主資料庫相同的資料。

實體恢復和資料庫不可能崩潰

實體失敗的原因有電力故障、重啟伺服器、發出SHUTDOWN ABORT命令，或導致實體後臺行程終止、破壞System Global Area（SGA）的任何事情——所有這些都沒有嘗試把快取中變更的快取資料掃清到資料檔案中，或者混滾任何正在進行的事務。

大體上，實體恢復只不過是使用聯機日誌檔案的內容，將資料庫緩衝區快取重新構建至崩潰之前的狀態。這個重構過程將重演在崩潰時未被寫至磁碟的資料塊的相關重做日誌中提取出的所有變更。完成上述操作後，就能夠開啟資料庫。此時，資料庫仍然受到損壞，但是由於使用者看到的實體已被修複，因此允許使用者進行連線。實體恢復的這個階段稱為前滾，該階段將恢復所有變更（也就是針對已提交和未提交事務的資料塊變更與撤銷塊變更）。每條重做記錄都具有重新構造一個變更所需的最少資訊：資料塊的地址以及新值。在前滾期間，會讀取每條重做記錄，相應的資料塊從資料檔案載入資料塊緩衝區快取，並且應用相應的變更，隨後，資料塊會被寫回磁碟。

向前回滾結束後，崩潰看上去似乎從未發生過。不過此時資料庫中還存在未提交的事務，這些事務必須被回滾，Oracle將在實體恢復的回滾階段自動完成未提交事務的回滾操作。然而，上述操作則發生在資料庫已被開啟且使用之後。如果使用者在連線時遇到某些需要回滾但是尚未回滾的資料，那麼不存在任何問題。由於前滾階段會填充保護未提交事務的撤銷段，因此伺服器能夠以正常的方式回滾變更，從而實現度一致性。

實體恢復時自動的、不可避免的，那麼如何才能呼叫實體恢復呢？答案是使用STARTUP命令。在實體啟動時，載入控制檔案之後，開啟資料庫之前，SMON行程會檢視所有資料檔案和連線重做日誌檔案的檔案頭。此時，如果已經出現了實體失敗，由於檔案頭沒有全部同步，因此SMON行程會發現實體失敗，從而進入實體恢復例程，而資料庫只能在前滾階段結束之後才能被真正地開啟。

如果執行了STARTUP命令，那麼絕對不會丟失任何資料。在發生任何崩潰之後，都應當執行STARTUP命令並檢視崩潰的程度。這個命令可以解決所有問題。

重做日誌流中始終存在足夠的資訊，因此不僅能夠重新構造發生崩潰前進行的所有操作，而且能夠重新構造回滾崩潰時正在進行的事務所需的撤銷資訊。分析下麵的場景：

使用者John啟動了一個事務。John使用某些新值更新某個表的一行，其伺服器行程則將舊值複製至一個撤銷段。但是完成這些更新之前，伺服器行程會將變更寫入日誌緩衝區。使用者Joo也啟動了一個事務。兩個使用者都未提交事務，也沒有在磁碟上寫下任何資料。如果此時實體崩潰，那麼不存在（甚至重做日誌中也不存在）與任一個事務相關的記錄。因此，兩個事務都不會被恢復，但這並不是一個問題。因為都未被提交，所以不應當恢復這兩個事務（未提交的工作絕不會被儲存）。

隨後，使用者John提交了自己的事務。這個提交操作會觸發LGWR行程將日誌緩衝區中的內容掃清到聯機重做日誌檔案，也就是說，此時重做日誌檔案記憶體在joh和Joo的事務對錶和撤銷段的更改以及針對John的事務的提交記錄。只有在LGWR行程結束後，“commit complete（提交完成）”訊息才會被傳回給John的使用者行程。但是，資料檔案中仍然不會寫入任何資料。如果此時實體失敗，那麼前滾階段會重新構造這兩個事務，不過處理完所有重做後仍然不會得到針對Joo的更新操作的提交記錄，這將通知SMON行程回滾Joo所做的變更，同時保留John所做的變更。

然而，如果DBWn行程在實體崩潰前將某些資料塊寫入磁碟，那麼又將出現怎樣的情況呢？John（或者另一個使用者）可能頻繁地重新查詢與其相關的資料，而Joo對資料進行了未提交的更改，並且不再檢視這些資料。因此，DBWn行程將確定在磁碟上優先寫入Joo所做的變更，然後再寫入John所做的變更。DBWn行程總是會在磁碟上先寫入不活躍的資料塊，然後再寫入活躍的資料塊。因此，此時資料檔案中儲存了JOO的未提交事務，但是丟失了John的已提交事務。這是最糟糕的損壞型別。不過經過仔細考慮可以發現：即使此時實體崩潰，前滾仍然能夠解決這個問題。重做流中始終存在重新構建已提交變更所需的足夠資訊，其原因顯而易見，因為提交操作在DBWn行程完成寫入之前不會結束。不過，因為LGWR行程將所有資料塊的所有變更都寫至日誌檔案，因此日誌檔案中也將存在重新構建撤銷段所需的足夠資訊，從而能夠回滾Joo未提交的事務。

綜上所述，因為LGWR行程總是先於DBWn行程進行寫操作，並且在提交的同時進行實時的寫操作，所以在重做流中始終存在足夠的資訊，從而能夠重新構建任何已提交的未被寫入資料檔案的變更，回滾任何已被寫入資料檔案的未提交變更。只要沒有受到物理損壞，重做與回滾這種實體恢復機制就能夠使Oracle資料庫絕對不被破壞。

執行SHUTDOWN ABORT命令會損壞資料庫嗎？答案是絕對不會！這個命令不可能損壞資料庫。只要聯機日誌檔案可用，實體恢復機制就總是可以恢復任何損壞的資料。

檢查點和重做日誌

檢查點機制

檢查點位置（崩潰後，重做流中的實體恢復起點）由DBWn自動前移。這個過程稱為“增量檢查點（incremental checkpointing）”。除此之外，還有“完整檢查點（full checkpointing）”和“區域性檢查點（partial checkpointing）”。

增量檢查點是正常資料庫活動的一部分。DBWn行程決定快取中是否有足夠的、已更新的塊，是否應把其中的幾個寫入磁碟。選擇寫入哪些變更的緩衝區的演演算法，是基於更改時多久以前進行的，以及如何啟用緩衝區。

在一般情況下，只有緩衝區已更改，且是空閑的，才能寫入該緩衝區。永遠不要忘記，提交變更和把塊寫入磁碟之前沒有相關性，DBWn只寫入所需的最少塊數。

如果將素有臟緩衝區都寫入磁碟，就會出現完整檢查點。在常規執行中，快取中可能存在一百萬個臟緩衝區，但對於增量檢查點，DBWn只寫入其中的數百條。而對於完整檢查點，它將寫入這些內容。為此，必須完成大量的工作：在執行檢查點時，需要非常高的CPU使用率和磁碟使用率，使用者會話的效能會隨之降低。完整檢查點會對業務產生負面影響。鑒於此，只有在兩種情況下才執行完整檢查點，第一種情況是有序關閉，第二種情況是DBA要求這麼做。

當使用NORMAL、IMMEDIATE或TRANSACTIONAL選項關閉資料庫時，都會執行檢查點：在關閉和解除安裝資料庫之前，DBWn會將所有的臟緩衝區掃清到磁碟中。這意味著，再次開啟資料庫時，不需要執行任何���復操作。在執行某些操作（如啟用歸檔日誌樣式）前，始終希望（也有必要）執行乾凈關閉。使用以下命令，可以在任何時間發出完整檢查點訊號：

alter system check point;

對於某些操作而言，區域性檢查點是必須的，並會自動執行。區域性檢查點影響的緩衝區因操作而異：

保護聯機重做日誌檔案

Oracle資料庫執行時至少需要兩個聯機重做日誌檔案組， 從而能夠在兩個組之間進行切換。考慮到效能因素，可能需要新增更多的聯機重做日誌檔案組，但兩組是必需的。每個組都由一個或多個成員組成，這些成員是物理檔案。執行Oracle資料庫只要求每個組有一個成員，但是為了安全起見，每個組至少都應當具有兩個成員。

DBA不允許丟失當前聯機日誌檔案組的所有備份。如果出現這種情況，就會丟失資料。在丟失當前聯機日誌檔案組的素有成員時，不丟失資料的唯一方法是，配置一個無資料 損失的Data Guard環境，不過比較複雜。為什麼說不丟失但錢聯機日誌檔案組的所有成員直觀重要呢？答案與實體恢復有關。實體崩潰後，SMON行程會使用當前聯機日誌檔案組的內容進行前滾恢復，從而修複資料庫中的任何損壞。如果當前聯機日誌檔案組不可同，可能是由於未被多路復用，一個成員因介質受損而被破壞，那麼SMON行程無法進行前滾恢復。如果SMON行程無法透過前滾修正資料庫的損壞，那麼不能開啟資料庫。

如果重做日誌檔案組的一個成員被損壞或丟失，那麼資料庫在存在備份成員的情況下，仍然會保持開啟狀態。這與控制檔案不同，控制檔案任何副本的損壞都會使資料庫立即崩潰。同樣，只要存在至少兩個重做日誌檔案組，每個組都至少有一個有效的成員，那麼在資料庫開啟時，也可以新增或移動重做日誌檔案組以及組中的成員。

在開啟資料庫時，無須停機，聯機重做日誌就可以重新配置，而資料庫在非載入樣式下或完全關閉時，才能執行控制檔案中的操作。

V$LOG檢視給每個組顯示一行，V$LOGFILE檢視給每個日誌檔案成員顯示一行。

SYS@ prod>select group#,sequence#,members,status from v$log;
    GROUP#  SEQUENCE#    MEMBERS STATUS---------- ---------- ---------- ----------------        1        10          1 CURRENT        2          8          1 INACTIVE        3          9          1 INACTIVE
SYS@ prod>select group#,status,member from v$logfile;
    GROUP# STATUS  MEMBER---------- ------- ------------------------------        3        /u01/oradata/prod/redo03.log        2        /u01/oradata/prod/redo02.log        1        /u01/oradata/prod/redo01.log
SYS@ prod>alter system switch logfile;
System altered.
SYS@ prod>select group#,sequence#,members,status from v$log;
    GROUP#  SEQUENCE#    MEMBERS STATUS---------- ---------- ---------- ----------------        1        10          1 ACTIVE        2        11          1 CURRENT        3          9          1 INACTIVESYS@ prod>

第一個查詢說明該資料庫有三個日誌檔案組。此時LGWR行程正在寫的當前組是組1（status – current），其他兩個組是不活動的。SEQUENCE#列說明從建立資料庫以來（或者使用ALTER DATABASE OPEN RESETLOG重置日誌順序以來）總共發生過10次日誌切換。MEMBER列說明每個組都由一個成員組成。

第二個查詢顯示了不同的聯機重做日誌檔案。其中，每個檔案都是由GROUP#標識的一個組的一部分，並且具有唯一的名稱。STATUS列應當時鐘為空。如果該成員未使用（原因通常是資料庫剛開啟，尚未發生日誌切換），那麼其狀態為STALE，並且一直會持續到發生第一次日誌切換時。如果日誌檔案成員的狀態為INVALID，則說明存在問題。

命令lter system switch logfile強制執行日誌切換。

最後一個查詢說明在日誌切換後，組2成為LGWR行程進行寫操作的當前組，序列號切換為11。先前的當前組（組1）的狀態變為ACTIVE，這以為著如果此時出現實體失敗，SMON行程仍然需要使用組2來進行實體恢復。稍後，由於檢查點位置前移，因此這個組的狀態不久將變為INACTIVE。

為了防止資料庫在聯機重做日誌檔案組受到破壞時丟失資料，請準備多路復用副本。可以給每個日誌檔案組使用下麵的命令，將多路復用副本新增到聯機日誌中：

alter database add logfile member ‘D:\app\orale\oradata\redo01a.log’ to group 1;

歸檔日誌樣式和歸檔器行程

將資料庫改為歸檔日誌樣式能夠確保：如果聯機重做日誌檔案組沒有首先被覆製為歸檔日誌檔案，那麼不能被重寫。這樣將存在一系列歸檔日誌檔案，這些檔案描述了應用於資料庫的所有變化的完整歷史。如果一個資料檔案在某個時刻被破壞，那麼可以還原該資料檔案的一個備份，並應用歸檔日誌重做流中的變更，從而使這個資料檔案是最新的。

在預設情況下，資料庫時在非歸檔日誌樣式中建立的，這意味著日誌切換在沒有先進行複製的情況下會重寫聯機重做日誌檔案。此時資料庫仍然不會受損，但是如果資料檔案因為介質失敗被損壞，那麼會丟失資料。在資料庫被轉換至歸檔日誌樣式時，如果從最近一次資料庫備份開始生成的所有歸檔日誌檔案都可用，那麼不會丟失資料。

一旦資料庫被轉換至歸檔日誌樣式，就會自動啟動一個新的後臺行程：歸檔器行程ARCn。在預設情況下， Oracle會啟動4個這樣的行程，不過在實際應用中最多可以啟動30個。

Oracle實體使用ARCn行程維護歸檔日誌的建立過程，但是DBA必須透過使用作業系統命令或RMAN來控制到磁帶的遷移過程。

資料庫只有在乾凈關閉後處於載入樣式時，才能轉換至歸檔日誌樣式，並且必須由建立了SYSDBA連線的使用者完成。此外，還必須設定若干初始化引數，來控制所生成的歸檔日誌名稱和位置。

配置快速恢復區

快速恢復區是一個磁碟標的，用作與恢復相關的檔案的預設位置。可以使用兩個實體引數對快速恢復區進行控制：

• db_recovery_file_dest ：指定位置。這可以使檔案系統目錄或ASM磁碟組。多個資料庫可以共享一個公共標的；在標的中，每個資料庫都有各自自動建立的目錄結構。
• db_recovery_file_dest_size ：限制資料庫將要在標的中佔用的最大空間量，但不能說明標的中實際可用的空間大小。

快速恢復區的配置和使用在兩個檢視中顯示：

• v$recovery_file_dest
• v$recovery_area_usage

寫入快速恢復區（除非另外指定）的檔案包括：

• 恢復管理器備份
• 歸檔重做日誌檔案
• 資料庫閃回日誌

RMAN可以管理快速恢復區中的空間：它可以根據已配置的關於保留檔案副本和備份的策略，刪除不再需要的檔案。在理想狀況下，快速恢復區將足夠大，可以儲存完整的資料庫副本、在必要時恢復副本所需的任何歸檔日誌和增量備份，以及聯機重做日誌檔案和控制檔案的多路復用副本。

資料庫備份例程還應包括將快速恢復區備份到磁帶，從而實現一級、二級和三級儲存的策略。

• 一級儲存是磁碟中使用的資料庫。
• 二級儲存是資料庫的副本以及快速恢復需要的檔案。
• 三級儲存是磁帶庫中的長期備份。

RMAN可以管理整個週期：將資料庫從一級儲存備份到二級儲存，並將備份從二級儲存遷移到三級儲存。可以將這樣的系統實現為在故障之後能接近瞬時恢復，同時能在必要時及時恢復資料庫。

快速恢復區可以隨時配置，不會影響其中的任何檔案。變更只應用於之後建立的檔案。

配置ARCHIVELOG樣式

切換為歸檔日誌樣式的過程：

1. 乾凈地關閉資料庫。
2. 以裝載樣式啟動。
3. 執行命令ALTER DATABASE ARCHIVELOG;
4. 開啟資料庫
5. 執行完整備份。

zhaochunyi

贊賞

朋友會在“發現-看一看”看到你“在看”的內容

確定