【翻譯自mos文章】對rman 壓縮的徹底理解,mos文章rman壓縮
對rman 壓縮的徹底理解
來源於:
A Complete Understanding of RMAN Compression (文檔 ID 563427.1)
適用於:
Oracle Database - Enterprise Edition - Version 8.1.7.4 to 11.2.0.3 [Release 8.1.7 to 11.2]
Information in this document applies to any platform.
***Checked for relevance on 14-Oct-2014***
目標:
rman 壓縮是怎麼工作的?
解決方案:
預設,rman 有3種類型的壓縮:
1. null 壓縮
2. unused block 壓縮
3. binary 壓縮
10.1及其以前,只有null 壓縮可以被使用
從10.2開始,null壓縮和unused block 壓縮 可以被使用。
這些壓縮是自動被執行的,不需要特別的命令來執行壓縮。
null 壓縮和 unused block 壓縮 是對進行backup的 block 實施 過濾(當然有過濾的規則)
binary 壓縮 是一個額外的壓縮,該壓縮是在進行backup的block層級實行的。
1. null 壓縮
當備份datafile到backupset中時,rman 不會備份 那些 從沒有被allocate 的data block(在之前的版本中,該行為被稱作null 壓縮)
這意味著rman從來不備份 那些 從來沒有used的 blocks 。直到oracle 9i ,rman執行的就是null 壓縮。
舉例:
有一個tablespace,該tablespace有一個datafile,該datafile size 是100MB,在這100MB中,有50MB已經被使用,那麼rman只會備份50MB
2.unused block 壓縮
從oracle 10.2開始,rman備份時會skip 掉 那些 當前不包括data(資料)的block,該行為稱作unused block 壓縮。
通過skip掉那些 當前不用來儲存data(資料)的block,rman 建立了更為緊湊的datafile的備份。 在之前的oracle版本中,
rman 僅僅支援null 壓縮,null壓縮是指 skip掉 datafile 中的那些從來沒有被allocate過的空間。使用該特性時,不需要dba進行額外的工作。
舉例:有一個tablespace,該tablespace中有一個datafile,該datafile有100MB,在100MB中,50MB 已經被user table使用掉了。
然後 user drop了 該資料表空間中一個25MB的表,with the new Unused Block Compression on 25MB of the files is backed up.
在該例子中,若是使用null壓縮的話,將會備份50MB,null壓縮會考慮(其實考慮翻譯成備份更為合適)那些已經formattd,曾經used 過的block。
如果下面的所有條件被滿足,unused block 壓縮才會被啟用:
1) compatible 參數被設定為10.2
2) db中沒有定義guaranteed restore points
3) datafile 是本地管理
4) datafile作為 full backup 或者level 0 incremental backup 的備份組的一部分被備份、
5) 備份組被建立在disk上
或者
使用OSB(Oracle Secure Backup)將備份組建立在tape上。
注意:若是使用第三方備份軟體備份到tape上,unused block 壓縮將不會被使用。
跳過unused data block 將會使rman 備份datafile 時,用更少的空間,使得io更有效率。
3 binary 壓縮
binary 壓縮可以通過在backup 子句中指定關鍵字‘as compressed’ 來使用,這種壓縮稱之為binary 壓縮
當rman 寫資料到backup set中時,rman可以使用binary 壓縮演算法。 這個壓縮類似於 很多tape vendors 在備份資料到tape上時的壓縮。
但是,我們不能給出一個確切的壓縮百分比。這個binary 壓縮演算法可以極大的降低備份檔案所佔用的磁碟空間。典型的是2倍或者4倍,對於文本密集型database 甚至更高的壓縮倍數。
做壓縮備份的命令為
RMAN> backup as compressed backupset database;
壓縮backupset時,會有cpu的過載。當在資料庫負載最大的時候,做資料庫的壓縮備份時,你會發現使用as compressed backupset方式進行備份是不可接受的。
在多數其他情境中,壓縮備份組節省出足夠的disk space,是值得讓cpu 負載提高的。
從compressed backupset中restore database,不需要特別的命令,restore命令和非壓縮備份時的restore命令一樣。
從compressed backupset中restore的時間要比非壓縮備份時的時間長。
除了oracle 10g中binary 壓縮使用的BZIP2壓縮演算法,rman 11g也支援ZLIB演算法,用來壓縮使用 database 11g 進階壓縮選項的backup。
BZIP2是11g和10g中預設的壓縮演算法。
BZIP2 壓縮率很高,但是很慢,並且是cpu敏感型的。
ZLIB 很快,但是壓縮率不想其他演算法那麼高(11g 並且使用進階壓縮option時才能用)
受支援的壓縮演算法是BZIP2(預設的)和ZLIB。對最大程度上壓縮而言,BZIP2 壓縮演算法是最佳化的。
而ZLIB壓縮演算法是CPU使用率上最佳化的。BZIP2的cpu 資源消耗比ZLIB要高,但是一般會產生更緊湊的backup。
對ZLIB壓縮演算法,初始化參數compatible必須設定為11.0.0 或者更高,並且需要Oracle 進階壓縮 option
binary壓縮可以使用於:controlfile,archive log, datafile
比如:
MAN> backup as compressed backupset archivelog all;RMAN> backup as compressed backupset database;RMAN> backup as compressed backupset current controlfile;
在寫入到disk之前,rman 壓縮backupset的內容(contents).對於rman 壓縮backup,不需要額外的解壓縮步驟。
配置壓縮演算法的方法如下:
RMAN> CONFIGURE COMPRESSION ALGORITHM '<alg_name>';
4.各種不同的壓縮演算法:
對於不同的壓縮演算法,可以去查詢V$RMAN_COMPRESSION_ALGORITHM
SQL> select ALGORITHM_NAME, ALGORITHM_DESCRIPTION, ALGORITHM_COMPATIBILITY from V$RMAN_COMPRESSION_ALGORITHM ;ALGORITHM_NAME ALGORITHM_DESCRIPTION ALGORITHM_COMPATIB--------------- ------------------------------------------------------------ ------------------BZIP2 good compression ratio 9.2.0.0.0BASIC good compression ratio 9.2.0.0.0LOW maximum possible compression speed 11.2.0.0.0ZLIB balance between speed and compression ratio 11.0.0.0.0MEDIUM balance between speed and compression ratio 11.0.0.0.0HIGH maximum possible compression ratio 11.2.0.0.06 rows selected.