備份的優化和調整

在瞭解備份優化之前首先要知道RMAN 備份的原理：

當RMAN 發起備份任務時，會開啟相應的通道工作，每一個通道在資料庫伺服器都有一個相對應的服務程式，RMAN 會首先呼叫DBMS_RCVMAN 包讀取控制檔案，確定資料檔案的存放位置等資訊，獲取該資訊後，RMAN 將呼叫DBMS_BACKUP_RESTORE 包對資料檔案進行讀取並備份。讀取過程就是基於RMAN 備份的演算法規則來編譯需要備份的檔案列表。RMAN 執行備份操作時，會請求Oracle 的共享記憶體段來建立自己備份緩衝區，與通道相對應的服務程式會去掃描資料檔案中的資料塊，並且將需要備份的資料塊讀入到輸入緩衝區中，當輸入緩衝區被填滿時，會被轉移到輸出緩衝區，在轉移的過程中，也會對資料塊進行檢測，檢測是否有損壞的資料塊，當輸出緩衝區被填滿時，就會形成備份片，與通道相對應的服務程式最終會將其寫入到指定備份片的位置。

所有的備份恢復不能千篇一律，需要契合不同客戶的生產環境針對性的去調整和優化，否則很有可能會導致生產環境出現問題。生產環境場景有：備份磁碟空間不足、儲存I/O 慢、儲存很快且cpu 資源足夠等。

RMAN 備份的優點如下（以11g 為例）：

1 ）RMAN 會檢測資料壞塊

2 ） 不需要開熱備，額外的重做會減少

3 ）RMAN 備份只備份使用過的塊

4 ）RMAN 備份具有壓縮特性

5 ） 支援增量備份策略

 

對於不同的場景我們需要給出不同的優化方法：

場景一：劃分的備份檔案系統空間不足：

存在這麼一種情況，查詢資料庫大小略大於備份空間大小我們怎麼處理？

這就要從rman 的備份特性說起兩個概念：

1 ）null block compression

2 ）unused block compression

10.1 版本 RMAN 的壓縮方式為空值壓縮（null compression ），當掃描資料塊進行備份時，可以進行空值壓縮，對塊頭為空的塊，在從輸入緩衝區轉移到輸出緩衝區時將其過濾掉，不會去備份已分配但未被格式化的塊。

在10.2 版本RMAN 的壓縮方式又出現一種未使用塊壓縮（unused block compression ），這種壓縮方式是過濾掉不包含資料的資料塊，就是該資料塊已經被使用過（被格式化過），但是不包含資料。

只有在滿足以下條件的時候，Unused Block Compression 會起作用:

1 ）初始化引數COMPATIBLE=10.2 或者更新的版本
2 ）資料檔案是本地管理模式

3 ）完全備份或0 級備份

4 ）備份的指定位置在磁碟上

所以備份出來的備份片相當於被壓縮過，所以這也是rman 備份工具一個很重要的特性，減少不必要的空間浪費。

場景二：備份檔案系統空間非常小

這時候我們很容易想到rman 的壓縮特性，rman  能夠使用二進位制壓縮演算法進行備份，這個二進位制的壓縮演算法能夠大大的減少備份集所需要的磁碟空間，通常情況下壓縮比會達到2-4 倍

使用這種壓縮方式的命令如下:

rman> backup as compressed backupset database;

1 ）啟用壓縮將消耗更多的CPU 資源。。

2 ）啟用壓縮備份耗時略有增加

3 ）節省儲存備份的空間

場景三：備份片很大，備份時間較長

加快備份速度的方法無非是開並行，這裡涉及到兩個關鍵詞：通道、並行

自動分配通道（CHANNEL ）：

Configure  命令來完成通道配置。如果沒有用手工方式為RMAN 分配通道，RMAN 將利用預定義的設定來為命令自動分配通道

RMAN>Configure channel device type disk format ‘xxx’;

可配置自動分配多個通道

手工分配通道（PARALLELISM ）：

allocate channel  命令進行分配通道，這個命令只能放在run 命令塊中，並且它分配的通道也只作用於本run 塊內的命令。

run {

Allocate channel d1 device type disk format ‘xxx’;

Allocate channel d2 device type disk format ‘xxx’;

Backup database;

release channel d1 ；

release channel d2 ；

}

 

注意   如果配置的通道個資料小於 PARALLELISM ，如 PARALLELISM 為 5 ， configure channl 1 ， 2 ， 3 則 1 ， 2 ， 3 指定的配置備份 4 ， 5 按預設的配置來備份。如果配置的通道大於 PARALLELISM ， PARALLELISM 為 3 ，配置 5 個通道，則通道 4 ， 5 被忽略

一個 CPU 任一時刻只能處理一個事務，並行度不能超過 CPU 數量。

 

場景四：資料庫資料量很龐大，增量備份需要較長時間

這裡需要開啟一個資料庫的特性：塊跟蹤

1 ）塊修改跟蹤會記錄資料檔案裡每個塊的更新資訊，這些跟蹤資訊儲存在跟蹤檔案裡。當啟動塊修改跟蹤後，RMAN 使用跟蹤檔案裡的資訊，只讀取改變的塊資訊，而不用在對整個資料檔案進行掃描，從而提高了RMAN  備份的效能。

2 ）塊修改跟蹤預設是禁用的，如果啟用了增量備份，那麼建議開啟塊修改跟蹤。  啟用BCT 後，不需要其他的維護操作。

3 ）在備份期間，修改跟蹤會維護已經標記為更改的塊的點陣圖資訊。Oracle  會自動管理修改跟蹤檔案的大小，只保留最近最近8 次塊更改的資訊。  超過8 次，那麼最前面的塊點陣圖資訊會被當前的更改覆蓋。

4 ）第一個0 級的增量備份掃描整個資料檔案。隨後的增量備份使用塊跟蹤檔案的資訊，只掃描自上次備份以來被標記為更改的塊。

5 ）如果是RAC  環境，塊跟蹤檔案必須放在共享裝置上。

6 ）資料庫在open  或者 mounted  狀態都可以啟用塊跟蹤.

開啟塊跟蹤：

（1 ）  檢視是否設定路徑

SQL> showparameter db_create_file_dest

NAME                                 TYPE        VALUE

----------------------------------------------- ------------------------------

db_create_file_dest                  string

（2 ）  設定存放塊跟蹤檔案路徑

SQL> alter system set db_create_file_dest = 'oracle/blkch' scope=both sid='*';

System altered.

（3 ）  檢查設定路徑

SQL> show parameter db_create_file_dest

NAME                                 TYPE        VALUE

----------------------------------------------- ------------------------------

db_create_file_dest                  string      oracle/blkch

SQL>

（4 ）  開啟塊跟蹤

SQL> alter database enable block change tracking;

Database altered.

也可以直接指定目錄或者複用已存在的檔案

SQL>alter database enable block change tracking using file 'oracle/blkch/blkch.chg' reuse;

禁用塊跟蹤：

SQL>alter database disable block change tracking;

檢視塊跟蹤是否可用：

SQL> select status, filename fromv$block_change_tracking;

STATUS  FILENAME

--------------------------------------------------------------------

ENABLED /oracle/blkch/blkch.chg

 

注意   快跟蹤使用場景一般有兩種： 1 、常規含有增量備份的 RMAN 備份策略； 2 、應用於 XTTS 遷移，可以有效加快增量資料的備份。

在使用 RMAN  增量備份的情況下，啟用塊跟蹤，在做增量備份時會縮短 RMAN  備份的時間，   因為不用掃描整個資料檔案。   但是塊跟蹤也會帶來其他的一些開銷。   所以要根據實際情況決定是否啟用塊跟蹤。