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;

 

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

 

操作	從緩存中刷新哪些緩存區
使表空間脫機	表空間中的所有塊
使數據文件脫機	數據文件中的所有塊
刪除區間	區間中的所有塊
截斷表	表中的所有塊
將表空間置於備份模式	表空間中的所有塊
用RMAN備份數據文件	數據文件中的所有塊

 

保護聯機重做日志文件

---

 

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. 執行完整備份。

原文：https://www.tuicool.com/articles/r2EZB3Z