Oracle數據庫備份和恢復配置詳解

時間 2019-11-12

標籤 oracle 數據庫備份恢復配置詳解欄目 Oracle 简体版

原文原文鏈接

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

失敗類型sql

遇到的失敗或錯誤分爲兩大類：物理和邏輯。物理錯誤通常是硬件錯誤或使用數據庫的應用程序中的軟件錯誤，而邏輯錯誤通常在終端用戶級別（數據庫用戶和管理員）。數據庫

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

語句失敗：用戶的SELECT或DML語句因權限、語法或資源限制而失敗。安全
用戶錯誤：用戶誤刪了一個表或表中的行。服務器
用戶進程失敗：與數據庫的鏈接由於客戶端斷開或未預料的停機而失敗。網絡
網絡失敗：客戶機和服務器（數據庫）之間的網絡鏈接由於網絡硬件或協議錯誤而失敗。app
實例失敗：數據庫實例由於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 ：限制數據庫將要在目標中佔用的最大空間量，但不能說明目標中實際可用的空間大小。

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