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