與歸檔日志清理：生產(chǎn)環(huán)境安全實(shí)踐指南)
接手一套生產(chǎn)庫的第一件事我基本都會(huì)先看兩樣?xùn)|西備份策略長什么樣歸檔日志使用率到哪了。前兩年排查過一套業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫磁盤被歸檔日志撐滿整個(gè)實(shí)例卡在日志切換上所有寫事務(wù)全部阻塞最后是先用 RMAN 清掉一批已經(jīng)備份過的歸檔日志才讓系統(tǒng)恢復(fù)過來。RMAN 備份恢復(fù)、刪除歸檔聽起來是 Oracle 日常運(yùn)維里最常見的操作但在生產(chǎn)環(huán)境里每一步都做對(duì)絕對(duì)沒那么簡單。這篇文章不打算背命令手冊(cè)重點(diǎn)講底層邏輯和實(shí)操判斷RMAN 的數(shù)據(jù)塊備份機(jī)制是怎么回事歸檔日志在恢復(fù)鏈路里扮演什么角色全備、增量、歸檔之間如何搭配怎樣安全地把歸檔日志清掉以及真遇到數(shù)據(jù)文件損壞時(shí)怎么把數(shù)據(jù)庫完整撈回來。我會(huì)把常用命令、參數(shù)設(shè)計(jì)思路和踩過的坑一起放出來希望對(duì)你手頭的備份方案有實(shí)際參考價(jià)值。1. 先理解 RMAN 的備份體系與歸檔日志機(jī)制1.1 RMAN 和普通文件備份到底有什么區(qū)別很多剛接觸 Oracle 的運(yùn)維人員最先想到的備份方式是用 cp 或 tar 直接拷貝數(shù)據(jù)文件這種叫用戶管理備份。它看起來直觀實(shí)際上問題不少。第一它會(huì)備份全部內(nèi)容無論數(shù)據(jù)文件里有沒有實(shí)際數(shù)據(jù)空閑塊也被拷貝一遍浪費(fèi)存儲(chǔ)和時(shí)間。第二數(shù)據(jù)庫運(yùn)行時(shí)數(shù)據(jù)文件本身處于不一致狀態(tài)因?yàn)?buffer cache 里的臟數(shù)據(jù)還沒刷到文件redo log 也在不斷變化。直接拷貝出來的文件要在恢復(fù)時(shí)可能需要你自己去處理一大堆一致性校驗(yàn)工作稍不留神就恢復(fù)失敗。RMAN 的邏輯完全不一樣。它通過服務(wù)器會(huì)話讀取數(shù)據(jù)塊找到 allocated block 也就是真正有數(shù)據(jù)的塊只備份這些塊并在備份過程中做數(shù)據(jù)塊內(nèi)部的邏輯校驗(yàn)。它生成的是自包含的備份集里面還會(huì)記錄必要的元數(shù)據(jù)包含 SCN、數(shù)據(jù)文件號(hào)等等。恢復(fù)時(shí) RMAN 知道該用哪個(gè)備份片也知道備份和當(dāng)前 redo log 的 sequence 之間差多少從而自動(dòng)完成恢復(fù)動(dòng)作。打個(gè)比方手動(dòng)備份就像把一屋子文件全部復(fù)印了一遍塞進(jìn)倉庫備份了多少東西全靠自己心里記RMAN 更像一套帶索引的檔案管理系統(tǒng)它不光告訴你文件在哪還記錄什么時(shí)間點(diǎn)有什么版本你只需要告訴它“恢復(fù)到某個(gè)時(shí)間”它就能自己按目錄找文件、按順序歸檔重做日志。這也是為什么在數(shù)據(jù)量不小且要求可恢復(fù)性的核心庫上大家普遍選擇 RMAN。1.2 歸檔日志為什么是恢復(fù)的生命線Oracle 的數(shù)據(jù)庫修改流程是先寫重做日志再寫數(shù)據(jù)文件。聯(lián)機(jī)重做日志是循環(huán)覆蓋的一組寫滿之后切換下一組。如果數(shù)據(jù)庫是非歸檔模式切換出去的那組日志一旦被覆蓋舊內(nèi)容就永久消失數(shù)據(jù)庫也就只能恢復(fù)到最近一次檢查點(diǎn)附近。如果數(shù)據(jù)庫開啟了歸檔模式ARCHIVELOG日志切換時(shí)后臺(tái)進(jìn)程會(huì)把即將被覆蓋的日志內(nèi)容復(fù)制為歸檔日志文件等于是給每個(gè)歷史 redo 日志留下了一份完整副本。有了這份副本數(shù)據(jù)庫才能實(shí)現(xiàn)介質(zhì)恢復(fù)。比如周三數(shù)據(jù)文件所在的磁盤壞了而你的全備是周日晚上做的那么周日晚到周三損壞時(shí)刻之間的所有變更只能靠歸檔日志和當(dāng)前在線 redo log 來重放?；謴?fù)步驟就是先把全備的物理文件恢復(fù)出來再把備份后的歸檔日志從早到晚重新應(yīng)用數(shù)據(jù)庫最終推進(jìn)到接近故障點(diǎn)的狀態(tài)。這也回答了一個(gè)常見問題為什么不能隨意刪除歸檔日志。刪早了刪多了恢復(fù)窗口就會(huì)縮短遇到故障你可能只能恢復(fù)到更早的備份點(diǎn)數(shù)據(jù)丟失量會(huì)成倍放大。所以歸檔日志不是“越刪越爽”的日志殘留它的存在本身就是 RPO恢復(fù)點(diǎn)目標(biāo)的兜底。理解了這一點(diǎn)再去討論刪除歸檔的操作你才會(huì)明白為什么要把“是否有備份”“是否在保留策略范圍內(nèi)”放在刪除之前先想清楚。2. RMAN 備份實(shí)操從環(huán)境準(zhǔn)備到備份命令2.1 確認(rèn)數(shù)據(jù)庫開啟歸檔模式在寫備份腳本之前必須先確認(rèn)數(shù)據(jù)庫處于歸檔模式。用 SQL 執(zhí)行這條命令就可以SQL archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 1024 Next log sequence to archive 1031 Current log sequence 1031如果看到 No Archive Mode需要按下面步驟把數(shù)據(jù)庫切成歸檔模式。整個(gè)過程要重啟一次實(shí)例建議放在業(yè)務(wù)低峰或維護(hù)窗口進(jìn)行SQL shutdown immediate; SQL startup mount; SQL alter database archivelog; SQL alter database open;注意開啟歸檔模式之后數(shù)據(jù)庫會(huì)產(chǎn)生歸檔日志文件。如果你的歸檔目錄是快速恢復(fù)區(qū)Fast Recovery AreaFRA那么 FRA 的空間規(guī)劃直接影響能容納多少歸檔文件。很多生產(chǎn)庫走到“刪除歸檔”這一步其實(shí)就是因?yàn)樽畛?FRA 給得太小備份全占了空間歸檔一兩周就把磁盤填滿了。所以補(bǔ)課的第一步不只是會(huì)切換歸檔還要心里有數(shù)這個(gè)庫每小時(shí)/每天能產(chǎn)生多少歸檔空間能撐多久。2.2 全備腳本最基礎(chǔ)也最剛需的命令先給出一份我實(shí)際用來做每日全備的最小腳本它對(duì)中小型生產(chǎn)庫基本夠用RMAN run { allocate channel c1 device type disk format /backup/rman/%U; backup database plus archivelog delete input; backup current controlfile; backup spfile; release channel c1; }這里最值得關(guān)注的是backup database plus archivelog delete input。它的執(zhí)行順序比較巧妙在備份數(shù)據(jù)文件之前先把當(dāng)前已經(jīng)生成的歸檔日志備份進(jìn)備份集然后開始備份數(shù)據(jù)文件數(shù)據(jù)文件備份完成后再備份這段時(shí)間里新生成的歸檔日志。也就是說從備份開始到結(jié)束所有歸檔日志都有備份沒有遺漏窗口。delete input則在成功備份這些歸檔日志后把原始?xì)w檔文件從磁盤刪除。所以它本質(zhì)上是“先備份后清理”這也是刪除歸檔最安全的一種姿勢(shì)比單獨(dú)執(zhí)行delete archivelog all要穩(wěn)得多。有人會(huì)問這份腳本里為什么要單獨(dú)寫backup current controlfile和backup spfileRMAN 在backup database時(shí)默認(rèn)也會(huì)備份控制文件和參數(shù)文件但我習(xí)慣顯式寫出來。第一恢復(fù)時(shí)可以直接引用控制文件備份避免依賴自動(dòng)行為第二腳本的可讀性更好換人接手時(shí)一看就明白庫的骨架文件有沒有被覆蓋。多寫兩行幾乎不增加成本卻能讓后續(xù)的恢復(fù)過程清晰很多。2.3 增量備份、通道配置與備份集校驗(yàn)數(shù)據(jù)量超過幾十 GB 后每天全備可能不現(xiàn)實(shí)備份窗口會(huì)被拉得很長。增量備份是更務(wù)實(shí)的選擇。RMAN 的增量備份分 0 級(jí)和 1 級(jí)。0 級(jí)會(huì)備份一個(gè)基線是后續(xù)增量恢復(fù)的起點(diǎn)1 級(jí)只備份自上次備份以來發(fā)生變化的 block。差異式 1 級(jí)備份體積可能更小但恢復(fù)時(shí)需要讀取上一次 1 級(jí)備份及 0 級(jí)基線累積式 1 級(jí)備份備份自 0 級(jí)以來所有變化的塊體積更大一些但恢復(fù)時(shí)要應(yīng)用的文件更少恢復(fù)速度更快。一個(gè)常用方案是周日凌晨做 0 級(jí)周一到周六做 1 級(jí)差異式或累積式同時(shí)每次都帶上plus archivelog delete input。如果業(yè)務(wù)變化集中、恢復(fù)要求高可以把 0 級(jí)頻率提高到一天一次或兩天一次。增量級(jí)別并不需要設(shè)置得多復(fù)雜關(guān)鍵是和保留策略匹配得上。通道和格式也值得聊兩句。通道代表一個(gè)備份流allocate channel c1 device type disk指定走磁盤。并發(fā)備份時(shí)多開幾個(gè)通道比如四個(gè)通道并行可以明顯壓縮備份耗時(shí)但也會(huì)提高 I/O 壓力生產(chǎn)上需要結(jié)合磁盤性能來定。format /backup/rman/%U里的%U是唯一文件名生成符保證不同備份片不重名。如果希望備份集壓縮可改成backup as compressed backupset database ...但壓縮會(huì)占用 CPU需要評(píng)估是否值得。還有一個(gè)很容易被忽略的動(dòng)作備份完成后做一次validate。嚴(yán)格來說validate是驗(yàn)證備份文件可讀性和數(shù)據(jù)塊完整性不是恢復(fù)數(shù)據(jù)庫。比如RMAN validate backupset 33;它會(huì)讀取備份集確認(rèn)里面的數(shù)據(jù)文件塊能正常讀出來。這種校驗(yàn)成本比真正恢復(fù)低很多建議周備份執(zhí)行后跑一次至少能提前發(fā)現(xiàn)備份集損壞的問題。2.4 保留策略怎么設(shè)置保留策略回答的問題是RMAN 到底應(yīng)該保留哪些備份和歸檔日志才算夠用兩種常見配置是恢復(fù)窗口和冗余。RMAN CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;恢復(fù)窗口 7 天表示數(shù)據(jù)庫必須能夠恢復(fù)到過去 7 天內(nèi)的任意時(shí)間點(diǎn)。RMAN 會(huì)根據(jù)這個(gè)窗口自動(dòng)判斷哪些備份集和歸檔日志可以標(biāo)記為 obsolete在后續(xù)執(zhí)行delete obsolete時(shí)清理。另一種是按冗余度RMAN CONFIGURE RETENTION POLICY TO REDUNDANCY 2;表示每個(gè)數(shù)據(jù)文件至少保留兩份可用的備份副本。窗口更長或冗余越多占用空間越大。具體怎么設(shè)取決于業(yè)務(wù)允許丟失的數(shù)據(jù)量和可用磁盤空間。一個(gè)小建議保留窗口別設(shè)成 30 天除非你有專門的歸檔存儲(chǔ)否則備份和歸檔會(huì)占掉大量磁盤清理動(dòng)作追不上生成速度最后歸檔堆積問題會(huì)出現(xiàn)得比想象快。先定業(yè)務(wù)要求再反推空間規(guī)劃這是比較健康的做法。3. 刪除歸檔安全清理的完整流程與關(guān)鍵坑點(diǎn)3.1 歸檔日志為什么會(huì)越堆越多歸檔堆積通常是幾個(gè)問題疊加。最典型的是備份腳本里根本沒有backup archivelog這一段只做了數(shù)據(jù)文件備份歸檔日志就一直堆在 FRA 里沒人管。還有一種是 DBA 覺得“刪除歸檔就是清理磁盤”于是定期手動(dòng)執(zhí)行delete archivelog all但沒有關(guān)聯(lián)備份策略結(jié)果刪得過于激進(jìn)真正需要恢復(fù)時(shí)反而缺文件。業(yè)務(wù)側(cè)的原因也不可忽視。某些批量導(dǎo)入、全表更新、索引重建操作會(huì)產(chǎn)生大量 redo如果日志切換頻率高到每幾分鐘切一次一晚上生成幾百份歸檔很正常。我記得有次接手批量任務(wù)只跑了一小時(shí)FRA 空間就掉了 30%到了晚間高峰直接把磁盤寫滿所有事務(wù)卡在日志切換上數(shù)據(jù)庫從“可用”變成“半掛”狀態(tài)。那種場景下第一步永遠(yuǎn)不是討論為什么堆積而是要先把已備份的歸檔安全清理掉騰出空間讓系統(tǒng)恢復(fù)運(yùn)行。3.2 標(biāo)準(zhǔn)操作交叉校驗(yàn)、確認(rèn)備份、再刪除在我的操作習(xí)慣里手動(dòng)清理歸檔會(huì)按固定順序走不直接上來就delete archivelog all。第一步先做交叉校驗(yàn)RMAN crosscheck archivelog all;crosscheck的動(dòng)作是把控制文件里記錄的歸檔日志和磁盤或帶庫上的實(shí)測文件做對(duì)照。有些文件可能被操作系統(tǒng)直接刪除了但你并不知道如果不做這步RMAN 會(huì)認(rèn)為文件還在后續(xù)刪除時(shí)就會(huì)報(bào)找不到文件的錯(cuò)誤。交叉校驗(yàn)后找不到的歸檔會(huì)被標(biāo)記為 expired它不是備份也沒關(guān)系接下來可以清理掉這些狀態(tài)記錄RMAN delete expired archivelog all;第二步確認(rèn)這些歸檔日志是否已經(jīng)有備份。最好的確認(rèn)方式是有backup archivelog或backup database plus archivelog日志輸出。也可以在 RMAN 里先查看RMAN list backup of archivelog all;我一般會(huì)看輸出的范圍是否覆蓋到今天。如果覆蓋不到我絕不會(huì)直接刪更早的歸檔因?yàn)橐坏┖竺嫘枰橘|(zhì)恢復(fù)缺口就會(huì)導(dǎo)致無法繼續(xù)。第三步才執(zhí)行真正的刪除。按天數(shù)保留的寫法最有價(jià)值RMAN delete noprompt archivelog until time sysdate-7;這條命令先列出所有 7 天前的歸檔然后自動(dòng)刪除。我建議執(zhí)行時(shí)先不帶noprompt試跑一次讓 RMAN 列出將被刪除的清單人工掃一眼再正式執(zhí)行避免誤刪近期重要?dú)w檔。對(duì)于絕大多數(shù)業(yè)務(wù)保留 7 天歸檔已經(jīng)覆蓋恢復(fù)窗口如果你的全備每天都做甚至可以只保留到上次全備時(shí)間點(diǎn)之前讓空間占用更少。3.3 刪除歸檔的三種命令和各自場景刪除歸檔常見寫法有三種適用場景不同第一種是“備份即刪除”也就是backup archivelog all delete input或backup database plus archivelog delete input。這種方法最推薦日常使用因?yàn)樗髿w檔日志先進(jìn)入備份集然后才刪原始文件不會(huì)出現(xiàn)“備份還沒做文件先沒了”的尷尬。第二種是手動(dòng)按時(shí)間刪除如delete archivelog until time sysdate-7。適合你已經(jīng)確定歸檔文件本身不再需要或者另外有工具備份了那些文件。需要注意這里的保留天數(shù)并不是 RMAN 自動(dòng)判斷的而是你人為指定的所以要確保時(shí)間范圍的判斷合理。第三種是直接清空全部歸檔如delete noprompt archivelog all。這條命令風(fēng)險(xiǎn)最大通常只在歸檔目錄完全被塞滿、業(yè)務(wù)緊急恢復(fù)運(yùn)行時(shí)才使用。使用這種命令前務(wù)必先確認(rèn)你接受的數(shù)據(jù)丟失風(fēng)險(xiǎn)并且在刪完后立刻觸發(fā)一次新的全備保證后續(xù)恢復(fù)點(diǎn)存在。否則一旦此刻發(fā)生數(shù)據(jù)文件損壞能恢復(fù)的位置會(huì)非常慘淡。3.4 三個(gè)我實(shí)測過的坑看看你中過哪個(gè)坑一把delete obsolete當(dāng)成歸檔清理命令。很多新手以為執(zhí)行完delete obsolete就會(huì)釋放歸檔空間實(shí)際上它清理的依據(jù)是保留策略清理對(duì)象是那些被標(biāo)記為過期的備份集和備份片。歸檔日志本身的原始文件并不會(huì)因?yàn)閐elete obsolete被刪除除非它們作為備份集內(nèi)容一起被判定過期。所以如果你發(fā)現(xiàn)歸檔占滿磁盤正確的思維路徑是先backup archivelog ... delete input或delete archivelog而不是糾結(jié)為什么delete obsolete沒效果?？佣w檔文件被手動(dòng) rm 后沒有交叉校驗(yàn)直接刪除。假設(shè)你在操作系統(tǒng)層面手動(dòng)刪了幾個(gè)歸檔文件然后執(zhí)行delete archivelog all;RMAN 會(huì)報(bào)錯(cuò)提示找不到文件看起來就像命令失敗。這里的問題不是命令本身而是控制文件記錄的元數(shù)據(jù)和磁盤實(shí)際情況不一致。解決方式就是先crosscheck archivelog all;再用delete expired archivelog all;讓 RMAN 先對(duì)賬再清理無效記錄。整個(gè)過程跑通只需要幾秒?yún)s能讓你的清理腳本變得安靜又可靠。坑三備份和數(shù)據(jù)庫放在同一塊磁盤上。delete input的安全性假設(shè)是“備份和原始文件不同盤”。如果備份集也放在數(shù)據(jù)庫主機(jī)的那塊數(shù)據(jù)盤上磁盤一壞備份和歸檔同時(shí)都沒了所謂備份就只是形式上存在。生產(chǎn)環(huán)境里備份存儲(chǔ)必須和數(shù)據(jù)庫存儲(chǔ)隔離至少是獨(dú)立磁盤最好是異地或者云對(duì)象存儲(chǔ)具體視團(tuán)隊(duì)資源而定。這個(gè)原則比任何具體的刪除命令都重要因?yàn)樗鼪Q定了刪除歸檔后是否還有可恢復(fù)的退路。4. 備份的最終目的恢復(fù)實(shí)操與故障排查4.1 restore 和 recover 先分清楚恢復(fù)不是一個(gè)動(dòng)作而是兩個(gè)階段。restore是把備份集里的物理文件還原回?cái)?shù)據(jù)庫目錄例如把損壞的數(shù)據(jù)文件從備份中拷貝回來recover則是把歸檔日志和當(dāng)前 redo log 應(yīng)用到這些還原后的數(shù)據(jù)文件上使它們推進(jìn)到一致或指定的時(shí)間點(diǎn)。你可以粗淺地理解為restore 是“把上次備份還原”recover 是“把備份之后的賬補(bǔ)上”。這是我反復(fù)強(qiáng)調(diào)的一點(diǎn)因?yàn)樵谂挪榛謴?fù)問題時(shí)顯得尤為重要。如果 restore 做完直接 open數(shù)據(jù)庫經(jīng)常報(bào)不一致錯(cuò)誤因?yàn)槟憧吹降氖悄硞€(gè)舊時(shí)間點(diǎn)的狀態(tài)recover 還沒執(zhí)行。反過來如果歸檔日志缺失recover 會(huì)中途停下此時(shí)究竟跳過還是轉(zhuǎn)為不完全恢復(fù)需要仔細(xì)判斷。4.2 數(shù)據(jù)文件損壞恢復(fù)的完整過程假設(shè)一個(gè)多數(shù)的場景數(shù)據(jù)庫還在運(yùn)行但某個(gè)數(shù)據(jù)文件損壞即使數(shù)據(jù)庫可能提示異常。第一步把損壞文件離線SQL alter database datafile 4 offline;然后用 RMAN 恢復(fù)這個(gè)文件RMAN restore datafile 4; RMAN recover datafile 4;最后重新上線SQL alter database datafile 4 online;這是在線文件級(jí)恢復(fù)整個(gè)數(shù)據(jù)庫不需要關(guān)閉只影響文件 4 所在的表空間?；謴?fù)完成后recover會(huì)應(yīng)用文件離線期間產(chǎn)生的所有必要 redo包括歸檔日志和在線日志最終把該數(shù)據(jù)文件和其他文件對(duì)齊到同一個(gè) SCN。如果損壞范圍較大或者控制文件也丟了那就需要整個(gè)數(shù)據(jù)庫恢復(fù)RMAN startup mount; RMAN restore database; RMAN recover database; RMAN alter database open;此處的recover database會(huì)自動(dòng)應(yīng)用備份后到當(dāng)前時(shí)刻的歸檔日志數(shù)據(jù)庫能夠恢復(fù)到盡量接近故障時(shí)刻的狀態(tài)。4.3 不完全恢復(fù)與 resetlogs 的配合當(dāng)業(yè)務(wù)誤刪了某張表或者希望恢復(fù)到某個(gè)誤操作之前的時(shí)間點(diǎn)就需要不完全恢復(fù)。流程是先定位精確時(shí)間或 SCN再執(zhí)行RMAN run { set until time to_date(2024-06-20 09:30:00,yyyy-mm-dd hh24:mi:ss); restore database; recover database; alter database open resetlogs; }set until time指定恢復(fù)目標(biāo)時(shí)間點(diǎn)RMAN 會(huì)找到該時(shí)間點(diǎn)之前最近的數(shù)據(jù)文件備份和一系列歸檔日志把數(shù)據(jù)庫恢復(fù)到那個(gè)時(shí)刻。這里的resetlogs是不完全恢復(fù)之后的固定動(dòng)作它會(huì)重置聯(lián)機(jī)重做日志的 sequence生成一條全新的日志歷史分支。執(zhí)行完resetlogs后數(shù)據(jù)庫就能以新的日志序列繼續(xù)運(yùn)行。這里必須強(qiáng)調(diào)一個(gè)后續(xù)動(dòng)作不完全恢復(fù)后立即做一次全備。因?yàn)閞esetlogs改變了日志序列舊的備份和歸檔日志在恢復(fù)鏈路里可能與新的日志分支不再銜接原有備份集對(duì)于新序列的數(shù)據(jù)庫來說不能直接用于恢復(fù)到更早的時(shí)間點(diǎn)。所以“恢復(fù)完成”不是終點(diǎn)備份重新生成才是。4.4 恢復(fù)失敗時(shí)怎么排查恢復(fù)過程中最常見的是ORA-00283或ORA-01110它們往往指向缺失或損壞的歸檔日志。排查思路分四步查看告警日志alert log其中記錄了恢復(fù)嘗試時(shí)遇到的錯(cuò)誤和具體文件路徑。查詢動(dòng)態(tài)視圖SQL SELECT * FROM v$recovery_log;這個(gè)視圖會(huì)列出恢復(fù)過程中需要應(yīng)用的歸檔日志序列范圍以及已應(yīng)用和待應(yīng)用的狀態(tài)。配合v$log_history可以定位缺失文件。判斷是否可以做完全恢復(fù)。如果缺失的歸檔發(fā)生在恢復(fù)路徑中間后續(xù)歸檔就算存在也無法連續(xù)應(yīng)用完全恢復(fù)不可能了。此時(shí)要么找備份源把缺的歸檔restore archivelog回來要么退而求其次把set until time定位在缺失歸檔之前最近的一個(gè)可用時(shí)間點(diǎn)做不完全恢復(fù)。如果換了主機(jī)或控制文件被重建RMAN 可能認(rèn)不出備份集。這時(shí)用目錄導(dǎo)入命令重新注冊(cè)備份目錄RMAN catalog start with /backup/rman;執(zhí)行完它會(huì)把目錄下的備份片信息寫回控制文件或目錄庫RMAN 就能找到可用的備份集再繼續(xù) restore。很多“備份明明在卻恢復(fù)不了”的詭異情況根本原因就是備份集沒有被 RMAN 的元數(shù)據(jù)識(shí)別。5. 監(jiān)控歸檔增長與日常運(yùn)維建議5.1 用視圖實(shí)時(shí)觀察歸檔和備份狀態(tài)與其等歸檔把磁盤占滿再搶救不如把監(jiān)控提前做起來。最常用的視圖是v$recovery_area_usageSELECT * FROM v$recovery_area_usage;它給出快速恢復(fù)區(qū)里各個(gè)文件類別歸檔日志、備份集、閃回日志等的使用率。如果歸檔日志的百分比持續(xù)超過 70%~80%說明歸檔清理沒跟上需要檢查最近一次備份是否成功、delete input是否真的生效。日志切換頻率也可以監(jiān)控SELECT TO_CHAR(first_time, yyyy-mm-dd hh24) hour, COUNT(*) FROM v$log_history WHERE first_time sysdate - 7 GROUP BY TO_CHAR(first_time, yyyy-mm-dd hh24) ORDER BY 1;如果某些的每小時(shí)切換數(shù)量異常多說明該時(shí)段 redo 生成量很大可能是夜間批量任務(wù)或調(diào)度作業(yè)產(chǎn)生的。我見過一條低效的 update 語句每小時(shí)觸發(fā)幾十次日志切換歸檔文件數(shù)量暴漲直接把 FRA 撐爆。這類問題光靠刪歸檔只是治標(biāo)還需要配合 SQL 調(diào)優(yōu)、調(diào)整批量任務(wù)或者日志組大小才能降低 redo 產(chǎn)生速率。5.2 把備份、清理、監(jiān)控做成閉環(huán)最后聊聊日常運(yùn)維的閉環(huán)設(shè)計(jì)而不是零散的命令。我推薦在定期流程里組合下面幾件事每天按策略執(zhí)行一次數(shù)據(jù)文件備份全備或增量命令中帶上plus archivelog delete input讓歸檔清理自動(dòng)發(fā)生。配置保留策略為RECOVERY WINDOW OF 7 DAYS或符合業(yè)務(wù)需求的窗口執(zhí)行delete obsolete清理過期的備份集。每周至少跑一次crosscheck archivelog all和crosscheck backup再執(zhí)行delete expired把外力刪除文件產(chǎn)生的元數(shù)據(jù)殘留清掉。每個(gè)月或每兩個(gè)季度做一次真實(shí)的恢復(fù)演練把 RMAN 備份恢復(fù)到測試環(huán)境驗(yàn)證備份可用的狀態(tài)。構(gòu)建這個(gè)閉環(huán)的動(dòng)機(jī)來自一個(gè)教訓(xùn)很多環(huán)境備份跑得很勤但從沒驗(yàn)證過恢復(fù)路徑最后真出問題時(shí)才發(fā)現(xiàn)某個(gè)備份片損壞、歸檔空缺、控制文件信息不完整?；謴?fù)演練的意義就是在真正出事前把這些缺陷暴露出來把“理論上能恢復(fù)”變成“實(shí)測能恢復(fù)”。我個(gè)人在實(shí)際操作中的體會(huì)是RMAN 備份恢復(fù)和刪除歸檔真正考驗(yàn)人的不是某條命令怎么寫而是你是否能把備份和刪除放在同一條安全的邏輯鏈路上先有備份再刪原始?xì)w檔先有元數(shù)據(jù)一致再動(dòng)文件先有恢復(fù)演練再放心的策略。最后再分享一個(gè)小技巧每次手工刪除歸檔之后順手執(zhí)行一下list backup summary;和list archivelog all;確認(rèn) RMAN 記錄的狀態(tài)和磁盤上真實(shí)情況一致。幾次之后你會(huì)對(duì)自己這套數(shù)據(jù)庫的歸檔生成速度、空間占用節(jié)奏形成非常直觀的判斷應(yīng)對(duì)突發(fā)狀況時(shí)心里也就不慌了。 Oracle RMAN備份恢復(fù)與歸檔日志清理：生產(chǎn)環(huán)境安全實(shí)踐指南
接手一套生產(chǎn)庫的第一件事我基本都會(huì)先看兩樣?xùn)|西備份策略長什么樣歸檔日志使用率到哪了。前兩年排查過一套業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫磁盤被歸檔日志撐滿整個(gè)實(shí)例卡在日志切換上所有寫事務(wù)全部阻塞最后是先用 RMAN 清掉一批已經(jīng)備份過的歸檔日志才讓系統(tǒng)恢復(fù)過來。RMAN 備份恢復(fù)、刪除歸檔聽起來是 Oracle 日常運(yùn)維里最常見的操作但在生產(chǎn)環(huán)境里每一步都做對(duì)絕對(duì)沒那么簡單。這篇文章不打算背命令手冊(cè)重點(diǎn)講底層邏輯和實(shí)操判斷RMAN 的數(shù)據(jù)塊備份機(jī)制是怎么回事歸檔日志在恢復(fù)鏈路里扮演什么角色全備、增量、歸檔之間如何搭配怎樣安全地把歸檔日志清掉以及真遇到數(shù)據(jù)文件損壞時(shí)怎么把數(shù)據(jù)庫完整撈回來。我會(huì)把常用命令、參數(shù)設(shè)計(jì)思路和踩過的坑一起放出來希望對(duì)你手頭的備份方案有實(shí)際參考價(jià)值。1. 先理解 RMAN 的備份體系與歸檔日志機(jī)制1.1 RMAN 和普通文件備份到底有什么區(qū)別很多剛接觸 Oracle 的運(yùn)維人員最先想到的備份方式是用 cp 或 tar 直接拷貝數(shù)據(jù)文件這種叫用戶管理備份。它看起來直觀實(shí)際上問題不少。第一它會(huì)備份全部內(nèi)容無論數(shù)據(jù)文件里有沒有實(shí)際數(shù)據(jù)空閑塊也被拷貝一遍浪費(fèi)存儲(chǔ)和時(shí)間。第二數(shù)據(jù)庫運(yùn)行時(shí)數(shù)據(jù)文件本身處于不一致狀態(tài)因?yàn)?buffer cache 里的臟數(shù)據(jù)還沒刷到文件redo log 也在不斷變化。直接拷貝出來的文件要在恢復(fù)時(shí)可能需要你自己去處理一大堆一致性校驗(yàn)工作稍不留神就恢復(fù)失敗。RMAN 的邏輯完全不一樣。它通過服務(wù)器會(huì)話讀取數(shù)據(jù)塊找到 allocated block 也就是真正有數(shù)據(jù)的塊只備份這些塊并在備份過程中做數(shù)據(jù)塊內(nèi)部的邏輯校驗(yàn)。它生成的是自包含的備份集里面還會(huì)記錄必要的元數(shù)據(jù)包含 SCN、數(shù)據(jù)文件號(hào)等等。恢復(fù)時(shí) RMAN 知道該用哪個(gè)備份片也知道備份和當(dāng)前 redo log 的 sequence 之間差多少從而自動(dòng)完成恢復(fù)動(dòng)作。打個(gè)比方手動(dòng)備份就像把一屋子文件全部復(fù)印了一遍塞進(jìn)倉庫備份了多少東西全靠自己心里記RMAN 更像一套帶索引的檔案管理系統(tǒng)它不光告訴你文件在哪還記錄什么時(shí)間點(diǎn)有什么版本你只需要告訴它“恢復(fù)到某個(gè)時(shí)間”它就能自己按目錄找文件、按順序歸檔重做日志。這也是為什么在數(shù)據(jù)量不小且要求可恢復(fù)性的核心庫上大家普遍選擇 RMAN。1.2 歸檔日志為什么是恢復(fù)的生命線Oracle 的數(shù)據(jù)庫修改流程是先寫重做日志再寫數(shù)據(jù)文件。聯(lián)機(jī)重做日志是循環(huán)覆蓋的一組寫滿之后切換下一組。如果數(shù)據(jù)庫是非歸檔模式切換出去的那組日志一旦被覆蓋舊內(nèi)容就永久消失數(shù)據(jù)庫也就只能恢復(fù)到最近一次檢查點(diǎn)附近。如果數(shù)據(jù)庫開啟了歸檔模式ARCHIVELOG日志切換時(shí)后臺(tái)進(jìn)程會(huì)把即將被覆蓋的日志內(nèi)容復(fù)制為歸檔日志文件等于是給每個(gè)歷史 redo 日志留下了一份完整副本。有了這份副本數(shù)據(jù)庫才能實(shí)現(xiàn)介質(zhì)恢復(fù)。比如周三數(shù)據(jù)文件所在的磁盤壞了而你的全備是周日晚上做的那么周日晚到周三損壞時(shí)刻之間的所有變更只能靠歸檔日志和當(dāng)前在線 redo log 來重放?；謴?fù)步驟就是先把全備的物理文件恢復(fù)出來再把備份后的歸檔日志從早到晚重新應(yīng)用數(shù)據(jù)庫最終推進(jìn)到接近故障點(diǎn)的狀態(tài)。這也回答了一個(gè)常見問題為什么不能隨意刪除歸檔日志。刪早了刪多了恢復(fù)窗口就會(huì)縮短遇到故障你可能只能恢復(fù)到更早的備份點(diǎn)數(shù)據(jù)丟失量會(huì)成倍放大。所以歸檔日志不是“越刪越爽”的日志殘留它的存在本身就是 RPO恢復(fù)點(diǎn)目標(biāo)的兜底。理解了這一點(diǎn)再去討論刪除歸檔的操作你才會(huì)明白為什么要把“是否有備份”“是否在保留策略范圍內(nèi)”放在刪除之前先想清楚。2. RMAN 備份實(shí)操從環(huán)境準(zhǔn)備到備份命令2.1 確認(rèn)數(shù)據(jù)庫開啟歸檔模式在寫備份腳本之前必須先確認(rèn)數(shù)據(jù)庫處于歸檔模式。用 SQL 執(zhí)行這條命令就可以SQL archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 1024 Next log sequence to archive 1031 Current log sequence 1031如果看到 No Archive Mode需要按下面步驟把數(shù)據(jù)庫切成歸檔模式。整個(gè)過程要重啟一次實(shí)例建議放在業(yè)務(wù)低峰或維護(hù)窗口進(jìn)行SQL shutdown immediate; SQL startup mount; SQL alter database archivelog; SQL alter database open;注意開啟歸檔模式之后數(shù)據(jù)庫會(huì)產(chǎn)生歸檔日志文件。如果你的歸檔目錄是快速恢復(fù)區(qū)Fast Recovery AreaFRA那么 FRA 的空間規(guī)劃直接影響能容納多少歸檔文件。很多生產(chǎn)庫走到“刪除歸檔”這一步其實(shí)就是因?yàn)樽畛?FRA 給得太小備份全占了空間歸檔一兩周就把磁盤填滿了。所以補(bǔ)課的第一步不只是會(huì)切換歸檔還要心里有數(shù)這個(gè)庫每小時(shí)/每天能產(chǎn)生多少歸檔空間能撐多久。2.2 全備腳本最基礎(chǔ)也最剛需的命令先給出一份我實(shí)際用來做每日全備的最小腳本它對(duì)中小型生產(chǎn)庫基本夠用RMAN run { allocate channel c1 device type disk format /backup/rman/%U; backup database plus archivelog delete input; backup current controlfile; backup spfile; release channel c1; }這里最值得關(guān)注的是backup database plus archivelog delete input。它的執(zhí)行順序比較巧妙在備份數(shù)據(jù)文件之前先把當(dāng)前已經(jīng)生成的歸檔日志備份進(jìn)備份集然后開始備份數(shù)據(jù)文件數(shù)據(jù)文件備份完成后再備份這段時(shí)間里新生成的歸檔日志。也就是說從備份開始到結(jié)束所有歸檔日志都有備份沒有遺漏窗口。delete input則在成功備份這些歸檔日志后把原始?xì)w檔文件從磁盤刪除。所以它本質(zhì)上是“先備份后清理”這也是刪除歸檔最安全的一種姿勢(shì)比單獨(dú)執(zhí)行delete archivelog all要穩(wěn)得多。有人會(huì)問這份腳本里為什么要單獨(dú)寫backup current controlfile和backup spfileRMAN 在backup database時(shí)默認(rèn)也會(huì)備份控制文件和參數(shù)文件但我習(xí)慣顯式寫出來。第一恢復(fù)時(shí)可以直接引用控制文件備份避免依賴自動(dòng)行為第二腳本的可讀性更好換人接手時(shí)一看就明白庫的骨架文件有沒有被覆蓋。多寫兩行幾乎不增加成本卻能讓后續(xù)的恢復(fù)過程清晰很多。2.3 增量備份、通道配置與備份集校驗(yàn)數(shù)據(jù)量超過幾十 GB 后每天全備可能不現(xiàn)實(shí)備份窗口會(huì)被拉得很長。增量備份是更務(wù)實(shí)的選擇。RMAN 的增量備份分 0 級(jí)和 1 級(jí)。0 級(jí)會(huì)備份一個(gè)基線是后續(xù)增量恢復(fù)的起點(diǎn)1 級(jí)只備份自上次備份以來發(fā)生變化的 block。差異式 1 級(jí)備份體積可能更小但恢復(fù)時(shí)需要讀取上一次 1 級(jí)備份及 0 級(jí)基線累積式 1 級(jí)備份備份自 0 級(jí)以來所有變化的塊體積更大一些但恢復(fù)時(shí)要應(yīng)用的文件更少恢復(fù)速度更快。一個(gè)常用方案是周日凌晨做 0 級(jí)周一到周六做 1 級(jí)差異式或累積式同時(shí)每次都帶上plus archivelog delete input。如果業(yè)務(wù)變化集中、恢復(fù)要求高可以把 0 級(jí)頻率提高到一天一次或兩天一次。增量級(jí)別并不需要設(shè)置得多復(fù)雜關(guān)鍵是和保留策略匹配得上。通道和格式也值得聊兩句。通道代表一個(gè)備份流allocate channel c1 device type disk指定走磁盤。并發(fā)備份時(shí)多開幾個(gè)通道比如四個(gè)通道并行可以明顯壓縮備份耗時(shí)但也會(huì)提高 I/O 壓力生產(chǎn)上需要結(jié)合磁盤性能來定。format /backup/rman/%U里的%U是唯一文件名生成符保證不同備份片不重名。如果希望備份集壓縮可改成backup as compressed backupset database ...但壓縮會(huì)占用 CPU需要評(píng)估是否值得。還有一個(gè)很容易被忽略的動(dòng)作備份完成后做一次validate。嚴(yán)格來說validate是驗(yàn)證備份文件可讀性和數(shù)據(jù)塊完整性不是恢復(fù)數(shù)據(jù)庫。比如RMAN validate backupset 33;它會(huì)讀取備份集確認(rèn)里面的數(shù)據(jù)文件塊能正常讀出來。這種校驗(yàn)成本比真正恢復(fù)低很多建議周備份執(zhí)行后跑一次至少能提前發(fā)現(xiàn)備份集損壞的問題。2.4 保留策略怎么設(shè)置保留策略回答的問題是RMAN 到底應(yīng)該保留哪些備份和歸檔日志才算夠用兩種常見配置是恢復(fù)窗口和冗余。RMAN CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;恢復(fù)窗口 7 天表示數(shù)據(jù)庫必須能夠恢復(fù)到過去 7 天內(nèi)的任意時(shí)間點(diǎn)。RMAN 會(huì)根據(jù)這個(gè)窗口自動(dòng)判斷哪些備份集和歸檔日志可以標(biāo)記為 obsolete在后續(xù)執(zhí)行delete obsolete時(shí)清理。另一種是按冗余度RMAN CONFIGURE RETENTION POLICY TO REDUNDANCY 2;表示每個(gè)數(shù)據(jù)文件至少保留兩份可用的備份副本。窗口更長或冗余越多占用空間越大。具體怎么設(shè)取決于業(yè)務(wù)允許丟失的數(shù)據(jù)量和可用磁盤空間。一個(gè)小建議保留窗口別設(shè)成 30 天除非你有專門的歸檔存儲(chǔ)否則備份和歸檔會(huì)占掉大量磁盤清理動(dòng)作追不上生成速度最后歸檔堆積問題會(huì)出現(xiàn)得比想象快。先定業(yè)務(wù)要求再反推空間規(guī)劃這是比較健康的做法。3. 刪除歸檔安全清理的完整流程與關(guān)鍵坑點(diǎn)3.1 歸檔日志為什么會(huì)越堆越多歸檔堆積通常是幾個(gè)問題疊加。最典型的是備份腳本里根本沒有backup archivelog這一段只做了數(shù)據(jù)文件備份歸檔日志就一直堆在 FRA 里沒人管。還有一種是 DBA 覺得“刪除歸檔就是清理磁盤”于是定期手動(dòng)執(zhí)行delete archivelog all但沒有關(guān)聯(lián)備份策略結(jié)果刪得過于激進(jìn)真正需要恢復(fù)時(shí)反而缺文件。業(yè)務(wù)側(cè)的原因也不可忽視。某些批量導(dǎo)入、全表更新、索引重建操作會(huì)產(chǎn)生大量 redo如果日志切換頻率高到每幾分鐘切一次一晚上生成幾百份歸檔很正常。我記得有次接手批量任務(wù)只跑了一小時(shí)FRA 空間就掉了 30%到了晚間高峰直接把磁盤寫滿所有事務(wù)卡在日志切換上數(shù)據(jù)庫從“可用”變成“半掛”狀態(tài)。那種場景下第一步永遠(yuǎn)不是討論為什么堆積而是要先把已備份的歸檔安全清理掉騰出空間讓系統(tǒng)恢復(fù)運(yùn)行。3.2 標(biāo)準(zhǔn)操作交叉校驗(yàn)、確認(rèn)備份、再刪除在我的操作習(xí)慣里手動(dòng)清理歸檔會(huì)按固定順序走不直接上來就delete archivelog all。第一步先做交叉校驗(yàn)RMAN crosscheck archivelog all;crosscheck的動(dòng)作是把控制文件里記錄的歸檔日志和磁盤或帶庫上的實(shí)測文件做對(duì)照。有些文件可能被操作系統(tǒng)直接刪除了但你并不知道如果不做這步RMAN 會(huì)認(rèn)為文件還在后續(xù)刪除時(shí)就會(huì)報(bào)找不到文件的錯(cuò)誤。交叉校驗(yàn)后找不到的歸檔會(huì)被標(biāo)記為 expired它不是備份也沒關(guān)系接下來可以清理掉這些狀態(tài)記錄RMAN delete expired archivelog all;第二步確認(rèn)這些歸檔日志是否已經(jīng)有備份。最好的確認(rèn)方式是有backup archivelog或backup database plus archivelog日志輸出。也可以在 RMAN 里先查看RMAN list backup of archivelog all;我一般會(huì)看輸出的范圍是否覆蓋到今天。如果覆蓋不到我絕不會(huì)直接刪更早的歸檔因?yàn)橐坏┖竺嫘枰橘|(zhì)恢復(fù)缺口就會(huì)導(dǎo)致無法繼續(xù)。第三步才執(zhí)行真正的刪除。按天數(shù)保留的寫法最有價(jià)值RMAN delete noprompt archivelog until time sysdate-7;這條命令先列出所有 7 天前的歸檔然后自動(dòng)刪除。我建議執(zhí)行時(shí)先不帶noprompt試跑一次讓 RMAN 列出將被刪除的清單人工掃一眼再正式執(zhí)行避免誤刪近期重要?dú)w檔。對(duì)于絕大多數(shù)業(yè)務(wù)保留 7 天歸檔已經(jīng)覆蓋恢復(fù)窗口如果你的全備每天都做甚至可以只保留到上次全備時(shí)間點(diǎn)之前讓空間占用更少。3.3 刪除歸檔的三種命令和各自場景刪除歸檔常見寫法有三種適用場景不同第一種是“備份即刪除”也就是backup archivelog all delete input或backup database plus archivelog delete input。這種方法最推薦日常使用因?yàn)樗髿w檔日志先進(jìn)入備份集然后才刪原始文件不會(huì)出現(xiàn)“備份還沒做文件先沒了”的尷尬。第二種是手動(dòng)按時(shí)間刪除如delete archivelog until time sysdate-7。適合你已經(jīng)確定歸檔文件本身不再需要或者另外有工具備份了那些文件。需要注意這里的保留天數(shù)并不是 RMAN 自動(dòng)判斷的而是你人為指定的所以要確保時(shí)間范圍的判斷合理。第三種是直接清空全部歸檔如delete noprompt archivelog all。這條命令風(fēng)險(xiǎn)最大通常只在歸檔目錄完全被塞滿、業(yè)務(wù)緊急恢復(fù)運(yùn)行時(shí)才使用。使用這種命令前務(wù)必先確認(rèn)你接受的數(shù)據(jù)丟失風(fēng)險(xiǎn)并且在刪完后立刻觸發(fā)一次新的全備保證后續(xù)恢復(fù)點(diǎn)存在。否則一旦此刻發(fā)生數(shù)據(jù)文件損壞能恢復(fù)的位置會(huì)非常慘淡。3.4 三個(gè)我實(shí)測過的坑看看你中過哪個(gè)坑一把delete obsolete當(dāng)成歸檔清理命令。很多新手以為執(zhí)行完delete obsolete就會(huì)釋放歸檔空間實(shí)際上它清理的依據(jù)是保留策略清理對(duì)象是那些被標(biāo)記為過期的備份集和備份片。歸檔日志本身的原始文件并不會(huì)因?yàn)閐elete obsolete被刪除除非它們作為備份集內(nèi)容一起被判定過期。所以如果你發(fā)現(xiàn)歸檔占滿磁盤正確的思維路徑是先backup archivelog ... delete input或delete archivelog而不是糾結(jié)為什么delete obsolete沒效果?？佣w檔文件被手動(dòng) rm 后沒有交叉校驗(yàn)直接刪除。假設(shè)你在操作系統(tǒng)層面手動(dòng)刪了幾個(gè)歸檔文件然后執(zhí)行delete archivelog all;RMAN 會(huì)報(bào)錯(cuò)提示找不到文件看起來就像命令失敗。這里的問題不是命令本身而是控制文件記錄的元數(shù)據(jù)和磁盤實(shí)際情況不一致。解決方式就是先crosscheck archivelog all;再用delete expired archivelog all;讓 RMAN 先對(duì)賬再清理無效記錄。整個(gè)過程跑通只需要幾秒?yún)s能讓你的清理腳本變得安靜又可靠。坑三備份和數(shù)據(jù)庫放在同一塊磁盤上。delete input的安全性假設(shè)是“備份和原始文件不同盤”。如果備份集也放在數(shù)據(jù)庫主機(jī)的那塊數(shù)據(jù)盤上磁盤一壞備份和歸檔同時(shí)都沒了所謂備份就只是形式上存在。生產(chǎn)環(huán)境里備份存儲(chǔ)必須和數(shù)據(jù)庫存儲(chǔ)隔離至少是獨(dú)立磁盤最好是異地或者云對(duì)象存儲(chǔ)具體視團(tuán)隊(duì)資源而定。這個(gè)原則比任何具體的刪除命令都重要因?yàn)樗鼪Q定了刪除歸檔后是否還有可恢復(fù)的退路。4. 備份的最終目的恢復(fù)實(shí)操與故障排查4.1 restore 和 recover 先分清楚恢復(fù)不是一個(gè)動(dòng)作而是兩個(gè)階段。restore是把備份集里的物理文件還原回?cái)?shù)據(jù)庫目錄例如把損壞的數(shù)據(jù)文件從備份中拷貝回來recover則是把歸檔日志和當(dāng)前 redo log 應(yīng)用到這些還原后的數(shù)據(jù)文件上使它們推進(jìn)到一致或指定的時(shí)間點(diǎn)。你可以粗淺地理解為restore 是“把上次備份還原”recover 是“把備份之后的賬補(bǔ)上”。這是我反復(fù)強(qiáng)調(diào)的一點(diǎn)因?yàn)樵谂挪榛謴?fù)問題時(shí)顯得尤為重要。如果 restore 做完直接 open數(shù)據(jù)庫經(jīng)常報(bào)不一致錯(cuò)誤因?yàn)槟憧吹降氖悄硞€(gè)舊時(shí)間點(diǎn)的狀態(tài)recover 還沒執(zhí)行。反過來如果歸檔日志缺失recover 會(huì)中途停下此時(shí)究竟跳過還是轉(zhuǎn)為不完全恢復(fù)需要仔細(xì)判斷。4.2 數(shù)據(jù)文件損壞恢復(fù)的完整過程假設(shè)一個(gè)多數(shù)的場景數(shù)據(jù)庫還在運(yùn)行但某個(gè)數(shù)據(jù)文件損壞即使數(shù)據(jù)庫可能提示異常。第一步把損壞文件離線SQL alter database datafile 4 offline;然后用 RMAN 恢復(fù)這個(gè)文件RMAN restore datafile 4; RMAN recover datafile 4;最后重新上線SQL alter database datafile 4 online;這是在線文件級(jí)恢復(fù)整個(gè)數(shù)據(jù)庫不需要關(guān)閉只影響文件 4 所在的表空間?；謴?fù)完成后recover會(huì)應(yīng)用文件離線期間產(chǎn)生的所有必要 redo包括歸檔日志和在線日志最終把該數(shù)據(jù)文件和其他文件對(duì)齊到同一個(gè) SCN。如果損壞范圍較大或者控制文件也丟了那就需要整個(gè)數(shù)據(jù)庫恢復(fù)RMAN startup mount; RMAN restore database; RMAN recover database; RMAN alter database open;此處的recover database會(huì)自動(dòng)應(yīng)用備份后到當(dāng)前時(shí)刻的歸檔日志數(shù)據(jù)庫能夠恢復(fù)到盡量接近故障時(shí)刻的狀態(tài)。4.3 不完全恢復(fù)與 resetlogs 的配合當(dāng)業(yè)務(wù)誤刪了某張表或者希望恢復(fù)到某個(gè)誤操作之前的時(shí)間點(diǎn)就需要不完全恢復(fù)。流程是先定位精確時(shí)間或 SCN再執(zhí)行RMAN run { set until time to_date(2024-06-20 09:30:00,yyyy-mm-dd hh24:mi:ss); restore database; recover database; alter database open resetlogs; }set until time指定恢復(fù)目標(biāo)時(shí)間點(diǎn)RMAN 會(huì)找到該時(shí)間點(diǎn)之前最近的數(shù)據(jù)文件備份和一系列歸檔日志把數(shù)據(jù)庫恢復(fù)到那個(gè)時(shí)刻。這里的resetlogs是不完全恢復(fù)之后的固定動(dòng)作它會(huì)重置聯(lián)機(jī)重做日志的 sequence生成一條全新的日志歷史分支。執(zhí)行完resetlogs后數(shù)據(jù)庫就能以新的日志序列繼續(xù)運(yùn)行。這里必須強(qiáng)調(diào)一個(gè)后續(xù)動(dòng)作不完全恢復(fù)后立即做一次全備。因?yàn)閞esetlogs改變了日志序列舊的備份和歸檔日志在恢復(fù)鏈路里可能與新的日志分支不再銜接原有備份集對(duì)于新序列的數(shù)據(jù)庫來說不能直接用于恢復(fù)到更早的時(shí)間點(diǎn)。所以“恢復(fù)完成”不是終點(diǎn)備份重新生成才是。4.4 恢復(fù)失敗時(shí)怎么排查恢復(fù)過程中最常見的是ORA-00283或ORA-01110它們往往指向缺失或損壞的歸檔日志。排查思路分四步查看告警日志alert log其中記錄了恢復(fù)嘗試時(shí)遇到的錯(cuò)誤和具體文件路徑。查詢動(dòng)態(tài)視圖SQL SELECT * FROM v$recovery_log;這個(gè)視圖會(huì)列出恢復(fù)過程中需要應(yīng)用的歸檔日志序列范圍以及已應(yīng)用和待應(yīng)用的狀態(tài)。配合v$log_history可以定位缺失文件。判斷是否可以做完全恢復(fù)。如果缺失的歸檔發(fā)生在恢復(fù)路徑中間后續(xù)歸檔就算存在也無法連續(xù)應(yīng)用完全恢復(fù)不可能了。此時(shí)要么找備份源把缺的歸檔restore archivelog回來要么退而求其次把set until time定位在缺失歸檔之前最近的一個(gè)可用時(shí)間點(diǎn)做不完全恢復(fù)。如果換了主機(jī)或控制文件被重建RMAN 可能認(rèn)不出備份集。這時(shí)用目錄導(dǎo)入命令重新注冊(cè)備份目錄RMAN catalog start with /backup/rman;執(zhí)行完它會(huì)把目錄下的備份片信息寫回控制文件或目錄庫RMAN 就能找到可用的備份集再繼續(xù) restore。很多“備份明明在卻恢復(fù)不了”的詭異情況根本原因就是備份集沒有被 RMAN 的元數(shù)據(jù)識(shí)別。5. 監(jiān)控歸檔增長與日常運(yùn)維建議5.1 用視圖實(shí)時(shí)觀察歸檔和備份狀態(tài)與其等歸檔把磁盤占滿再搶救不如把監(jiān)控提前做起來。最常用的視圖是v$recovery_area_usageSELECT * FROM v$recovery_area_usage;它給出快速恢復(fù)區(qū)里各個(gè)文件類別歸檔日志、備份集、閃回日志等的使用率。如果歸檔日志的百分比持續(xù)超過 70%~80%說明歸檔清理沒跟上需要檢查最近一次備份是否成功、delete input是否真的生效。日志切換頻率也可以監(jiān)控SELECT TO_CHAR(first_time, yyyy-mm-dd hh24) hour, COUNT(*) FROM v$log_history WHERE first_time sysdate - 7 GROUP BY TO_CHAR(first_time, yyyy-mm-dd hh24) ORDER BY 1;如果某些的每小時(shí)切換數(shù)量異常多說明該時(shí)段 redo 生成量很大可能是夜間批量任務(wù)或調(diào)度作業(yè)產(chǎn)生的。我見過一條低效的 update 語句每小時(shí)觸發(fā)幾十次日志切換歸檔文件數(shù)量暴漲直接把 FRA 撐爆。這類問題光靠刪歸檔只是治標(biāo)還需要配合 SQL 調(diào)優(yōu)、調(diào)整批量任務(wù)或者日志組大小才能降低 redo 產(chǎn)生速率。5.2 把備份、清理、監(jiān)控做成閉環(huán)最后聊聊日常運(yùn)維的閉環(huán)設(shè)計(jì)而不是零散的命令。我推薦在定期流程里組合下面幾件事每天按策略執(zhí)行一次數(shù)據(jù)文件備份全備或增量命令中帶上plus archivelog delete input讓歸檔清理自動(dòng)發(fā)生。配置保留策略為RECOVERY WINDOW OF 7 DAYS或符合業(yè)務(wù)需求的窗口執(zhí)行delete obsolete清理過期的備份集。每周至少跑一次crosscheck archivelog all和crosscheck backup再執(zhí)行delete expired把外力刪除文件產(chǎn)生的元數(shù)據(jù)殘留清掉。每個(gè)月或每兩個(gè)季度做一次真實(shí)的恢復(fù)演練把 RMAN 備份恢復(fù)到測試環(huán)境驗(yàn)證備份可用的狀態(tài)。構(gòu)建這個(gè)閉環(huán)的動(dòng)機(jī)來自一個(gè)教訓(xùn)很多環(huán)境備份跑得很勤但從沒驗(yàn)證過恢復(fù)路徑最后真出問題時(shí)才發(fā)現(xiàn)某個(gè)備份片損壞、歸檔空缺、控制文件信息不完整?；謴?fù)演練的意義就是在真正出事前把這些缺陷暴露出來把“理論上能恢復(fù)”變成“實(shí)測能恢復(fù)”。我個(gè)人在實(shí)際操作中的體會(huì)是RMAN 備份恢復(fù)和刪除歸檔真正考驗(yàn)人的不是某條命令怎么寫而是你是否能把備份和刪除放在同一條安全的邏輯鏈路上先有備份再刪原始?xì)w檔先有元數(shù)據(jù)一致再動(dòng)文件先有恢復(fù)演練再放心的策略。最后再分享一個(gè)小技巧每次手工刪除歸檔之后順手執(zhí)行一下list backup summary;和list archivelog all;確認(rèn) RMAN 記錄的狀態(tài)和磁盤上真實(shí)情況一致。幾次之后你會(huì)對(duì)自己這套數(shù)據(jù)庫的歸檔生成速度、空間占用節(jié)奏形成非常直觀的判斷應(yīng)對(duì)突發(fā)狀況時(shí)心里也就不慌了。