為了最大限度保障數據的安全性，同時能在不可預計災難的情況下保證數據的快速恢復，需要根據數據的類型和重要程度制定相應的備份和恢復方案。在這個過程中，DBA的職責就是要保證數據庫（其它數據由其它崗位負責）的高可用和高性能，比如：如何避免數據庫發生常規錯誤、如何增加MTBF、如何降低MTTR、使用使用哪些冗余技術保護關鍵組件以及如何做到最小化數據丟失。

在社區最近的在線交流中集中討論了Oracle數據庫備份恢復相關的問題，同時也拓展到了其它方面，比如性能問題、案例分析、RAC相關的備份問題及生產環境中的經驗分享。非常感謝愛好者的參與，特別是ttkanni、fengshuai等會員的積極參與，由主要分享者royalwzy對所涉及的問題進行了整理和歸類，提供給大家參考，包括如下幾個部分：

一、數據庫備份恢復基本問題

二、數據庫備份恢復性能相關問題

三、數據庫備份恢復性能案例分析

四、數據庫備份恢復性能優化問題

五、數據庫備份恢復RAC相關問題

六、數據庫備份恢復經驗分享

一、數據庫備份恢復基本問題

1、問：Oracle11g數據庫數據量有50T，每天增量50g左右，該如何制定備份方案，如何驗證備份的有效性？

答：

50T的數據也不大，運營商的地市級市數據基本都在100T以上了，只要備份環境允許的話，也能在12h內備份完成。

以一次全備份來算，在12h內備份完成，那麽平均備份速度最低是

5010241024/12/3600=1210MB/S

按照LTO 5 drive的速度（140MB/S）來算，備份最低的drive數量：1210/140=9

為了保障dive盡量保持最大IO，建議額外關註幾點：

1，datafile較小的話，聚合成較大的bakcup piece

2，調整read/write blocksize減少讀寫次數，可酌情調整至MB大小

3，調整備份腳本，一個channel對應一個backup session，每個channel盡量保障只有一個大塊backup piece寫入

4，關閉備份軟件和drive的多路復用功能，保證每個dive上只有一個session寫入

5，備份盡量走單獨的HBA卡，不要和業務或存儲共用

備份策略的話，一個完整的備份周期肯定是FULL+INCR+INCR比較符合實際情況，如果條件允許Synthetic Full也是一個很不錯的選擇。歸檔看需求，4h或者6h備份頻率都可以。

相關案例：

某地市數據庫，大概數據量90T，備份從4塊獨立的16 GB HBA走，每塊HBA綁2個LTO 5物理drive，備份起8個channel，每個channel對應一個bakcup piece，每個bakcup piece都聚合為500 GB，R/W blocksize為2MB，多路復用關閉。

2、問：Oracle的數據庫備份，一般采用數據泵將庫和數據備份，這樣安全嗎？一般是各一個周備份一次。

答：

安全這個詞在這裏的定義比較模糊。

1.expdp/impdp是邏輯備份，備份的過程中也可以使用加密從而保證數據的安全。

2.也正是因為這種方式是邏輯備份，不論你才用多久的時間間隔來備份，兩次備份過程中有數據丟失都無法通過這種方式恢復到數據丟失的那一刻。
想要保證數據可以恢復到任意時刻建議使用rman；如果每隔一段時間想要保存一下數據某時間點的快照的話，使用數據泵和rman都行。

3、問：如何設計oracle數據庫的備份與恢復的時間窗口？都需要做都那些方面的考慮？系統環境越來越復雜，需要備份的數據庫也越來越多。在做數據庫的備份與恢復設計時，應如何設計oracle數據庫的備份與恢復的時間窗口？都需要做都那些方面的考慮？

答：

先說備份，需要著重考慮幾點：

1，備份方式：根據實際數據保護需要，確定備份方式，一般都是FULL+INCR。條件允許就全FULL。其次就是備份頻率，一個FULL後追加多少個INCR，歸檔多久備份一次。

2，備份時間窗口：備份的過程中對生產業務（數據庫）壓力是很大的，所以首先應該規劃備份的時間窗口，一般都在晚上。

3，備份流量路徑：確定了備份時間窗口，就想想備份的流量怎麽走。LAN-FREE備份好說，LAN備份就要特別留意了，備份前先拉著網絡的哥們交流下感情，最終確定好流量路徑，不要影響其他業務。

4，數據保留、克隆：對於重要的數據，不僅需要備份，最好克隆一份。出入庫看實際需求了。

恢復一般在單獨的恢復環境，所以沒什麽需要特別註意的。

4、問：RMAN備份和數據泵備份的比較，適用範圍？

答：

RMAN是oracle推薦的數據保護工具，在備份恢復上，RMAN能夠借助備份數據恢復一段時間範圍內某個時間點數據庫的狀態。此外RMAN在備份恢復的校驗上更加嚴格，最大程度保護數據的完整性、一致性以及適用性，同時也方便備份恢復的統一管理。

EXP/EXPDB，在oracle的定位中，只是一個數據遷移的手段。在備份恢復上，數據泵只能利用備份數據來恢復一個時間點上的數據庫狀態，無法借助備份數據在一段時間內自由選擇恢復點。在嚴格的意義說，數據泵備份並不能說是一種有效的數據保障措施，這更像是一種臨時的保底操作。

5、問：oracle數據庫備份及恢復那種方式更簡單！更快捷？exp/imp 還是rman或是其他方式？

答：

應該按照系統的RTO的要求上來看，邏輯導出和RMAN配合使用，exp的方式因為要放到本地或者放到本地之後上傳到服務器，這種比較占用磁盤空間，但是在一些跨平臺恢復上exp又是可以的。rman主要還是防止邏輯錯誤，搭配備份軟件，進行數據的集中管理較多。

集中化備份管理來說，rman是最有效也是最可靠的方式。exp、expdb雖然操作簡單，對於數據的持續性保護太弱了~

6、問：ORACLE數據庫該如何設定防範邏輯錯誤的備份策略和備份方案？

答：

邏輯錯誤有很多中解決辦法，使用備份恢復是最有效的一種，但是大多時候並不是最優的一種方法。

如果要使用備份等話，那就建議保留所有的歸檔日誌，除了備份恢復，還可以使用Oracle數據庫的閃回功能，比如：閃回查詢，閃回表，閃回事務和閃回數據庫等操作。

7、問：很多時候Oracle備份或恢復都是由oracle結合第三方備份軟件完成，在備份恢復的過程當中時不時的會遇到備份恢復的速度比預想的要差很多，各位有哪些經驗？如何定位是oracle設置的問題還是備份軟件的方面的原因？

答：

性能排查無外乎源、路徑、目標這三點，第三方備份軟件可以看做在“路徑”上的管理員，調度數據從源到目標。

源端問題，存儲問題就從存儲讀直接寫到null看讀速度，寫就直接生產隨機數據寫存儲。

路徑問題，從源內存直接生產隨機大數據寫備份介質（drive一般不會有性能瓶頸）或者直接做rman的validate驗證恢復

目標端問題，drive一般只需檢查物理狀態。AFTD文件類型設備檢查其存儲性能問題，方法如上。

8、問：針對不同業務系統采用的數據庫備份策略是怎麽樣的？定期恢復驗證的周期為多久？

答：

備份方式無外乎FULL INCR Synthetic Full

備份環境極好，只用FULL備份，恢復速度最快。

備份環境稍好，FULL +INCR +Synthetic Full，恢復速度適中。

備份環境有限，FULL +INCR +INCR，恢復速度一般。

對於FULL+INCR（Synthetic Full）這種方式，INCR次數不建議太多（INCR較大的數據庫建議INCR次數不超過3），否則恢復速度會大打折扣。

現在廠商還宣傳一種特殊的備份方式：Virtual synthetic full backup

這種備份方式，利用傳統的FULL+INCR進行，Virtual synthetic full backup時在備份介質上將FULL +INCR整合成一個相當於實際的FULL對外提供恢復服務。

恢復驗證周期，一般一個季度內至少挑選各類型備份恢復一次。

恢復環境好，恢復驗證頻率可以為一個月一次，每次都真實恢復。

恢復環境稍好，適當降低恢復驗證頻率，挑選重要系統備份真實恢復，其余做oracle validate恢復或者scan tape。

恢復環境一般，在連續的多個備份周期內至少能對一個完整周期的備份進行oracle validate恢復或者scan tape。

9、問：最近veritas的來做技術交流，據他說NBU的備份一體機在生產庫出問題的情況下，可以通過rename一系列操作將庫從備份一體機中拉起來直接用。有用過的嗎？

答：

在其他廠商的產品裏有VM_RECOVERY可以實現這樣一種恢復。直接從備份介質讀備份數據，在前端虛擬出一臺虛擬機。

但在數據庫上，我記得還是要恢復的，廠商吹噓的直接拉起庫？只要你用RMAN rename就是有恢復，因為備份數據從備份軟件還原到RMAN識別、rename就是恢復的過程。

10、問：一個數據庫實例下面有十幾個用戶，如何實現分用戶備份各自的數據，不用一個一個exp?各用戶如何實現並發備份？

答：

Oracle Rman無法實現分用戶備份，但可以折中處理：備份用戶對應的所有表空間數據。

Oracle Rman是通過channel和復用來實現並發備份的，具體語法參考RMAN手冊。

11、問：在三地兩中心的雙活結構中，oracle的數據庫雙活如何進行安裝部署，在這種情況下還需要有數據庫備份的必要性呢？ODG和ADG在這種數據庫備份環境中該如何操作呢？

答：

數據庫雙活了更需要數據庫備份，否則數據庫邏輯錯誤，一損俱損，都沒得恢復了。。ORACLE備份不就是RMAN或者數據泵，備到存儲或磁帶，保持一份最新的數據，防治數據庫邏輯錯誤。

多活只能保障單邊故障下業務還可以online（高可用），但對於數據邏輯錯、歷史數據審查、歷史數據分析等問題，多中心多活的結構框架依舊無法克服。

的確，從另外一方面，數據庫雙活了，應用同樣需要雙活。切換時還需要考慮是直接切換到異地的機房，還是在原機房進行恢復。

12、問：Oracle 備份保留參數主要是兩個：一個是保留的天數，另一個是保留的副本數。那麽這兩種情況具體有什麽區別，在什麽場景下使用什麽樣的參數設置呢？

答：

前者主要考慮的方面是：想要把數據庫恢復到歷史的哪一個時間點；後者主要考慮的方面是：要針對備份如何做冗余

Configure retention policy to recovery window of N days;

表示備份保留N天，即表示oracle可以保證還原到N天內的任意時間點。

CONFIGURE RETENTION POLICY TO REDUNDANCY n

表示備份保留N份。

區別就是基於恢復窗口的保留策略緯度不同，看你的具體需求 磁盤窨 備份策略 來選擇不同的參數設置

13、問：oracle數據庫的exp備份方式是否能否恢復存儲過程和觸發器？是否支持跨版本？RMAN方式呢？

答：

exp和expdp都能滿足你的需求 rman更能滿足。不過註意千萬不要在平時用exp來做容災備份 用rman來做 exp的定位還是數據遷移工具。

14、問：大家的Oracle備份環境中，是否建設有Catalog數據庫用於存放備份記錄啊？還是直接使用的控制文件？

在備份和恢復中，Catalog的主要優勢在哪？哪些是必要因素說明必須要建設Catalog數據庫？

答：

1.rman的備份信息默認是存放在目標數據庫的控制文件中的,存放時間由control_file_record_keep_time參數控制,默認是7天;同時,也可以把rman的備份信息保存到一個獨立的數據庫中,叫做recovery catalog;

2.使用recovery catalog可以保存更長時間的備份信息,當目標數據庫的控制文件丟失時非常有用;

3.recovery catalog可以保存多個目標數據庫的備份信息,可以保存RMAN stored scripts(類似於存儲過程,就是一系列rman腳本);另外如果想要試用永久保留備份的話,必須使用catalog;

4.如果只是簡單的備份管理需求的話,建議使用控制文件即可,因為如果使用recovery catalog的話,意味著還要對其它的數據庫做備份管理,Licence費用;所以,只有在使用recovery catalog帶來的好處比較大時才使用。

二、數據庫備份恢復性能相關問題

15、問：Oracle 強大之處之一在於有很多表和視圖用於性能分析和故障診斷，哪些表可以用於備份恢復異常時的性能診斷，有無經驗分享？

答：

select s.status as "備份狀態",

b.INPUT_TYPE as "備份類型",

to_char(b.START_TIME,‘yyyy-mm-dd hh24:mi:ss‘) as 總的開始時間,

to_char(b.end_time, ‘yyyy-mm-dd hh24:mi:ss‘) as 總的結束時間,

trunc(b.ELAPSED_SECONDS/60,0) as 耗時多少分鐘,

b.INPUT_BYTES_PER_SEC_DISPLAY "in_sec/s",

b.OUTPUT_BYTES_PER_SEC_DISPLAY "out_sec/s",

trunc((s.END_TIME-s.START_TIME)2460,0) "單個文件備份用時(分)",

to_char(s.START_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) as "開始備份時間",

to_char(s.END_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) as "結束備份時間",

s.OPERATION as "命令",

trunc(s.INPUT_BYTES/1024/1024,2) as "INPUT-M",

trunc(s.OUTPUT_BYTES/1024/1024,2) as "OUTPUT-M",

s.OBJECT_TYPE as "對象類型",

s.MBYTES_PROCESSED as "百分比",

s.OUTPUT_DEVICE_TYPE as "設備類型"

from v$rman_status s,v$rman_backup_job_details b

where to_char(s.START_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) < to_char(sysdate,‘yyyy-mm-dd hh24:mi:ss‘)

and to_char(s.END_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) > to_char(sysdate-7,‘yyyy-mm-dd hh24:mi:ss‘)

and s.COMMAND_ID=b.COMMAND_ID

order by s.START_TIME desc ;

select s.status as 備份狀態,

trunc((s.END_TIME-s.START_TIME)2460,0) "備份用時(分鐘)",

to_char(s.START_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) as 開始備份時間,

to_char(s.END_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) as 結束備份時間,

s.OPERATION as 命令,

trunc(s.INPUT_BYTES/1024/1024,2) as "INPUT/M",

trunc(s.OUTPUT_BYTES/1024/1024,2) as "OUTPUT/M",

s.OBJECT_TYPE as "對象類型",

s.MBYTES_PROCESSED as 百分比,

s.OUTPUT_DEVICE_TYPE as "設備類型"

from v$rman_status s

where to_char(s.START_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) < to_char(sysdate,‘yyyy-mm-dd hh24:mi:ss‘)

and to_char(s.END_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) > to_char(sysdate-7,‘yyyy-mm-dd hh24:mi:ss‘)

order by s.START_TIME desc ;

16、問：請問各位在生產環境中遇到哪些備份恢復的問題？

答：

源庫和恢復的目標庫 數據庫編碼格式不一樣，導致一直提示找不到bakcup piece。

備份時遇到壞塊

備份時文件被誤刪除

17、問：數據庫從9版本遷移到12c 數據表結構都變了，怎麽遷移數據呢？

答：

可以使用kettel等etl工具來幫忙，當然你也可以先升10再升11再升12 一步一步的升上去；同是oracle數據導出再導入也簡單。

三、數據庫備份恢復性能案例分析

18、問：oracle用rman做recover和用sqlplus做recover有什麽區別？

我曾經遇到過這樣一個問題，生產的存儲卡壞了（生產是2個節點的ＲＡＣ），需要在另一臺服務器恢復數據庫（非ＲＡＣ），幸好我把歸檔日誌保存了一份在本地磁盤。在還原旱，用 rman 做 restore 正常完成，但在做 recover 的時候，報錯了（具體的錯誤號我忘了，但大概意思是找不到所需要的歸檔日誌，但在新的服務器上的歸檔路徑下有這歸檔日誌文件），整了半天，就是不得行，後來，我用　sqlplus recover 成功了，命令如下：
sql> recover database using backup controlfile until cancel;

為什麽為這樣，我至今沒有搞明白，請高手們分析一下。

答：

如果你的oracle rman恢復是沒有catalog，且在rman中的恢復僅僅是“recover database”的話，會出現你說的這個問題。

要想明白問題的原因，還得從這兩句恢復命令出發：

recover database using backup controlfile until cancel;

在單一的recover database 或者 recover tablespace, recover datafile時，Oracle會以當前controlfile所記錄的SCN為準，利用archive log和 redo log的redo entry, 把相關的datafile 的 block恢復到“當前controlfile所紀錄的SCN”
而當前controlfile和current/active redo都丟失的情況下，你就需要使用你在SQLPLUS裏輸入的那句恢復命令，在很多情況下，由於datafile數據的不一致性，Oracle需要把數據恢復到比當前controlfile所紀錄的SCN還要靠後的位置，簡單的說，就是需要更多的歸檔。

如果你還能復現這個恢復場景，你查詢下你報錯的所需的歸檔，利用原來的controlfile進rman裏list backup看一下就能知道了。

四、數據庫備份恢復性能優化問題

19、問：隨著數據庫體量的增大，有時每天全備已經不能滿足需要了，考慮使用增量備份。各位專家有沒有遇到過實施增量備份過程中的問題呢？還有就是對於OLTP系統，每天大量數據塊是被更新了的，這樣的話block change tracking即使打開了，也很難提高備份速度（因為大部分塊都被修改過，仍然需要備份），這類問題同行朋友有沒有比較好的建議？

答：

首先確認一下數據庫大小有多大，使用的lan備份還是光纖，使用的幾個通道，平均一個通道io有多大？如果使用的lan 是否網卡已經飽和等等？
如果你的狀況是每天變化的數據能影響到幾乎所有的數據塊的話，那麽考慮使用backup as copy。

五、數據庫備份恢復RAC相關問題

20、問：Oracle 10gr2 RAC因為需要更換存儲，數據庫遷移有什麽特別的方案嗎？系統Oracle Linux 5.7，DB：10.2.0.5。

答：

具體看停機窗口時間跟數據量，可以采用集中方式：1）導入導出；2）備份恢復；3）使用新的存儲做一個DG的備機，然後切換過去。

21、問：現有數據庫為oracle rac，想搭建一套完全實時互備的數據庫，能做DataGuard嗎？如果可以那麽scanip 和VIP、sid和原庫能保持一致嗎？如不行那麽有什麽能實現以上功能？

答：

完全可以在現有環境下搭建adg。

scanip，VIP，sid都不能一致，但是數據庫唯一名必須一致，這是adg的配置條件。

22、問：一個oracle數據庫的RAC環境，在日常運維管理中應重點關註那些方面的具體內容？

在對oracle數據庫進行日常運維管理中，我們都應該重點關註那些方面的具體內容？

我們目前能夠關註的，如：ORA-告警信息，一些表空間的的告警。這個也是主要從監控系統（如TIVOLI監控系統）中獲得，除此之外，我們還應該重點關註那些具體方面的內容?

答：

除了監控，也需要關註RAC環境的性能調優，Service的管理，負載均衡等方面吧

23、問：如果Orace數據庫的RAC在建設的時候，歸檔沒有放在共享或者ASM上，只是在單邊存放，那麽這種的Oracle數據庫備份大家一般都怎麽做？兩邊都備份？還是mount NFS？哪種更好些？

答：

歸檔還是建議放在共享存儲上，不太建議單邊存放。一是方便管理，二是簡化備份流程。

若是單邊存放，只能在每個節點上單獨備份各自的歸檔。

對於歸檔數據量較大的場景，不太建議NFS。如果允許，能共享盡量共享

六、數據庫備份恢復經驗分享

（一）、Oracle 備份和恢復的一點體會

架構

Oracle的備份一般來說還是基於第三方備份軟件來完成日常備份的，諸如NBU，TSM等

那麽在設計架構方面應該多考慮一下是集中的方式來做還是分開來做，主要考慮有幾點：

1.公司需要備份的節點數量和位置

2.目前公司網絡情況（是否有分支機構走專線備份，備份網段和生產網段的連通性等，是否有專用備份網絡）

3.是否使用catalog

4.備份設備是否分層或異地同步

5.是否有出庫異地存放需求。

數據量

1.數據量小，基本上可以考慮使用lan方式配合備份窗口來完成

2.數據量大，考慮配合高速以太網和lanfree方式完成，備份方式（全備+曾備+歸檔備份完成）

配置

1.選用較高配置X86 服務器+linux 完成備份環境搭建

2.備份server和節點session和資源限制不要使用默認，看情況修改

3.Oracle 備份片和通道要做適當設置

4.專有備份lan或光纖卡

性能定位

1.本地io

2.網絡io

3.備份軟件兼容性，已經版本bug

4.備份軟件trace跟蹤

5.oracle備份參數設置：備份片和備份方式，是否壓縮，塊跟蹤等

（二）、結合實際做備份恢復設計才能最大限度的滿意要求

備份恢復的方法和種類很多，為啥有的時候客戶還不滿意？因為你不對他路子。

舉個例子，開發人員不小心刪錯了數據。你說有flash back呀一看undo retention不夠。

那開始備份恢復吧，結果system或者user表空間巨大，哇數據全在system裏面是不是原來設計好的想法都沒用啦?

如果可以依照先有的數據庫結構做些適當的引導那麽會好很多。

且國內客戶和國外客戶處理的方式太不一樣。特別是韓國和日本客戶。針對細節問題到了無以復加的地步，那麽這個時候備份和恢復設計就不能有自己解釋不通的地方。

說了那麽多具體談下怎麽做事吧。

最重要的一點，備份的東西可以吐出來。

那麽要給自己留後路，備份的東西要異與恢復。

那麽如果錢足，上硬件級別備份。例如emc timefinder，SRDF等等。條件好的可以做個備份的colne。

一定要建議購買專業的備份恢復軟件，關鍵時刻可以用來頂包。

那麽最好做物理備份，用於防止物理的損壞。

如果既要防止物理損壞又要很快的把人為的錯誤數據找回來就可以設置一個standby那麽防止物理損壞的備份直接在原庫備份，用於防止人為損壞的備份在standby節點備份，延時個一天吧。應該可以滿足要求。

以上是大致的經驗，我的意思是備份手段多種多樣，怎麽搞成最適合的場景可是個大學問。

（三）、Oracle 11.2.0.3版本以上的RAC數據庫備份時，偶爾出現ORA-00245的報錯。

問題現象：ORA-00245: control file backup failed; target is likely on a local file system

解決辦法：

1. Check the snapshot controlfile location:
RMAN> show snapshot controlfile name;

2. Configure the snapshot controlfile to a shared disk:

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/snapcf_.f‘;
Or in case of ASM use

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘+/snapcf_.f‘;

Oracle數據庫備份、災備的23個常見問題