RMAN備份恢復效能優化

㈠ 發現問題

   RMAN在做備份、恢復時所做的操作說起來很簡單：

   就是把資料從“源”讀到緩衝區，然後自讀緩衝區寫到“目的地”、並在這個過程中完成資料塊的校驗工作

   這一過程中會發生很多的操作、而如果某一操作慢了我們則稱其為瓶頸

   發現問題的關鍵在於挑出這個瓶頸

   ① 確定備份源與備份裝置的最大速度

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

      Ⅰ 確定磁碟讀速度：

      可以在資料伺服器負載高峰期做一下sar –d，把物理盤的blks/s這一列加起來，再乘上作業系統塊的大小

      或者

      也可以挑出一些盤或LV，做對/dev/null的dd操作，然後用sar –d 進行觀察，測算速度

      Ⅱ 備份裝置的速度

      可以通過並行備份多個資料量大點的檔案系統獲得

   ② 通過v$session_longops監測RMAN的效能

      v$session_longops是一個很有用的檢視，超過6秒的操作會被記錄在這個檢視中

      這個檢視觀看RMAN的各個操作已經花費了多少時間，還需要多少時間，每一部分使用了多少時間

sys@ORCL> ed

Wrote file afiedt.buf

  1  SELECT A.SID,A.PROGRAM,A.STATUS,B.OPNAME,B.ELAPSED_SECONDS,B.TIME_REMAINING

  2    FROM V$SESSION A, V$SESSION_LONGOPS B

  3   WHERE A.SID = B.SID  AND

  4         A.SERIAL# = B.SERIAL# AND

  5         upper(A.PROGRAM) LIKE '%RMAN%' AND

  6*        TIME_REMAINING > 0

   ③ 通過v$backup_sync_io和v$backup_async_io可以監測IO是否有瓶頸

      備份最主要的部分是IO操作，因此IO也是最可能產生瓶頸的地方

      Oracle提供了v$backup_sync_io和v$backup_async_io這兩張檢視用於：

      觀察實際的備份的速率、觀察備份過程中的等待

      這兩張檢視中的資料存在的週期是例項執行的過程中、當資料庫被重新啟動，這兩張檢視中的資料會被清空

      ⑴ 同步IO瓶頸

         查詢v$backup_sync_io檢視、關注TYPE為AGGREGATE值的discrete_bytes_per_second這一列

         這一列表示每秒中以同步方式備份、恢復資料的位元組數，這個值應該接近於備份裝置的讀、寫速率

         如果這個值很小於備份裝置讀寫速率，我們優化的機會就來了

         可以從CPU負載、備份的程式、網路、MML介面的配置等幾方面進行檢查、優化

         指令碼：

sys@ORCL> ed

Wrote file afiedt.buf

  1  SELECT device_type device,TYPE,filename,

  2         to_char(open_time,'yyyymmdd hh24:mi:ss') OPEN,

  3         to_char(close_time,'yyyymmdd hh24:mi:ss') CLOSE,

  4         elapsed_time elapse,discrete_bytes_per_second d_bytes

  5    FROM v$backup_sync_io

  6   WHERE close_time>SYSDATE-1

  7*  ORDER BY close_time

      ⑵ 非同步IO瓶頸

         Ⅰ 關注每秒備份、恢復的效率

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

            在生產環境，基本用的都是非同步IO的方式，因此這個檢視用的頻率特別的多

            指令碼：

sys@ORCL> ed

Wrote file afiedt.buf

  1  SELECT device_type device,TYPE,filename,

  2         to_char(open_time,'yyyymmdd hh24:mi:ss') OPEN,

  3         to_char(close_time,'yyyymmdd hh24:mi:ss') CLOSE,

  4         elapsed_time elapse,effective_bytes_per_second e_bytes

  5    FROM v$backup_async_io

  6   WHERE close_time>SYSDATE-1

  7*  ORDER BY close_time

            同理、當effective_bytes_per_second這一列表示每秒中以非同步方式備份、恢復資料的位元組數

            這個值應該接近於備份裝置的讀、寫速率，如果這個值很小於備份裝置讀寫速率、我們也該注意了

         Ⅱ 關注IO等待 

            v$backup_async_io與IO等待相關的幾列：

            IO_COUNT：整個IO的總數 

            READY：非同步方式buffer請求，buffer立即可以獲復的次數 

            SHORT_WAITS：請求buffer不能立即獲得，不過經過簡短非的阻塞方式輪詢可獲的次數

            LONG_WAITS： 請求buffer不能獲得，需經過阻塞的等待，等待IO裝置的次數

            其中、LONG_WAIT是重點關注的物件，當LONG_WAITS/IO_COUNT這個值比較高時表明IO方式存在著瓶頸

            需要注意一下相關的檔案，看一下IO分佈是不是存在問題

㈡ 優化前的準備工作

   ⑴ 戰略上

      ① IO方面的調整

         備份、恢復是一個讀、寫密集型的操作

         資料檔案的IO均衡對備份的速度影響極大

         如果資料庫在IO方面做了很好的均衡，資料檔案也是跨磁碟做的條帶(stripe)

         Oracle的測試是會有至少10%的備份效能提升

      ② 記憶體方面的調整

         RMAN備份過程是將資料讀到buffer，然後通過MML介面寫到備份裝置

         Oracle推薦設定合理的Large pool，讓RMAN的buffer出自Large pool

      ③ SQL的優化

         不好的SQL耗用IO，耗用cache等各種資料庫資源

         這會讓RMAN可用資源減小

      ④ 備份策略的調整

         在業務的不繁忙期進行備份，同時做好全、增量備份的設定工作

         比如DG環境，全備份完全可以從Standby結點來做，在不影響業務的同時也保證了備份的速度

         Rac環境可以從兩個結點同時來備份增加讀的速度

   ⑵ 戰 術上

      ① 並行通道(Channel Parallelism)

         RMAN的備份、恢復的操作是通過通道(Channel)來完成的

         Channel在資料庫伺服器的體現是一個Server程式

         當RMAN分配一個Channel時，它即建立了一個到資料庫例項的連線

         多個Channel可以相互獨立的完成備份、恢復的操作

         因而活動通道數即並行通道數,簡而言之為並行通道

      ② 多路複用(Mutiplexing) 

         多路複用的目的是為了加快備份時自磁碟讀資料的效能，其針對的是單個channel

         當單個通道在備份時，它從多個資料檔案同時讀取資料，然後寫到同一個backupset中

         這樣的操作模式我們稱之為多路複用

         多路複用級別的多少取決於三個因素：

         ● FILESPERSET引數

         ● MAXOPENFILES引數

         ● 通道讀取的檔案數

         例如我的庫有100個資料檔案，FILESPERSET引數為12，MAXOPENFILES引數為10

         那麼多路複用級別=min(min(100,12),10)=10

      ③ 同/非同步IO

         如下以備份到帶庫簡單描述、比較一下在同異/步備份時資料流傳送的過程：

       ④ 磁碟/磁帶緩衝區(Buffers) 

         緩衝區的大小決定了單次IO所能傳送資料的多少

         Ⅰ 磁碟緩衝區 

            磁碟緩衝區的大小取決於多路複用(Mutiplexing)的級別，對照關係可以引數下表：

            具體每個檔案被分配了多大的Buffer可以通過如語句查到：

sys@ORCL> ed

Wrote file afiedt.buf

  1  SELECT type, filename, buffer_size, buffer_count, open_time, close_time

  2    FROM v$backup_async_io

  3*  ORDER by type, open_time, close_time

         Ⅱ 磁帶緩衝區

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

            當BACKUP_TYPE_IO_SLAVES初始化數值為TRUE時，磁帶緩衝區這段記憶體空間會從SGA區分配

            當BACKUP_TYPE_IO_SLAVES初始化數值為FALSE時，磁帶緩衝區會從PGA中分配

            ORACLE建議這部份空間從LARGE POOL中分配，避免RMAN的IO緩衝區與Library cache的爭用問題

      ⑤ 磁帶自身的情況

         每家廠商每種產品的帶機都有其利弊

㈢ 提升備份的效能

   ① 分配合理的並行通道數

      實際測試表明，如果備份裝置是帶庫，並行通道數等於帶庫中帶機的數會達到最佳的效能

      很少的情況也是一個帶機分配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/tivoli/tsm/client/oracle/bin64/tdpo.opt)';

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

   ② 確定合理的“多路複用”數

      從實際的測試及Oracle的建議來看，多路複用設定的規則為：

      如果要備份的所有磁碟或資料檔案很好的做了條帶(stripe)，多路複用處就不大了，可以將多路複用級別設為1或者2

      如果磁碟沒有做條帶，多路複用應當設一個8之下的一個值

      大於8的值常用在備份有很多空塊的檔案或在做增量備份時

   ③ 使用非同步IO 

      預設的情況下，當RMAN備份到磁帶時使用的是同步IO

      同步IO在一個時點只能執行一次操作，此時的備份效能一定是很糟的

      而非同步IO一個時點可以做多次操作，更好的填充寫緩衝區，保證磁帶的streaming

      對於支援本地非同步IO的系統，啟用比較簡單,BACKUP_TAPE_IO_SLAVES這個初始化引數設為TRUE就可以了

   ④ 當備份裝置為帶庫時，以BLKSIZE引數調整磁帶緩衝區 

      當備到磁帶時，這是改善RMAN備份效能很重要的一項

      RMAN通道的BLKSIZE引數確定了磁帶緩衝區的大小

      實際的測試及Oracle的建議都表明磁帶緩衝區至少應為256K

      如果你的磁帶備份出現了Not Streaming問題，經過檢查發現問題的並不是出現在備份空檔案及做增量備份上

      你可以嘗試調整BLKSIZE引數來改變磁帶緩衝區，Not Streaming會有改善

      改變BLKSIZE引數也很簡單，調整ALLOCATE CHANNEL或CONFIGURE CHANNEL的PARAM引數即可

      例如，可以這樣將磁帶緩衝區設成512K： 

RMAN>configure channel device type sbt PARAMS= “BLKSIZE=524288 ” 

   ⑤ 設定合理的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

   ⑥ 空檔案及增量備份時需考慮的問題

      當備份包含大量空塊的檔案及做增量備份時，保證磁帶緩衝區滿是一件較難的事，因而會引起磁帶的Not Sreaming的問題

      這方面的優化說起來也很容易，此時可以將多路複用(Multiplexing)調整到一個比較大的值，比如50

㈣ 提升恢復的效能

   ① 資料庫的效能

      ● I/O

         Recovery是一個讀和寫都密集型的操作，它需要：

         讀出歸檔日誌的內容

         把資料檔案相關的blocks讀到Cache

         把Recover完的髒塊回寫到硬碟

         因此資料庫要有良的IO均衡和良好的IO效能

      ● DBWR的效能

         Recovery過程中的髒塊回寫到資料檔案的工作是由DBWR程式來完成的

         因此DBWR的效能也會對Recovery的效能產生影響

         DBWR的瓶頸可以通過v$session_wait檢視的”free buffer waits”表現出來

         如果在各個時點總有一些這樣的等待說明DBWR的寫速度存在著瓶頸

         提高DBWR寫速度的方法有：

         啟用非同步IO

         多加一個DBWR程式

      ● CPU的效能

         每一個需要recover的資料塊在重做日誌應用其上前首先要被讀入Buffer cache中

         因此這便有一個栓(Latch)獲取的過程，包括cache buffers chains和cache buffers lru chain兩種栓

         獲取栓對資料塊修改的過程都需要CPU資源

         因此在Recovery過程中要確保有充足的CPU頻寬，特別是在做並行Recovery的時候

   ② 恢復要需用到的歸檔日誌、增量備份的量

      理論及實測都表明，增量備份會加快資料恢復的速度，用到的歸檔量越多恢復的時間會越加長

      10g及之後的版本已經加入了變化塊記錄的機制，會大大的加快增量備份的速度，同時大大減少對應用系統效能的影響

   ③ 需要恢復的資料檔案的量

      恢復時要仔細分析，減少介質恢復和Recovery的量

      例如，如果壞的只是一個資料檔案中的幾個塊，可以考慮做塊的介質恢復

   ④ 歸檔日誌的存在哪 

      一個好的主意就是在磁碟上存放一些近最近的歸檔日誌，這樣會加快Recovery的速度

   ⑤ 並行恢復(10g及之後版本)

      在多CPU系統做Recovery時，你可以為RECOVER命令指定一個並行度，會有多個並行程式同時工作

      例如：

RMAN> RECOVER TABLESPACE users PARALLEL 4; 

㈤ 總結

   RMAN 調優實則是項體力活、需要不斷測試

   RMAN效能調整也是在需求一個平衡點，使備份恢復的效能滿足實際的要求，又對生產影響最小

RMAN效能調優相關檢視

1.找出執行rman的資料庫會話

SQL> SELECT s.sid, s.serial#, p.spid, s.client_info  2    FROM v$process p, v$session s  3   WHERE p.addr = s.paddr  4     AND s.client_info LIKE '%rman%';

       SID    SERIAL# SPID                     CLIENT_INFO

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

       69        153 13356                    rman channel=ORA_DISK_1

SQL>

在執行rman操作時候，可以使用"set command id"來標識rman會話程式

RMAN> run{2> allocate channel d1 type disk;3> set command id to 'my_session';4> backup database;5> }

SQL> SELECT b.sid, b.serial#, a.spid, b.client_info  2    FROM v$process a, v$session b  3   WHERE a.addr = b.paddr  4     AND b.client_info LIKE '%rman%';

       SID    SERIAL# SPID                     CLIENT_INFO

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

       69        157 13434                    id=my_session,rman channel=d1

SQL>

2.檢視rman job詳細資訊：

SQL> select session_recid,  2         input_bytes_per_sec_display,  3         output_bytes_per_sec_display,  4         time_taken_display,  5         end_time  6    from v$rman_backup_job_details  7   order by end_time;

SESSION_RECID INPUT_BYTES_PER_SEC_ OUTPUT_BYTES_PER_SEC TIME_TAKEN_DISPLAY             END_TIME

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

1     3.09M                3.12M            00:00:03                       17-JUN-15

            3   178.12K              122.60K            05:38:23                       17-JUN-15

           27   107.93M               75.97M            00:00:17                       23-JUN-15

           42    64.91M               50.01M            00:00:37                       25-JUN-15

           51   109.27M               76.85M            00:00:17                       25-JUN-15

           57   109.27M               76.85M            00:00:17                       25-JUN-15

           90    43.96M               31.23M            00:02:10                       29-JUN-15

           98    19.74M               14.03M            00:03:13                       29-JUN-158 rows selected.

SQL>

3.檢視rman操作的進度

select s.client_info,

       sl.opname,

       sl.message,

       sl.sid,

       sl.serial#,

       p.spid,

       sl.sofar,

       sl.totalwork,

       round(sl.sofar / sl.totalwork * 100, 2) "% Complete"

  from v$session_longops sl, v$session s, v$process p where p.addr = s.paddr

   and sl.sid = s.sid

   and sl.serial# = s.serial#

   and opname LIKE 'RMAN%'

   and opname NOT LIKE '%aggregate%'

   and totalwork != 0

   and sofar <> totalwork;

如果沒有開啟I/O slaves，rman只是使用share pool。

如果開啟了I/O slaves進行rman備份（設定了dbwr_io_slaves或backup_tape_io_slaves），需要考慮large pool的大小，因為rman會使用large pool。

Oracle官方建議： large_pool_size = num_of_allocated_channels * (16 MB + (4 * size_of_tape_buffer ))

RMAN的media recovery預設會根據cpu_count引數的值，開啟並行恢復。

PARALLELISM --- 

我們還可以通過parallelism引數來指定同時"自動"建立多少個通道：

RMAN > configure device type disk parallelism 3 ; 

表示啟動三個通道，可以加快備份恢復的速度。

預設情況下，自動分配通道的並行度為1，如果你通過設定PARALLELISM設定了並行通道

為2，那麼在run塊中，如果你沒有單獨通過ALLOCATE CHANNEL命令指定通道，它會預設

使用2條並行通道，如果你在run命令塊中指定了數個ALLOCATE CHANNEL，那麼rman在執

行備份命令時會以你設定的channel為準，而不管configure中配置了多少個並行通道。

需要注意的一點是，在backup命令中有一個FILESPERSET引數，該引數是指rman建立的每

個備份集中所能包含的資料檔案的最大數(注意： 不是指備份片，也就是備份出來的檔案)，該引數預設值為64，如果在執行

backup命令時沒有指定該引數值，那麼rman會僅使用第一個通道來執行備份，其它通道

將處於空閒狀態。關於通道數與FILESPERSET值之間也有一個大小關係，邏輯稍顯複雜。

比如， datafiles 的個數為25 ， FILESPERSET = 8 ，那麼備份資料庫的時候生成4個backupset  （25/8=3.125）， 每個備份集包含8個資料檔案。

-----  並行定義通道個數， 通道定義了通道屬性。

例子1 ：

RMAN> configure device type disk parallelism 4;

RMAN> configure channel 1 device type disk;

RMAN> configure channel 2 device type disk;

注意： 在上面的配置中，將開啟四個通道， 通道1，2採用使用者的配置，3，4採用預設配置 。

例子2 ：

RMAN> configure device type disk parallelism 3;

RMAN> configure channel 1 device type disk;

RMAN> configure channel 2 device type disk;

RMAN> configure channel 3 device type disk;

RMAN> configure channel 4 device type disk;

注意： 這時，RMAN將忽略parallelism 的設定，而以使用者設定的通道為準。

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

轉載：

oracle如何在filesperset和channel之間作選擇的？我們看看專家們怎麼說

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

--biti_rainy

filesperset =files per backupset

有10個datafiles,filesperset =4

10/4=2.5

你備份資料庫的時候生成3個backupset

－－－－－－－－－－－－－－－－－－－－－－－－－－－－

--piner

filesperset是說每個備份集最多能備份幾個資料檔案或歸檔日誌

一個備份集可以有多個備份片

資料檔案等備份是不能跨越備份集但是能跨越備份片

所以說備份集包含某資料檔案是正確的。。。

-- blog作者加入： 

注意：   maxpiecesize 用於設定備份片的大小 。比如備份片最大大小為2000M, 那麼一個5G 的資料檔案必須跨備份片進行備份，但是一個資料檔案不能跨多個備份集。   通常一個通道對應一個備份集。

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE 2000 M;

－－－－－－－－－－－－－－－－－－－－－

-- husthxd

用filesperset控制備份集的尺寸

當指定filesperset引數時，rman比較filesperset與自動計算出來的值（對每個已分配通道的檔案數目）

並取其中較小的那個值來保證所有的通道被使用。

如果指定或者通過組合backupSpec語句暗示的檔案數目比filesperset要大，

那麼rman建立多個備份集來維護正確的速率（ratio）；

如果沒有指定filesperset，rman比較計算出來的值（檔案數目除以已分配的通道）和預設值64，

並取其中較小的那個值來保證所有通道可用。

Rman通常嘗試建立足夠的備份集以使所有已分配的通道有事可做。

一個例外是通道比要備份的檔案還要多

blog作者理解舉例：

例如：

A. filesperset設定為6，資料檔案數目為30，通道資料為4，通過30/4可以得出每個

備份集可含有8個檔案，取6和8中較小的值6，那麼30/6=5個備份集，那麼4個通道肯定都有事情可做了。

B. 如果不指定filesperset，假設資料檔案數目為30，通道資料為4，通過30/4可以

得出每個備份集可含有8個檔案，比較8和預設值64，我們取其中較小的8，那麼也可以保證4個通道都有事情可做 。

在遇到資料量大、硬體條件差的資料庫備份時我們會受到多種條件的限制，就有必要使用RMAN的一些限制配置瞭如設定備份片、備份集的最大容量，同時開啟檔案數的最大數量，以及讀寫速

率等。

綜合例項

#這個命令設定了通道1的備份片最大100MB，最多可以開啟8個檔案，讀取速度限制在100MB以內的吞吐量。

configure channel 1 device type disk maxpicesize 100m maxopenfiles 8 rate 100 MB;

maxpiecesize 和maxsetsize之間的關係區別

maxpiecesize限定單個備份片的大型，對備份的整體大小沒影響，另一方面maxsetsize可以限定備份的整體大小，如果備份的資料庫產生的容量大小超過備份片的最大size則備份就會失敗。

限制備份片大小的原因

某種磁帶可能處理的單個檔案大小不能超過2G，或者某個檔案系統上對超過4G的檔案無法處理等等，在這種條件下都必須設定備份片的大小。

配置備份集大小設定和清理

# 設定備份集大小   

configure maxsetsize to 10G;

# 清除設定

configure maxsetsize clear;

備份優化

使用備份優化將在備份期間跳過已經在備份裝置上存在的相同備份本機的備份，用下面這個引數來表示。

CONFIGURE BACKUP OPTIMIZATION OFF

監視RMAN作業

1. 建立rman備份：

RMAN> run {
　　allocate channel ch1 type disk;
　　allocate channel ch2 type disk;
　　backup as compressed backupset tablespace users;
}

2. 當rman作業執行的時候，使用v$PROCESS和V$SESSION檢視client_info資訊：

SQL> select sid, spid, client_info from v$process p join v$session s on (p.addr = s.paddr) where client_info like '%rman%';1. Create two RMAN jobs (in two different RMAN sessions) that back up the USERS and CHGTRK tablespaces and use the SET COMMAND option:/* session 1 */RMAN> run {
　　set command id to 'bkup users';
　　backup as compressed backupset tablespace users;
}/* session 2 */RMAN> run {
　　set command id to 'bkup chgtrk';
　　backup as compressed backupset tablespace users;
}2.
SQL> select sid, spid, client_info from v$process p join v$session s on (p.addr = s.paddr) where client_info like '%id=%';
SQL> select sid, serial#, opname, sofar, totalwork from v$session_longops where opname like 'RMAN%' and sofar <> totalwork;

調整RMAN

可以通過多種方式來調整RMAN操作。

可以使用多個RMAN通道，然後將資料檔案分配到不同的通道，以此來調整備份的總吞吐量。為每個通道分配-個程式，這樣可以通過並行處理方式加快備份過程。與此相反，可以將多個備份檔案多路複用在同一個備份片中。

對於特定通道而言，可以使用 MAXPIECESIZE 和 MAXOPENFILES 引數儘量提高通往特定輸出裝置的吞吐量，BACKUP命令使用這些引數以及 FILESPERSET 和 BACKUP DURATION 引數來優化備份操作。

如果資料庫必須保持可用，而且要滿足嚴格的SLA要求，還可以使用 BACKUP DURATION 來盡最減少備份操作對響應時間的影響。最後，還可以使用資料庫初始化引數來優化備份和恢復效能(特別是同步I/O操作)

如果瞭解每種調整方法的工作原理，就可以保持快捷的使用者響應速度、優化硬體和軟體環境以及在預算緊張的情況下(這種情況幾乎始終存在)推遲升級時間，環境中的某些位置幾乎始終存在著吞吐量瓶頸。瓶頸是RMAN備份期間速度最慢的步驟或任務

1.確定備份和還原步驟
RMAN備份在通道中執行任務時.將經歷以下三個主要階段：

(1) 讀階段 ：通道將資料塊讀入輸入緩衝區
(2) 複製階段 ：通道將塊從輸入緩衝區複製到輸出緩衝,並根據需要執行其他處理：
　　•驗證檢查塊是否受到損壞，此操作不會大量使用CPU
　　•壓縮使用BZIP2或ZLIB來壓縮塊，此操作會大量使用CPU
　　•加密使用加密演算法(透明、口令保護或兩者)來保護資料的安全性，此操作會大量使用CPU
(3) 寫階段 ：通道將輸出緩衝區中的塊寫入輸出裝置(磁碟或磁帶)

使用動態效能檢視，可以確定哪個通道操作的哪個階段出現了瓶領，並採用相應措施予以消除。在某典情況下，可能需要增加備份時間，以便確保縮短恢復時間。每天或每小時建立一次映像副本會增加備份時間，卻可以極大地減少恢復時間

並行備份 ：為了提高備份的速度，通過增加多個通道

1. 通過指定並行引數來實現並行備份：

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;

2. 手動分配通道實現並行備份：

RMAN> run {
　　allocate channel c1 device type disk;
　　allocate channel c2 device type disk;
　　allocate channel c3 device type disk;
　　backup database format='/u01/backup/rmanbk/%d_%s.dbf'　　(datafile 1,2 channel c1)
　　(datafile 3,4 channel c2)
　　(datafile 5,6 channel c3) plus archivelog format='/u01/backup/rmanbk/%d_%s.arc';
}

3. 指定通道的檔案格式，將備份集放在不同的目錄下：

RMAN> run {
　　allocate channel c1 device type disk format='/u01/backup/rmanbk/%d_%s.dbf';
　　allocate channel c2 device type disk format='/u02/backup/rmanbk/%d_%s.dbf';
　　backup as backupset
　　(datafile 1,2,3 channel c1)
　　(datafile 4,5,6 channel c2) plus archivelog;
}

配置RMAN多路技術

可以通過多路複用備份和恢復操作來提高RMAN效能和吞吐最。使用多路複用功能時，RMAN可以同時讀取多個檔案，然後將資料塊寫入到同一個備份片中。

在備份和恢復操作中，使用多路複用來調整RMAN是減少瓶頸的方法之一，主要通過 FILESPERSET 和 MAXOPENFILES 兩個引數來控制多路複用級別
，RMAN BACKUP命令的FILESPERSET引數確定放在每個備份集中的資料檔案數量。如果單個通道最多備份10個資料檔案，但FILESPERSET值是4,則RMAN的每個備份集僅備份4個檔案(取min(10,4))。FILESPERSET引數的預設值是64。

多路複用級別(寫入到同一備份片的輸入檔案數量，或從同一備份片讀取的輸入檔案數量)是MAXOPENFILES和每個備份集中的檔案數量中的最小者。MAXOPENHLES的預設值是8。可以通過以下等式更方便地理解計算方式：
multiplexing_level = min(MAXOPENFILES, min(FILESPERSET, files__per_channel))

本例在一個通道中備份10個資料檔案，MAXOPENFILES值是12, FILESPERSET使用預設值64。因此，使用以下等式計算多路複用級別：
multiplexing_level=min(12, min(64, 10))=10

RMAN根據RMAN作業中的多路複用級別來分配不同數量和大小的磁碟I/O緩衝區。在RMAN根據前面提到的等式，使用FILESPERSET和MAXOPENFILES引數確定了多路複用級別後，可以使用下表提供的資訊確定RMAN執行備份需要的緩衝區的數量和大小

Oracle建議將FILESPERSET值設定為小於等於8的值，以便優化恢復效能。也就是說，如果將過多的輸入檔案放在單個備份集中，由於在恢復單個資料檔案時RESTORE或RECOVER命令仍然需要讀取備份集中大童的多餘塊，所以恢復速度將減慢

配置RMAN使用非同步I/O

在RMAN環境中使用同步I/O還是非同步I/O取決於多種因素。這些因素包括為備份集使用的裝置型別(磁碟或磁帶)，以及輸出裝置或主機作業系統支援同步I/O還是支援非同步I/O，即使主機作業系統或裝置不支援本地非同步I/O,仍然可以配置RMAN,以便使用諸如DBWR_IO_SLAVES這樣的初始化引數模擬非同步I/O

1. 瞭解非同步I/O和同步I/O

當RMAN讀寫資料時，I/O操作要麼是同步操作，要麼是非同步操作。同步I/O操作不允許伺服器程式一次執行多個操作。只有在完成一個操作後才能開始另一個操作。而非同步操作可以啟動一個I/O操作，然後立即執行其他操作(包括啟動另一個I/O操作)
可以 使用初始化引數控制I/O操作的型別 ：
對於 磁帶備份 而言，可以將 BACKUP_TAPE_IO_SLAVES 設定為TRUE,以將備份配置為使用非同步操作，否則，將其設定為FALSE以便使用同步操作。預設值是FALSE。
對於 磁碟備份 而言，大多數現代作業系統支援本地非同步I/O。但是，如果作業系統不予支援，仍然可以將BACKUP_TAPE_IO_SLAVES設定為TRUE，並通過將 DBWR_IO_SLAVES 設定為 非零值 指示Oracle模擬非同步I/O，這會分配 4個從屬備份磁碟I/O ,以便模擬RMAN非同步I/O操作

2.監視非同步I/O
為了監視非同步I/O操作，使用動態效能檢視 V$BACKUP_ASYNC_IO 。重要的監視列如下：
　　• IO_COUNT ：在檔案中執行的I/O數量。
　　• LONG_WAITS ：備份或還原程式必須告知OS等待I/O完成的次數。
　　• SHORT_WAIT_TlME_TOTAL ：非阻塞輪詢I/O完成佔用的總時間(以0.01秒為單位)
　　• LONG_WAIT_TIME_TOTAL ：阻塞等待I/O完成佔用的總時間(以0.01秒為單位)
如果LONG_WAITS與IO_COUNT的比率達到最大，這很可能是備份過程中的瓶頸。如果SHORT_WAIT_TIME_TOTAL 和 LONG_WAlT_TIME_TOTAL 是非零值，則也指示出現了瓶頸。此示例確定兩個包含非零比率的輸入檔案：

SQL> select long_waits / io_count waitcountratio, filename from v$backup_async_io where long_waits / io_count > 0 order by long_waits / io_count desc;

對於這個檔案而言，可以考慮增加多路複用程度，以便減少或消除備份時的等待時間

3.監視同步I/O
動態效能檢視V$BACKUP_SYNC_IO將幫助確定同步I/O操作中的瓶頸以及備份作業的進度。使用DISCRETE_BYTES_PER_SECOND列來檢視操作的I/O比率。此後將此比率與輸出裝置(例如磁帶裝置)的最大比率做比較。如果比率低得多，則可以調整程式，通過使用並行化或增加通道多路複用級別來提高備份操作的吞吐最

SQL> select DISCRETE_BYTES_PER_SECOND from v$backup_sync_io;

如果正在使用同步I/O，但將BACKUP_TAB_IO_SLAVES設定為TRUE,則可在V$BACKUP_ASYNC_IO中監視I/O效能

BACKUP DURATION

指定完成備份需要的時間。可以使用 MINIMIZE TIME 限制此選項以便儘快執行備份，也可以使用 MINIMIZE LOAD 限制此選項以便使用在BACKUP DURATION視窗中指定的全部時間。此外，還可以使用 PARTIAL 選項，以便儲存由於時間限制而終止的部分備份。例如，為了將完全資料庫備份的時間限制在2小時之內，則儘可能快地執行並儲存一部分備份，那麼可以使用此命令：

RMAN> backup duration 2:00 partial database;

如果未在指定的時間內完成備份，但連續的BACKUP命令完成了備份，而且使用了PARTIAL選項，則仍然可以在恢復場景中使用部分備份。如果不使用PARTIAL選項，則備份將會終止並給出一個錯誤

About Me

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2652515/，如需轉載，請註明出處，否則將追究法律責任。