100GB的archivelog ,耗時從3分鐘變?yōu)?8分鐘16倍但是大小基本沒變未壓縮archivelog 100GB 3分鐘datafile 30000GB 900分鐘 實際191分鐘datafile 更快INPUT_TYPE OUTPUT_DEVICE_TYP START_TIME ET(Mins) SIZE (GB) STATUS------------- ----------------- -------------------- ---------- ---------- ----------DB INCR DISK 20260926 00:16:36 191 30475 COMPLETEDARCHIVELOG DISK 20260925 23:07:53 48 102 COMPLETED --compressARCHIVELOG DISK 20260925 22:32:49 3 110 COMPLETED ---no compARCHIVELOG DISK 20260925 22:20:38 42 87 COMPLETED原理rman備份 的dek存放在哪在 Oracle 數據庫中RMAN 加密備份的 DEK數據加密密鑰直接存放在備份片Backup Piece即生成的備份文件的頭部區(qū)域。 [1, 2]為了確保安全性這個 DEK 絕對不會以明文形式存儲而是以密文形式Encrypted Form內嵌在備份文件里 。其完整的存放與加解密邏輯如下 [1, 2, 3] 1. 備份生成時DEK 存放在哪里當你執(zhí)行 RMAN 加密備份時RMAN 會在內存中為每一個備份集Backup Set隨機生成一個獨立的、專用的 DEK 。隨后RMAN 會根據你配置的加密模式用上一層密鑰如 Master Key 或密碼將這個 DEK 加密 。最終存放點包裝后的 DEK 密文被直接寫入到該備份集對應的BKP備份片文件Backup Piece的頭部。數據體本身則由該 DEK 進行數據塊級別的實時加密。 [1, 2, 3, 4, 5]? 2. 三種加密模式下誰來加密 DEK根據 RMAN 的加密配置備份片頭部里的 DEK 是被不同的“外殼”保護的RMAN 加密模式備份片頭部的 DEK 被誰加密恢復Restore時的解密依賴透明加密 (Transparent)由數據庫的TDE 主密鑰 (Master Key)加密必須打開匹配的Oracle Wallet 錢包(.p12/.sso)口令加密 (Password-based)由你在 RMAN 中輸入的解密口令加密不需要錢包輸入相同的Password即可雙重模式 (Dual-mode)同時生成兩份 DEK 密文分別用Master Key和口令加密二選一有錢包或記得密碼均可解密恢復?? 災難恢復3 種場景的重要結論因為 DEK 已經隨備份片一起打包了所以在進行異地恢復或災難重建時你不需要單獨尋找 DEK 文件而是需要解決解密 DEK 的鑰匙如果是透明加密僅僅把 RMAN 備份片復制到新服務器是不夠的。你必須把源庫的Oracle Wallet 錢包文件如ewallet.p12復制到異地并成功打開因為只有錢包里的 Master Key 才能解開備份片頭部的 DEK。 [1, 2, 3]如果是口令加密異地恢復最省心不需要拷貝錢包。只需在 RMAN 中執(zhí)行SET DECRYPTION IDENTIFIED BY 你的密碼;即可直接命令 RMAN 解開備份片頭部的 DEK。 [1, 2]不要與本地 TDE 混淆哪怕數據庫本地的表空間啟用了 TDE 加密其本地 DEK 在DBF數據文件頭在通過 RMAN 備份時如果你沒有配置CONFIGURE ENCRYPTION FOR DATABASE ON;RMAN 默認生成的備份片是不帶備份級 DEK的備份片里的數據由于順次讀取本地已被加密的數據塊在備份片里直接呈現為混亂的密文。 [1]您目前是在規(guī)劃Oracle 異地災備演練 (Cross-System Restore)還是遇到了ORA-19913: unable to decrypt backup piece之類的報錯如果正在編寫異地恢復的腳本我可以為您提供對應的錢包或密碼配置命令。TDE下rman備份需要先解密嗎在 TDE透明數據加密環(huán)境下執(zhí)行 RMAN 備份不需要、也絕對不可以先將數據庫解密。RMAN 在備份時有其獨特的底層處理邏輯具體分為以下兩種情況1. 默認情況直接備份不配置 RMAN 級別加密如果你在 TDE 環(huán)境下直接運行普通的 RMAN 備份命令未開啟 RMAN 層的ENCRYPTIONRMAN 的行為如下數據塊級別直接復制RMAN 會直接從磁盤上讀取已經加密的數據塊Blocks并原封不動地寫入備份片Backup Piece中。安全性備份片中的數據依然是加密的。恢復Restore依賴恢復時直接寫回磁盤即可。但由于數據塊本身是加密的數據庫在運行期讀取這些數據塊時必須依賴 TDE 錢包Wallet里的 Master Key 才能正常打開和讀取。2. 推薦做法開啟 RMAN 級別加密AS TRANS_ONLY / CONFIGURE ENCRYPTION在實際生產中為了能讓備份文件擁有獨立的密鑰管理或者在傳輸到第三方存儲時更安全通常會配置 RMAN 加密雙重復合加密RMAN 在備份時同樣不需要你解密數據庫。它會直接讀取加密的數據并在 RMAN 備份集層面上再加一把鎖。AS TRANS_ONLY的妙用Oracle 提供了一個關鍵字叫ONLY或TRANS_ONLY取決于大版本。它允許 RMAN直接把 TDE 加密過的數據塊打包同時在備份片頭部打上 TDE 相關的加密標記。這樣可以避免 RMAN 在備份時對數據進行“先用 TDE 解密、再用 RMAN 加密”的 CPU 損耗從而極大地節(jié)省備份時的 CPU 開銷。 避坑指南唯一需要確保的一件事雖然你不需要解密數據庫但在執(zhí)行 RMAN 備份時TDE 錢包Wallet必須處于打開OPEN狀態(tài)。如果錢包關閉RMAN 備份會直接報錯例如ORA-28365: wallet is not open。這是因為RMAN 需要讀取數據庫的元數據和控制文件。如果配置了 RMAN 的透明加密模式RMAN 需要調用錢包里的 Master Key 來加密備份集自身的 DEK。 總結在 TDE 環(huán)境下做 RMAN 備份直接備份即可千萬不要去解密數據庫。唯一要做的就是在數據庫中確認錢包已打開sqlSELECT WRL_TYPE, WRL_PARAMETER, STATUS FROM V$ENCRYPTION_WALLET; -- 確保 STATUS 為 OPEN 或 OPEN_NO_DATA_STARTUP請謹慎使用此類代碼。您目前是在寫RMAN 的備份腳本還是在準備把備份集傳輸到異地或者物理備庫 Data Guard進行恢復如果您需要異地恢復需要特別注意錢包文件的遷移我可以為您提供相關的遷移步驟。TDE下的archivelog 為什么不能壓縮在啟用了 TDE透明數據加密的環(huán)境下歸檔日志Archivelog并不是絕對不能壓縮而是“壓縮幾乎完全無效”或者“直接壓縮會導致嚴重的性能暴跌和空間浪費”。這背后的根本原因在于密碼學特性以及 Oracle 底層的加密邏輯1. 核心原因加密數據的“零冗余”特性密碼學原理數據的壓縮如gzip,bzip2,zstd或 RMAN 的COMPRESS依賴于找出數據中的重復模式和冗余結構例如連續(xù)的零、重復的字符串。未啟用 TDE 的 Archivelog包含大量的明文 SQL 變更、未填滿的數據塊空隙大量的0x00冗余度極高通?？梢垣@得4x 到 10x 的超高壓縮率。啟用 TDE 后的 ArchivelogTDE 使用 AES 算法對修改的數據塊或 WAL/Redo 日志進行加密。加密算法的本質就是將數據徹底隨機化白噪聲化。結果加密后的歸檔日志在二進制結構上幾乎沒有任何重復模式。如果你嘗試去壓縮它壓縮軟件會消耗大量的 CPU 算力進行極其復雜的字典匹配最終發(fā)現壓縮率接近 0%甚至因為添加了壓縮文件頭文件反而變大了。2. Oracle RMAN 備份時的特殊限制如果你在 RMAN 中使用BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL;會遇到以下尷尬的局面CPU 暴漲與備份變慢RMAN 的壓縮算法如 BZIP2/ZLIB會強行對這些已經隨機化的二進制數據塊進行掃描和壓縮算法重算導致服務器 CPU 飆升至 100%備份時間成倍拉長但文件體積根本沒有變小。Oracle 官方的架構建議Oracle 在最佳實踐中明確指出對于已經通過 TDE 加密的對象包括加密表空間的數據文件和加密的歸檔日志在進行備份時應該關閉 RMAN 壓縮或者改用專門針對加密數據優(yōu)化的硬件壓縮/高級壓縮選項如高級壓縮選項中的MEDIUM或HIGH算法在某些特定硬件組合下能通過識別加密塊頭跳過無效壓縮但普通壓縮依然無效。3. 特例什么時候 TDE 的 Archivelog 還能被壓縮一點點很多 DBA 會發(fā)現開了 TDE 后有些 Archivelog 壓縮后還是小了 10%~20%這是為什么局部加密因為 TDE 通常是表空間級Tablespace-level加密。如果你的數據庫中只有一部分核心業(yè)務表空間開了 TDE而系統(tǒng)表空間SYSTEM,SYSAUX,UNDOTBS和部分普通表空間沒開那么歸檔日志中屬于“未加密表空間”的那部分重做數據依然是可以被成功壓縮的。如果你開啟了全庫級別的加密歸檔日志將徹底失去壓縮價值。 生產環(huán)境的解法既然無法通過軟件壓縮來節(jié)省歸檔日志的空間業(yè)內通常采用以下方案替代縮短歸檔保留周期提高 RMAN 備份歸檔的頻率例如從一天一次改為每 2 小時或每小時一次備份并驗證成功后立即使用DELETE INPUT刪掉本地磁盤上的歸檔日志。利用存儲底層的硬件壓縮/去重部分高端存儲如全閃存陣列具備硬件級的數據縮減技術雖然對加密數據的壓縮率依然有限但由于是專用芯片處理至少不會白白消耗數據庫服務器的 CPU。您目前是遇到了歸檔日志目錄Archive Destination爆滿的問題還是在調整RMAN 定時備份腳本的壓縮參數如果您正在面對磁盤空間壓力我們可以探討一下如何優(yōu)化您的 RMAN 歸檔清理策略。為什么TDE下db備份可以壓縮您提到了一個非常深刻且看似矛盾的現象既然加密數據因為“隨機化”無法被壓縮為什么在 TDE 環(huán)境下數據文件DB的 RMAN 備份卻依然可以被成功壓縮這并不是因為 TDE 對數據文件放水了而是因為 Oracle RMAN 在備份 TDE 數據文件時使用了與處理歸檔日志Archivelog完全不同的底層解密/處理機制。主要原因有以下三點1. 核心差異RMAN 在備份時有權“提前解密”數據塊這是 DB 備份與 Archivelog 備份最大的區(qū)別備份 Archivelog 時RMAN 是直接以流式二進制Streaming讀取日志文件不關心也不解析里面的邏輯內容因此它看到的完全是 AES 加密后的亂碼無法壓縮。備份 DatafileDB時RMAN 是通過 Oracle 數據庫引擎去讀取數據塊Data Blocks的。當 RMAN 讀取一個 TDE 加密的數據塊時如果數據庫的TDE 錢包Wallet是打開的Oracle 會在內存中先將該數據塊解密為明文然后再交給 RMAN。結果RMAN 壓縮引擎拿到的實際上是未加密的、帶有大量冗余和空閑空間的明文數據塊。因此它能夠像往常一樣進行極高比例的壓縮。(注解密后壓縮并打包進備份片時RMAN 會用備份級的密鑰如密碼或 TDE Master Key重新對整個備份片進行加密以確保備份文件的安全。這個過程被稱為 RMAN 的透明/口令備份加密。)2. 數據文件內部存在大量的“白空間”White Space即使不考慮提前解密數據文件和歸檔日志的物理結構也完全不同歸檔日志Archivelog它是緊湊的、連續(xù)的重做記錄流。一旦被 TDE 加密從頭到尾塞滿了密文沒有任何空隙。數據文件Datafile為了應對未來的數據插入INSERT數據塊內部通常保留了大量的空閑空間PCTFREE / Unused Blocks或者由于刪除了數據留下的空洞。當 RMAN 掃描數據文件時它能準確識別出哪些數據塊是從來沒有使用過的High Water Mark 以上的塊。對于這些空塊RMAN 根本不會去讀取或加密它們而是直接在備份片中進行跳塊Block Skipping或用極小的標記代替。這種對結構性空閑空間的優(yōu)化帶來了巨大的“壓縮”空間。3. Oracle Advanced Compression高級壓縮的智能識別如果您使用的是 Oracle 的高級安全組件Advanced Security和高級壓縮Advanced CompressionRMAN 擁有專門針對 TDE 優(yōu)化的壓縮算法如MEDIUM或HIGH級別這些算法能夠識別出 TDE 加密塊的頭部標識。如果在某種特殊配置下如使用了AS TRANS_ONLY導致 RMAN 只能讀取密文塊高級壓縮引擎會智能放棄對加密數據部分的無用壓縮轉而專門去壓縮塊頭、元數據以及未加密的區(qū)域。雖然這種情況下壓縮率會打折扣但它通過“聰明地偷懶”避免了 CPU 的無效暴漲。 總結對比備份對象RMAN 讀取時的狀態(tài)為什么能/不能壓縮Archivelog (歸檔)純粹的底層密文流無法提前解密數據徹底隨機化無法壓縮。Datafile (DB備份)經錢包在內存中解密后的明文塊恢復了數據的冗余性且能跳過未使用的空閑數據塊可以高效壓縮。您在測試 RMAN 備份壓縮時使用的是普通的BASIC壓縮算法還是購買了高級壓縮選項Advanced Compression的LOW/MEDIUM/HIGH算法呢不同的壓縮算法級別在 TDE 環(huán)境下的CPU 消耗差異非常大如果您需要我們可以對比一下它們的性能損耗。