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

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

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

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

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

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

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

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

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

 

 

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，多路複用關閉。

 

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

答：

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

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

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

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

答：

先說備份，須要着重考慮幾點：

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

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

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

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

恢復通常在單獨的恢復環境，因此沒什麼須要特別注意的。

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

答：

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

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

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

答：

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

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

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

答：

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

若是要使用備份等話，那就建議保留全部的歸檔日誌，除了備份恢復，還可使用Oracle數據庫的閃回功能，好比：閃回查詢，閃回表，閃回事務和閃回數據庫等操做。

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

答：

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

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

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

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

八、問：針對不一樣業務系統採用的數據庫備份策略是怎麼樣的？按期恢復驗證的週期爲多久？

答：

備份方式無外乎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。

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

答：

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

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

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

答：

Oracle Rman沒法實現分用戶備份，但能夠折中處理：備份用戶對應的全部表空間數據。

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

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

答：

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

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

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

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

答：

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

Configure retention policy to recovery window of N days;

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

CONFIGURE RETENTION POLICY TO REDUNDANCY n

表示備份保留N份。

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

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

答：

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

1四、問：你們的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帶來的好處比較大時才使用。

 

 

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

 

1五、問：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 ;

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

答：

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

備份時遇到壞塊

備份時文件被誤刪除

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

答：

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

 

 

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

 

1八、問：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看一下就能知道了。

 

 

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

 

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

答：

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

 

 

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

 

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

答：

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

2一、問：現有數據庫爲oracle rac，想搭建一套徹底實時互備的數據庫，能作DataGuard嗎？若是能夠那麼scanip 和VIP、sid和原庫能保持一致嗎？如不行那麼有什麼能實現以上功能？

答：

徹底能夠在現有環境下搭建adg。

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

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

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

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

答：

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

2三、問：若是Orace數據庫的RAC在建設的時候，歸檔沒有放在共享或者ASM上，只是在單邊存放，那麼這種的Oracle數據庫備份你們通常都怎麼作？兩邊都備份？仍是mount NFS？哪一種更好些？

答：

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

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

對於歸檔數據量較大的場景，不太建議NFS。若是容許，能共享盡可能共享

 

 

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

 

（一）、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';