今天主要介紹一下如何對RMAN備份監控及優化，這裡就不講rman備份的一些原理了，僅供參考。

一、監控RMAN備份

1、確定備份源與備份設備的最大速度
從磁碟讀的速度和磁帶寫的帶度、備份的速度不可能超出這兩個速度、只能儘量的接近、我們心裡要有數

2、通過v$session_longops監測RMAN的性能
v$session_longops會將超過6秒的操作記錄在這個視圖中，可以通過這個視圖觀看RMAN的各個操作已經花費了多少時間，還需要多少時間，每一部分使用了多少時間

SELECT A.SID,
       A.PROGRAM,
       A.STATUS,
       B.OPNAME,
       B.ELAPSED_SECONDS,
       B.TIME_REMAINING
  FROM V$SESSION A, V$SESSION_LONGOPS B
 WHERE A.SID = B.SID
   AND A.SERIAL# = B.SERIAL#
   AND upper(A.PROGRAM) LIKE '%RMAN%'
   AND TIME_REMAINING > 0

3、通過v$backup_sync_io和v$backup_async_io監測IO是否有瓶頸
備份最主要的部分是IO操作，因此IO也是最可能產生瓶頸的地方。
Oracle提供了v$backup_sync_io和v$backup_async_io這兩張視圖用於觀察實際的備份的速率、觀察備份過程中的等待。這兩張視圖中的數據存在的周期是實例運行的過程中、當資料庫被重新啟動，這兩張視圖中的數據會被清空
3.1、同步IO瓶頸

V$BACKUP_SYNC_IO displays performance information about ongoing and recently completed RMAN backups and restores. For each backup, it contains one row for each input datafile, one row for the aggregate total performance of all datafiles, and one row for the output backup piece. This data is not stored persistently, and is not preserved when the instance is re-started.

查詢v$backup_sync_io視圖、關注TYPE為AGGREGATE值的discrete_bytes_per_second這一列
這一列表示每秒中以同步方式備份、恢複數據的字節數，這個值應該接近於備份設備的讀、寫速率
如果這個值很小於備份設備讀寫速率，就需要從CPU負載、備份的進程、網絡、MML接口的配置等幾方面進行檢查、優化。

SELECT device_type device,
       TYPE,
       filename,
       to_char(open_time, 'yyyymmdd hh24:mi:ss') OPEN,
       to_char(close_time, 'yyyymmdd hh24:mi:ss') CLOSE,
       elapsed_time elapse,
       discrete_bytes_per_second d_bytes
  FROM v$backup_sync_io
 WHERE close_time > SYSDATE - 1
 ORDER BY close_time;

3.2、異步IO瓶頸
關注每秒備份、恢復的效率

V$BACKUP_ASYNC_IO displays performance information about ongoing and recently completed RMAN backups and restores. For each backup, it contains one row for each input datafile, one row for the aggregate total performance of all datafiles, and one row for the output backup piece. This data is not stored persistently, and is not preserved when the instance is re-started.

查詢v$backup_async_io、關注TYPE為AGGREGATE值的effective_bytes_per_second這一列

SELECT device_type device,
       TYPE,
       filename,
       to_char(open_time, 'yyyymmdd hh24:mi:ss') OPEN,
       to_char(close_time, 'yyyymmdd hh24:mi:ss') CLOSE,
       elapsed_time elapse,
       effective_bytes_per_second e_bytes
  FROM v$backup_async_io
 WHERE close_time > SYSDATE - 1
 ORDER BY close_time

二、優化RMAN備份

1、分配合理的並行通道數
RMAN的備份、恢復的操作是通過通道(Channel)來完成的,Channel在資料庫伺服器的體現是一個Server進程,當RMAN分配一個Channel時，它即建立了一個到資料庫實例的連接。多個Channel可以相互獨立的完成備份、恢復的操作。

實際測試表明，如果備份設備是帶庫，並行通道數等於帶庫中帶機的數會達到最佳的性能。很少的情況也是一個帶機分配2或3個通道達到最佳性能的狀況。需要注意的是，如果並行通道數多於帶機數，會出現Backupset在多盤磁帶混合存放的情況，因而會影響到恢復的速度
如果備份到磁碟，並行通道數等於磁碟子系統的數量時會達到最佳的性能，磁碟子系統數量指的是輸出設備跨幾塊磁碟。例如磁碟子系統分布在3塊物理硬碟上，則應分配3個通道。
假設並行通道設置2個，參考如下：

CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 2; 
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tsm/client/oracle/bin64/tdpo.opt)';
CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tsm/client/oracle/bin64/tdpo.opt)';

2、確定合理的「多路復用」數

多路復用的目的是為了加快備份時自磁碟讀數據的性能，其針對的是單個channel，當單個通道在備份時，它從多個數據文件同時讀取數據，然後寫到同一個backupset中，這樣的操作模式我們稱之為多路復用。
多路復用級別的多少取決於三個因素：
● FILESPERSET參數
● MAXOPENFILES參數
● 通道讀取的文件數
從實際的測試及Oracle的建議來看，多路復用設置的規則為：

• 如果要備份的所有磁碟或數據文件很好的做了條帶(stripe)，多路復用處就不大了，可以將多路復用級別設為1或者2
• 如果磁碟沒有做條帶，多路復用應當設一個8之下的一個值,大於8的值常用在備份有很多空塊的文件或在做增量備份的場景

3、內存方面調整

3.1、調整linux內核參數shmmax和shmall

kernel.shmmax 是核心參數中最重要的參數之一，用於定義單個共享內存段的最大值，shmmax 設置應該足夠大，能在一個共享內存段下容納下整個的SGA ,設置的過低可能會導致需要創建多個共享內存段，這樣可能導致系統性能的下降 。

kernel.shmmni 內核參數是共享內存段的最大數量，shmmni 預設值 4096 ，一般肯定是夠用了

kernel.shmall 參數是控制共享內存頁數 。Linux 共享內存頁大小為4KB, 共享內存段的大小都是共享內存頁大小的整數倍。假設一個共享內存段的最大大小是16G，那麼需要共享內存頁數是 16GB/4KB=16777216KB/4KB=4194304 （頁），也就是64Bit 系統下16GB 物理內存，設置 kernel.shmall = 4194304 才符合要求(幾乎是原來設置2097152的兩倍)。這時可以將shmmax 參數調整到 16G 了，同時可以修改SGA_MAX_SIZE 和SGA_TARGET 為 12G。

設置之後我們可以通過ipcs -m觀察Oracle的共享內存，看碎片有沒減少。

3.2、增大磁碟/磁帶緩衝區(Buffers)

緩衝區的大小決定了單次IO所能傳送數據的多少，磁碟緩衝區的大小取決於多路復用(Mutiplexing)的級別，對照關係可以參數下表：

當你使用帶庫作為備份設備，並且分配了SBT通道，Oracle會為每一個通道分配一個Buffer

當BACKUP_TYPE_IO_SLAVES初始化數值為TRUE時，磁帶緩衝區這段內存空間會從SGA區分配
當BACKUP_TYPE_IO_SLAVES初始化數值為FALSE時，磁帶緩衝區會從PGA中分配
ORACLE建議這部份空間從LARGE POOL中分配，避免RMAN的IO緩衝區與Library cache的爭用問題

RMAN通道的BLKSIZE參數確定了磁帶緩衝區的大小。
實際的測試及Oracle的建議都表明磁帶緩衝區至少應為256K。

3.3、設定合理的LARGE_POOL_SIZE值

如果LARGE_POOL_SIZE參數沒有設定，磁碟及磁帶緩衝區會試圖從shared pool中分配
這樣會引起shared pool中各組件如Library cache的爭用問題
LARGE POOL要分配一個合理值，如果其大小不夠用，磁碟及磁帶緩衝區會從PGA分配，同時alert 警告信息：

 Ksfqxcre: failure to allocate chared memory means sync I/O will be used whenever async I/O to file not supported natively

4、IO方面調整成異步IO

默認的情況下，當RMAN備份到磁帶時使用的是同步IO
同步IO在一個時點只能執行一次操作，此時的備份性能一定是很糟的
而異步IO一個時點可以做多次操作，更好的填充寫緩衝區，保證磁帶的streaming
對於支持本地異步IO的系統，啟用比較簡單,BACKUP_TAPE_IO_SLAVES這個初始化參數設為TRUE就可以了

ps:簡單比較一下在同異/步備份時數據流傳送的過程：

常用命令如下：

--查看是否開啟異步IO
SELECT NAME,ASYNCH_IO FROM V$DATAFILE F,V$IOSTAT_FILE I WHERE F.FILE#=I.FILE_NO AND FILETYPE_NAME='Data File';
--開啟異步IO
alter system set filesystemio_options=setall  sid ='*' scope=spfile;
startup force;

5、修改成hugepage

Transparent HugePages內存與標準HugePages內存的差異在於內核khugepaged線程在運行時動態分配內存。標準HugePages內存是在啟動時預先分配在運行時不會發生改變。
如檢查Transparent HugePage是否被啟用

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never ---這說明Transparent Hugepage被啟用

覺得有用的朋友多幫忙轉發哦！後面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~