簡介面向Oracle DBA與備份運維人員這份NetBackup環(huán)境下的Oracle數(shù)據(jù)庫備份配置文檔完整覆蓋從客戶端代理安裝、主服務器策略創(chuàng)建到RMAN腳本定制與備份任務執(zhí)行的全流程。文檔以實際操作步驟為主線先說明在Linux/Unix Oracle主機上選擇合適的CLIENTS2安裝包并提示安裝時輸入主服務器與媒體服務器信息、token粘貼后不顯示的易錯細節(jié)隨后講解在主服務器新建策略時將類型設為Oracle、存儲選擇對應媒體服務器并配置調度計劃與‘用于腳本的客戶端’同時強調hosts文件、1556與13724端口互通等前提條件。針對RMAN腳本文檔展開hot_database_backup.sh中的環(huán)境變量與參數(shù)調整包括備份類型、標簽保留策略、壓縮與加密等關鍵配置幫助讀者理解熱備份機制。資源為1個docx格式文檔壓縮包約5.9MB內容精煉集中目前已有836人學習。讀者可參照完成Oracle客戶端代理安裝、備份計劃配置、腳本修改與備份執(zhí)行獲得一套可直接落地的備份配置參考。1. NBU備份oracle到底在解決什么問題凌晨手機被 DBA 群里的告警電話炸醒剛接手的一臺 Oracle 19c 生產庫因為磁盤陣列故障直接宕了。你趕緊打開 NetBackup 管理控制臺發(fā)現(xiàn)昨天剛跑完的全量備份顯示“成功”可當你準備用這臺 NBU 的備份數(shù)據(jù)去恢復數(shù)據(jù)庫時卻驚訝地發(fā)現(xiàn)最近幾天的歸檔日志都沒備份進去數(shù)據(jù)只能恢復到一周前。這種場景在備份運維里太常見了。NBU備份oracle詳細配置文檔這個標題背后真正要解決的問題不是教你學會敲幾條 RMAN 命令而是怎么用 Veritas NetBackup 這個中央調度平臺把 Oracle 數(shù)據(jù)文件、歸檔日志、控制文件以及恢復驗證串成一條可靠的流水線。它適合那些被備份任務折磨的 DBA、負責容災的備份管理員以及第一次接觸企業(yè)級備份軟件的運維新人。折騰明白這套配置你的備份才算真正具備恢復能力而不只是一堆躺在磁帶和磁盤上的黑匣子。2. 把 NBU 和 Oracle 接起來基礎架構與集成原理2.1 備份鏈路中的三個角色Master Server、Media Server、ClientNBU 備份 Open 文件系統(tǒng)時鏈路相對簡單但備份 Oracle 數(shù)據(jù)庫時必須要分清三個角色的職責理解數(shù)據(jù)流量是從哪邊推到哪邊的。Master Server是整個 NBU 域的大腦。它上面存放著 EMMEnterprise Media Manager數(shù)據(jù)庫所有備份策略、調度計劃、保留期限以及備份作業(yè)的啟動都歸它管。你打開 NBU 管理控制臺看到的“活動作業(yè)”和“備份策略”都是從 Master Server 上拉取和提交的。Media Server是數(shù)據(jù)流的搬運工。它實際連接磁帶庫、DataDomain 去重存儲或普通的磁盤存儲單元通過bptm進程接收來自客戶端的備份數(shù)據(jù)流。Client就是裝在 Oracle 主機上的代理。在 Oracle 場景下它不只是 NBU 的文件系統(tǒng)客戶端還裝了 NetBackup for Oracle 的智能策略插件。明確這三個角色對后續(xù)配置至關重要。因為 Oracle 備份總是出現(xiàn)“作業(yè)顯示成功但實際備份不完整”的尷尬根源往往就是數(shù)據(jù)流經過了 Media Server 時超時但 Master Server 沒收到明確的錯誤碼最后把作業(yè)拉成了成功的狀態(tài)。NBU 10.4 的界面雖然越來越漂亮但核心的數(shù)據(jù)流構架沒有變依然是 Master Server 基于服務的模式向 Client 下發(fā)備份任務Client 再通過 SBT 接口把數(shù)據(jù)交給 Media Server。所以排查故障時先要想清楚你現(xiàn)在看到的日志是 Master Server 的作業(yè)日志還是 Media Server 的驅動日志還是 Oracle 端 RMAN 的輸出日志。這三者信息完全不一樣混著看容易把自己繞進去。2.2 不要繞開的兩種集成方式RMAN 插件與客戶端腳本要把 NBU 和 Oracle 拉起手來官方層面有兩條主流路徑。第一種是NBU 的 Oracle 智能策略Smart Policy。你在 NBU 控制臺創(chuàng)建備份策略時“策略類型”選擇Oracle然后直接在這個界面里指定要備份的數(shù)據(jù)庫、備份方式全備份、增量備份或僅歸檔日志。NBU 會自動在后臺生成一套 RMAN 命令并調用 NetBackup for Oracle 的插件去執(zhí)行。這種方式的好處是備份信息與 NBU 的目錄庫深度綁定可以自動實現(xiàn)基于時間點的恢復粒度控制在做“Instant Recovery”或“裸文件恢復”時最省事。第二種是標準備份腳本方式Standard Policy。這種策略類型選擇Standard然后把“備份命令行”寫成一個 Shell 腳本腳本里自定義 RMAN 的完整執(zhí)行邏輯。它本質上是 NBU 只負責定時拉起這個腳本至于腳本里 RMAN 是調用 SBT 通道還是把備份寫到本地的普通文件NBU 都不關心。這種方式在 DBA 群體里非常流行因為腳本可以用到很多 RMAN 的高級特性比如過濾特定表空間、指定備份片段大小、跳過離線數(shù)據(jù)文件靈活性更高。如果你問我哪種更推薦我的建議是生產環(huán)境如果業(yè)務要求快速接管直接上智能策略如果 DBA 團隊對備份粒度控制有執(zhí)念且對 RMAN 異常參數(shù)十分敏感那就用標準腳本策略腳本本身就是你的后悔藥。但不管你選哪種底層都必須依賴 Oracle 的介質管理層MML庫。NBU 到 Oracle 的橋接就是那個位于$ORACLE_HOME/lib下的libobk.so文件它能被 RMAN 識別成TYPE SBT_TAPE通道本質上相當于把 NBU 的存儲單元偽裝成了一臺無限容量的磁帶機。2.3 安裝 NetBackup 客戶端與 Oracle 代理不要默認路徑的坑安裝 NBU 客戶端的過程本身沒什么難度執(zhí)行./install然后一路默認到底但這正是后面各種疑難雜癥的源頭。安裝完 NetBackup Client 后你還需要單獨安裝 NetBackup for Oracle 的擴展包。這個擴展包非常重要否則策略類型選 Oracle 時系統(tǒng)會提示你“客戶端不支持該應用”。裝完以后最關鍵的環(huán)節(jié)不是看安裝成功而是確認 NBU 的服務進程能不能讀到ORACLE_HOME環(huán)境變量。因為 NBU 的客戶端服務bpbkar接管 Oracle 備份時需要向外部的bptm進程匯報數(shù)據(jù)庫審計日志的路徑這個路徑默認從ORACLE_HOME拼接出來。如果 NBU 服務時沒有把ORACLE_HOME寫進它的守護進程環(huán)境里經常會出現(xiàn)備份數(shù)據(jù)庫文件完全可以但備份完 ORACLE 歸檔日志時立馬報錯ORA-19511。這里有一個笨但絕對有效的做法在備份主機的/usr/openv/netbackup/bp.conf文件末尾手動補一條靜態(tài)配置項明確指定 Oracle 環(huán)境。# /usr/openv/netbackup/bp.conf 文件部分內容 SERVER nbumaster.localdomain CLIENT_NAME oracle19c.localdomain # 手動增加 Oracle 專用的環(huán)境變量避免 bpbkar 進程找不到 Oracle 依賴 ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1 ORACLE_SID ORCL這段配置邏輯很直接。SERVER用于告訴 NBU 客戶端哪個 Master Server 可以給他派發(fā)任務CLIENT_NAME要嚴格和 NBU 控制臺里添加主機時填的名稱一致不能因為改過主機名就忽略不同步的問題。而ORACLE_HOME寫在bp.conf里是業(yè)內最穩(wěn)妥的方式因為它能保證 NBU 服務進程無論由哪個用戶重啟都能通過文件解析找到數(shù)據(jù)庫的庫路徑。千萬不要指望服務器重啟后/etc/profile里的環(huán)境變量能順順利利被 NBU 的守護進程讀到那個是純看系統(tǒng)運氣屬于玄學范疇。補完配置記得重啟netbackup客戶端服務然后執(zhí)行下面的命令驗證 Master Server 和 Client 之間的信任是否打通。/usr/openv/netbackup/bin/bptestbpcd -client oracle19c.localdomain -verbose輸出如果顯示Status: OK則說明 NBU 客戶端能在 Master Server 的控制下發(fā)號施令了。這個bptestbpcd命令是 NBU 客戶端注冊后必測的一道防線它驗證的是主機間的 BPCD 端口是否可達屬于純網(wǎng)絡層面的握手一旦失敗后面配置策略基本就是玩瞎。3. 從環(huán)境檢查到策略落地NBU備份Oracle配置實操3.1 預備工作先檢查數(shù)據(jù)庫與 RMAN 的狀態(tài)配置 NBU 策略之前不要在 GUI 里急著點下一步。先把數(shù)據(jù)庫的底層狀態(tài)摸清否則備份任務即使啟動了也是帶病運轉。你需要登到 Oracle 主機上用sqlplus檢查幾個硬指標。-- 檢查數(shù)據(jù)庫歸檔模式、閃回恢復區(qū)大小以及當前日志切換頻率 SELECT log_mode, flashback_on FROM v$database; -- 查看閃回恢復區(qū)當前已使用空間和總大小 SELECT name, round(space_limit/1024/1024/1024, 2) SIZE_GB, round(space_used/1024/1024/1024, 2) USED_GB FROM v$recovery_file_dest; -- 查看當前在線日志組的狀態(tài)和大小 SELECT group#, sequence#, status, bytes/1024/1024 MB FROM v$log ORDER BY group#;這幾條 SQL 的作用很明確。log_mode必須為ARCHIVELOG否則無法實現(xiàn)基于時間點的恢復閃回恢復區(qū)Fast Recovery AreaFRA的大小直接決定了歸檔日志在本地最多能攢多少。我曾經遇到過生產庫db_recovery_file_dest_size只配了 50GB而每小時日志量 20GB 的場景等于 FRA 每兩個半小時就被寫滿數(shù)據(jù)庫直接 hang 住這種情況下 NBU 即便再勤快也架不住源端不斷井噴的日志量。除了數(shù)據(jù)庫本身還要檢查rman的配置項。備份時那些靈異的時間點恢復失敗大多是因為RMAN的冗余策略或者控制文件自動備份被設置成了異常值。下面這組查看命令是必做的功課。rman target / RMAN SHOW ALL;SHOW ALL的輸出里重點盯著CONFIGURE RETENTION POLICY、CONFIGURE CONTROLFILE AUTOBACKUP以及CONFIGURE ARCHIVELOG DELETION POLICY這三行。不需要過度修改但要心里有數(shù)。強烈建議把CONFIGURE CONTROLFILE AUTOBACKUP ON;打開因為控制文件是恢復的命根子在 NBU 這種介質管理場景下如果控制文件丟失且沒有 autobackup恢復時就得手工指定文件名那是在給自己挖坑。3.2 寫一個能直接調用的 RMAN 備份腳本配置 NBU 策略時最常見的落地方式是“標準策略外部腳本”因為這種方式最方便 DBA 手工在命令行同樣執(zhí)行一遍測試與排錯成本最低。下面是我自己的生產環(huán)境里用得極其順手的備份腳本模板。#!/bin/bash # 文件名: /home/oracle/scripts/nbu_oracle_backup.sh # 說明: 該腳本由 NBU 標準策略觸發(fā)也可由 DBA 在 crontab 中手工調用 export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export ORACLE_SIDORCL export NLS_DATE_FORMATYYYY-MM-DD HH24:MI:SS export NBU_CLIENThostname -s # 定義 RMAN 日志輸出路徑 BK_LOG/home/oracle/scripts/log/rman_full_date %Y%m%d_%H%M%S.log # 調用 rman 對數(shù)據(jù)庫執(zhí)行全量備份和歸檔日志備份 $ORACLE_HOME/bin/rman target / log $BK_LOG EOF STARTUP MOUNT; RUN { # 分配兩條 SBT 通道對應 NBU 策略里的并行流數(shù) ALLOCATE CHANNEL ch1 DEVICE TYPE SBT_TAPE; ALLOCATE CHANNEL ch2 DEVICE TYPE SBT_TAPE; # 全量備份數(shù)據(jù)庫文件并備份所有歸檔日志同時刪除已備份過的歸檔日志 BACKUP DATABASE PLUS ARCHIVELOG FORMAT %U DELETE INPUT; RELEASE CHANNEL ch1; RELEASE CHANNEL ch2; } ALTER DATABASE OPEN; EXIT; EOF # 判斷備份結果失敗則退出并返回非 0 值 if [ $? -ne 0 ]; then echo Oracle NBU backup failed at date $BK_LOG exit 1 fi exit 0這段腳本里有兩個參數(shù)至關重要。一是ALLOCATE CHANNEL的條數(shù)它決定了備份數(shù)據(jù)流最終分裂成幾股必須和 NBU 策略中的“最大并行流數(shù)”完全匹配。二是DELETE INPUT它的存在與否直接關系到源端 FRA 的空間是否會被殘留歸檔日志打爆。執(zhí)行BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT時RMAN 會先備份數(shù)據(jù)文件再備份歸檔日志最后把備份過的日志從源庫刪除掉相當于“卸貨完成后再清空貨架”。腳本還有個隱藏的關鍵點STARTUP MOUNT和ALTER DATABASE OPEN必須成對出現(xiàn)。因為在備份期間讓數(shù)據(jù)庫保持 MOUNT 狀態(tài)能保證無日志寫入同時避免END BACKUP不一致的情況。如果你不敢把生產庫拉成 MOUNT 狀態(tài)也可以直接使用BACKUP DATABASERMAN 會自動處理在線數(shù)據(jù)文件的一致性但那樣的話日志切換會非常頻繁FRA 壓力陡增。對于 NBU 這種介質管理工具除非業(yè)務無法接受任何停機窗口否則我從來都堅持 MOUNT 備份。3.3 創(chuàng)建 NBU Policy備份策略的十個關鍵參數(shù)腳本準備完畢后打開 NBU 管理控制臺進入Policies新建一個策略。策略創(chuàng)建頁面的參數(shù)很多新手經常一頭扎進去亂填這里把最關鍵的十個參數(shù)拎出來直接照著抄作業(yè)就可以。策略類型與客戶端參數(shù)推薦取值說明Policy typeOracle如果選了 StandardNBU 就只把腳本當普通文件執(zhí)行安裝 Oracle Agent 的意義就沒了Clientoracle19c.localdomain必須與 bp.conf 里的 CLIENT_NAME 一致否則作業(yè)在調度時會直接失敗Storage unitMSDP 或 DataDomain_01決定備份數(shù)據(jù)寫到哪套存儲池直接關系到恢復時的讀取速度備份內容與調度參數(shù)推薦取值說明Backup Selection指向腳本的絕對路徑標準策略下這里填/home/oracle/scripts/nbu_oracle_backup.shSchedule全備每周六 02:00歸檔日志每 1 小時歸檔備份策略要與 Oracle 的日志產生速率匹配寧可過密不可過稀Retention14 天如果生產要求恢復到一個月內任意點14 天絕對不夠用至少 31 天起性能與通道參數(shù)推薦取值說明Performance等同于腳本里 channel 數(shù)比如腳本里分配了 2 條通道這里最大并行流數(shù)設為 2如果設大了NBU 只會多開好幾個 Master Server 進程空等毫無意義Active Server默認 Media Server若多臺 Media Server選離 Oracle 主機網(wǎng)絡延遲最小的一臺Compression選擇程序自動判斷Oracle 的數(shù)據(jù)塊本身壓縮率有限NBU 的客戶端壓縮如果對高并發(fā)業(yè)務啟用極其消耗 CPU容易形成瓶頸Multistreaming開啟并設為 2對應 RMAN 通道開啟后 NBU 會把備份集打成多個流有效提高單表空間備份并發(fā)度Job priority5若與其他業(yè)務系統(tǒng)搶窗口調高 Oracle 備份的優(yōu)先級避免被文件備份擠掉這些參數(shù)設置完畢后還有一道非常關鍵的步驟在Clients標簽下的主機列表里把oracle19c.localdomain加進來并激活策略。激活后NBU 會在下一個調度點自動拉起任務。如果你想立刻驗收可以右鍵策略選擇Manual Backup然后回到 Activity Monitor 盯一次作業(yè)的全過程。4. 場景細化RAC、ASM、DataGuard 下 NBU 備份的差異化配置4.1 為 Oracle RAC 與 ASM 設計備份策略生產環(huán)境絕大多數(shù)高可用數(shù)據(jù)庫都是 RAC 架構。RAC 環(huán)境下給 NBU 配策略最大的變化在于Client不再是一個單點主機而是一組節(jié)點。備份接口的選擇也更有講究。傳統(tǒng)方式要求你指定一個主節(jié)點作為備份源其他節(jié)點作為輔助節(jié)點但這種方式在 NBU 10.4 中有更優(yōu)雅的解就是走“集群客戶端”模式。配置 RAC 的 NBU 客戶端時建議在每個節(jié)點上都安裝 NetBackup Client 和 NetBackup for Oracle 插件然后在 NBU 管理控制臺為所有節(jié)點建一個集群實體這樣備份策略就可以統(tǒng)一調度RMAN 會自動在可用節(jié)點間做負載均衡。注意這里的 RMAN 通道分配要寫成CONNECT形式明確指定節(jié)點實例否則 RMAN 可能隨機挑一個節(jié)點導致備份數(shù)據(jù)流都擠在同一臺機器上。# 在 rman 腳本中指定通道連接 RAC 節(jié)點示例 RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE SBT_TAPE CONNECT sys/密碼rac1; ALLOCATE CHANNEL ch2 DEVICE TYPE SBT_TAPE CONNECT sys/密碼rac2; BACKUP DATABASE PLUS ARCHIVELOG FORMAT %U DELETE INPUT; }在 ASM 環(huán)境下RMAN 備份無需關心 ASM 磁盤組內部結構。備份數(shù)據(jù)文件時RMAN 直接通過 ASM 實例讀取數(shù)據(jù)塊再經 SBT 通道交由 NBU 寫入介質。但有一個極容易踩的坑在 RAC 備份中CONFIGURE CHANNEL如果指定了CONNECT必須顯式指定 ASM 實例否則會報ORA-15032。同時你有必要為 ASM 啟用CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE SBT_TAPE這樣即使數(shù)據(jù)庫控制文件所在磁盤組發(fā)生物理損壞也能通過最后一條自動備份集恢復控制文件。4.2 把備份負荷轉移到 Data Guard 備庫如果你手頭有一套 Data Guard 環(huán)境尤其近年來大家都在把“真實應用集群”和“災備”做融合那種“主庫跑業(yè)務、備庫做備份”的架構在運維圈越來越吃香。利用 NBU 在備庫上拉一份全備既能徹底釋放主庫 I/O又能避免主庫的MTTR因為備份而變得不穩(wěn)定。配置備庫備份時有幾個前置條件備庫處于MOUNTED或OPEN READ ONLY狀態(tài)均可但必須開啟閃回恢復區(qū)且備庫數(shù)據(jù)庫到主庫的日志傳輸一定要順暢。否則備庫的歸檔日志不連續(xù)即使備份成功恢復到那個時間點也會缺后面的數(shù)據(jù)。另外在備庫上做BACKUP DATABASE時需要額外注意因為備庫的數(shù)據(jù)庫 scn 與主庫保持一致但備份出來的控制文件無法直接用于還原主庫在恢復時要用DB_FILE_NAME_CONVERT去映射文件路徑。如果主備庫路徑不一致而你的數(shù)據(jù)庫又是 ASM 管理的這一步沒處理好恢復時間會延后數(shù)小時。我個人在實際操作中一般會在策略里單獨建一個“歸檔日志備份”的任務專門針對備庫的歸檔目錄執(zhí)行。這樣主庫的歸檔日志傳輸?shù)絺鋷旌驨BU 會優(yōu)先將備庫的日志備份到存儲中隨后再清理備庫的歸檔文件相當于在備庫側完成日志的二次容災對主庫完全沒有影響。這種“xcopy”式的精細化編排是 NBU 配電高級運維最典型的一個體現(xiàn)。4.3 多通道機制與并發(fā)控制參數(shù)精講通道數(shù)是一個看似簡單的參數(shù)卻藏了很多翻車點。很多人為了追求速度把 RMAN 通道數(shù)和 NBU 的并行流數(shù)一次性拉到 16結果備份時間確實縮短了但數(shù)據(jù)庫所在主機的 CPU 直接被打滿正常的業(yè)務查詢瞬間卡死導致故障雪崩。常規(guī)的經驗法則是生產庫按 CPU 核數(shù)來定通道數(shù)。如果主機是 8 核 16 線程建議 RMAN 通道數(shù)設 4NBU 策略中的最大并行流數(shù)同樣設為 4。如果使用 DataDomain 等存儲設備單通道帶寬上限通常為 200MB/s4 通道上行可以達到 800MB/s這已經能撐起大部分業(yè)務環(huán)境的備份窗口了。對于超過 2TB 的大庫可以考慮把BACKUP拆成多段BACKUP DATABASE SECTION SIZE每段 8GB 左右讓 RMAN 以數(shù)據(jù)文件為單位分段備份這樣也能避免一個超大表空間備份時長時間霸占單通道。需要特別指出的是在 NBU 的 Media Server 層面還需要檢查它允許同時掛載的磁帶驅動器或數(shù)據(jù)流數(shù)量。如果是虛擬磁帶庫或DataDomain這個限制一般很高如果是物理帶庫驅動器數(shù)量就是你硬件的上限超額后作業(yè)會在Media request狀態(tài)卡住很久。5. 排查與避坑NBU備份Oracle翻車現(xiàn)場實錄5.1 備份作業(yè)顯示成功但 RMAN 里查不到備份集現(xiàn)象NBU 控制臺里作業(yè)狀態(tài)顯示“成功”可你想在恢復窗口里RMAN LIST BACKUP SUMMARY;時卻發(fā)現(xiàn)一片空白或者只有幾條無關緊要的片段。原因這種表面繁榮十有八九是策略類型選錯了。如果你在 NBU 策略類型里誤選了Standard而腳本內部執(zhí)行 RMAN 時又沒有指定DEVICE TYPE SBT_TAPE那備份作業(yè)實際上只是備份了一個普通的文件系統(tǒng)目錄完全沒有走 NBU 的介質管理。NBU 的成功只是針對“文件收集成功”而不是“數(shù)據(jù)庫備份成功”。解決遇到這種誤配置不用慌。先把 NBU 策略類型改為Oracle再在Backup Selection里明確填上RMAN腳本路徑或者直接對RMAN腳本的執(zhí)行方式做調整。另外最直接的驗證手段是在 RMAN 里執(zhí)行一次BACKUP DATABASE VALIDATE命令它會檢查介質管理層的接口能不能被正確加載。這條命令如果返回ORA-19511說明libobk.so沒被 RMAN 找到那重點就得去檢查$ORACLE_HOME/lib和 NBU 客戶端的安裝目錄的軟鏈了。5.2 “rman備份老是滿”的日志增長困局現(xiàn)象Oracle 告警日志里頻繁提示 “WARNING: Recycle Bin is full” 或者磁盤剩余空間不足經常是閃回恢復區(qū)爆掉數(shù)據(jù)庫直接自動掛起。而你在 NBU 側看歸檔日志備份調度卻很奇怪地發(fā)現(xiàn)歸檔日志策略很勤懇就是總差最后一口“深呼吸”的空間。原因這背后往往是一個經典的設計沖突Oracle 的ARCHIVELOG DELETION POLICY設置成了NONE或者沒有和 NBU 的備份策略配合。也就是說FRA 里的歸檔日志不管備份到沒備份到 NBU都被 Oracle 當作可無條件清理的對象于是 NBU 還沒讀完日志Oracle 自己就把源文件刪了亦或是反了過來NBU 備份后沒有DELETE INPUTOracle 沒收到刪除指令于是 FRA 一直在堆積歷史日志直到被寫滿。解決解決思路很清晰。在 Oracle 側設置一個基于備份刪除策略的源頭約束讓 Oracle 只有在 NBU 確認接收后才清理日志。RMAN CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DEVICE TYPE SBT_TAPE;執(zhí)行這條配置后Oracle 必須確認歸檔日志在SBT_TAPE上至少成功備份過一次才允許把源端的歸檔文件標記為可復用。配合 NBU 歸檔日志策略里的DELETE INPUT雙管齊下閃回恢復區(qū)的空間就能進入一種“備份多少刪多少”的穩(wěn)態(tài)循環(huán)你去查盤的時候它永遠保持在 70% 以下再也不用半夜爬起來手動刪歸檔了。5.3 NBU 存儲單元寫入慢RMAN 會話直接卡死現(xiàn)象Oracle 備份作業(yè)的 RMAN 日志停在某個百分比不再輸出數(shù)據(jù)庫上的會話數(shù)卻異常飆升DBA 看到 RAC 節(jié)點 CPU 全紅業(yè)務查詢耗時從 200ms 變成 20s。你殺死過幾次 RMAN 進程發(fā)現(xiàn)每次都在同一個位置卡住。原因問題不一定出在 Oracle 端極大概率在 NBU 存儲單元的寫入側。若是物理帶庫大概率是驅動器被其它備份任務占滿了導致當前 RMAN 的 SBT 通道一直處在等待 tape 資源狀態(tài)若是 DataDomain 或磁盤存儲單元則觀察 Media Server 的 CPU可能是后端去重進程的吞吐量達到瓶頸同時有大量客戶端任務在同時擠兌形成 IO 長尾效應。解決先檢查 NBU 的作業(yè)活動監(jiān)控看同一時間段有幾個備份策略在并發(fā)搶占同一個存儲池。建議給 Oracle 備份單獨劃一個存儲單元或磁盤池限制其它文件系統(tǒng)備份不要搶占它的帶寬。同時降低 RMAN 通道數(shù)減少并發(fā)對存儲的壓力。如果確定是 Media Server 的硬件瓶頸就只能增加節(jié)點或遷移去重存儲。在 NBU 里調整存儲單元優(yōu)先級是一個立竿見影的手段把 Oracle 備份的優(yōu)先級調最高文件備份的任務會在調度時自動被排在后面保證關鍵數(shù)據(jù)庫的備份不被積壓。5.4 備份成功卻恢復失敗日志文件與控制文件的坑現(xiàn)象發(fā)生故障真正要用 NBU 備份恢復時發(fā)現(xiàn)使用RESTORE DATABASE總是報缺少歸檔日志或者恢復出來的數(shù)據(jù)庫在打開時報ORA-01547控制文件不一致。原因這個場景我在很多客戶那里都看到過。事件主因是在 NBU 的全量備份策略里沒有包含控制文件或者 RMAN 腳本中沒有開啟INCLUDE CURRENT CONTROLFILE。很多朋友以為 NBU 代理會自動把控制文件作為元數(shù)據(jù)保護但實際上NBU 只保護它接收到的數(shù)據(jù)流控制文件必須顯式加入備份。如果你走的是自定義腳本并且使用了BACKUP DATABASE PLUS ARCHIVELOG而沒有控制文件恢復時自然缺了關鍵的引擎。解決在 RMAN 的備份命令中強制添加控制文件備份BACKUP CURRENT CONTROLFILE FORMAT %U;同時在 NBU 的恢復測試中用BPLIST或NBU 恢復向導檢查恢復點是否能包含控制文件。建議在測試恢復時使用RESTORE CONTROLFILE去驗證是否可讀不要等到生產故障時才發(fā)現(xiàn)“最后一根稻草”根本不在備份集里。控制文件就是那個最后后悔藥它平時不起眼缺了它整個恢復流程就癱瘓。5.5 NBU 備份狀態(tài)正常但異地災備拿不到數(shù)據(jù)現(xiàn)象生產機房的備份作業(yè)每天執(zhí)行成功但你登錄異地機房的 NBU 域或者在災備中心的 Master Server 上用bpdbjobs查看卻連一條任務記錄都看不到。原因跨域傳輸配置缺失。很多企業(yè)的生產 NBU 和災備 NBU 是兩套獨立的域。生產端 Master Server 的備份只停留在本地存儲災備端希望定時拉取生產端的數(shù)據(jù)鏡像但是你沒有在 NBU 中配置“遠程復制”或 Vault 策略更常見的是配置了 SLPStorage Lifecycle Policy但目標存儲單元的寫權限沒給災備域的用戶。解決這種場景先不要急著懷疑網(wǎng)絡先在災備 NBU 的存儲單元中檢閱連接生產 Master Server 的“遠程存儲單元”的授權主機列表手動執(zhí)行一次bpcreatesv看看兩側的通信是否正常。如果確認通信無誤就用Duplicate Backup功能從生產庫復制一份到遠程池。這個操作可以把備份集從本地 NBU 域復制到災備域但沒有 SLP 的定期調度每次都得手工右鍵重復備份不夠自動化。最穩(wěn)妥還是在生產 NBU 中配置一套 SLP 策略設定“備份后復制”動作選擇“目標為遠程存儲單元”。配置 SLP 時要注意本地備份的保留期限要和遠程復制保留期限區(qū)分開否則源端因過期清理了鏡像災備端的副本也可能遭到連帶清除這在 10.4 版本里尤其常見。6. 配置好只是開始驗證備份可恢復的三個進階習慣6.1 每月做一次“整庫恢復演練”而不是只做“備份驗證”備份做沒做成功N BU 的作業(yè)狀態(tài)其實不能完全作數(shù)。機器宕機那一刻你需要的不是備份記錄而是一條明確的恢復鏈路。我給自己訂了一個死規(guī)矩每個月最后一個周六把上周的全量備份恢復到一臺閑置測試主機上然后執(zhí)行ALTER DATABASE OPEN RESETLOGS;。這不是走馬觀花的Restore Validate而是真正把數(shù)據(jù)文件、控制文件、歸檔日志一步步灌進新實例。做過一次真正的異機恢復你會比看任何備份日志都踏實。每次恢復演練后我會用 RMAN 的LIST BACKUP與REPORT SCHEMA核對兩份清單確保沒有遺漏表空間或數(shù)據(jù)文件。如果生產環(huán)境是 RAC 或 ASM演練主機也需要提前裝好同樣的網(wǎng)格組件否則 ASM 磁盤組無法正常裝載恢復過程必然翻車。6.2 寫一個自動檢查 NBU 作業(yè)日志的腳本日常巡檢不必每天打開操作臺最簡單實用的是跑一段判斷邏輯。下面的腳本是我放在 cron 里的每天早晨 8 點執(zhí)行用于檢查前一天的備份作業(yè)里是否存在狀態(tài)碼非 0 的記錄。#!/bin/bash # 自動巡檢 NBU 18 小時以內的任務狀態(tài)并輸出異常 /usr/openv/netbackup/bin/admincmd/bpdbjobs -all_after $(date -d 18 hours ago %m/%d/%Y) | awk -F, $6 ~ /oracle/ $9 ! 0 {print $0} /tmp/nbu_oracle_alert.txt if [ -s /tmp/nbu_oracle_alert.txt ]; then echo [NBU Oracle Alert] 發(fā)現(xiàn)異常作業(yè)請登錄控制臺核查 | mail -s NBU Oracle Backup Alert dba-teamexample.com else echo [NBU Oracle] 昨日 Oracle 相關備份作業(yè)全部完成暫未發(fā)現(xiàn)異常。 fi這段腳本的原理很簡單。bpdbjobs會輸出全部任務記錄用逗號分隔字段。我用awk過濾包含 “oracle” 關鍵字的行同時檢查狀態(tài)碼字段第九列是否等于 0。如果有失敗任務它會輸出到臨時文件并觸發(fā)郵件告警如果一切正常則輸出確認語句。這里有個小心機設置 18 小時的時間窗口而不是從前一天零點開始是為了容忍那些深夜啟動第二天早上才跑完的長任務避免因為它們還沒結束而被誤判為“無備份”。這個腳本雖然簡單粗暴但勝在可靠已經穩(wěn)定運行了兩年多。你甚至可以在末尾追加一個播報聲音不過在生產環(huán)境中看到 “一切正?！?的郵件遠比收到告警更讓人安心。6.3 養(yǎng)成看日志摘要的習慣而不是只盯作業(yè)狀態(tài)經驗告訴我NBU 控制臺的作業(yè)狀態(tài)只是一個漂亮的外殼日志摘要才是真正反映內部活動的地方。Oracle 備份的日志藏在兩條鏈路里一條是 NBU 的bpbkar日志在/usr/openv/netbackup/logs/bpbkar目錄下另一條是 RMAN 自身的輸出日志。推薦每次手動備份時在 RMAN 腳本里加上log參數(shù)把日志定向到一個固定目錄。同時調低 NBU 日志級別在作業(yè)屬性里把debug level調成 2 級別雖然日志量會翻幾倍但出現(xiàn)問題的時候有足夠的數(shù)據(jù)做回溯定位。記得有一次某核心庫備份總是周期性失敗我一遍遍盯控制臺的作業(yè)記錄都沒發(fā)現(xiàn)問題。后來耐著性子把 RMAN 的日志打開發(fā)現(xiàn)ORA-19511每次都發(fā)生在警報表空間SYSAUX的某個數(shù)據(jù)文件讀取時。后來才查清是那個數(shù)據(jù)文件出現(xiàn)物理壞塊和 NBU 本身毫無關系。從那次以后我在每次交接備份系統(tǒng)時一定會強調“日志摘要比作業(yè)狀態(tài)可靠一百倍”這是 NBU 備份 Oracle 必須養(yǎng)成的第一習慣。希望幫到你。本文還有配套的精品資源點擊獲取