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