㈠ 發現問題
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性能調優相關視圖
| 視圖名 | 說明 |
| v$rman_backup_job_details | 備份job信息 |
| v$backup_async_io | 當前正在運行的、最近完成的備份和restore操作的rman異步I/O性能信息 |
| v$backup_sync_io | 當前正在運行的、最近完成的備份和restore操作的rman同步I/O性能信息 |
| v$process | 當前活躍進程 |
| v$session | 當前活躍會話信息 |
| v$session_longops | 可以顯示rman備份、還原和恢復進度 |
| v$recovery_progress | rman操作進度 |
| v$session_wait | 顯示會話正在等待的事件、資源信息 |
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備份期間速度最慢的步驟或任務
確定備份和還原步驟
RMAN備份在通道中執行任務時.將經歷以下三個主要階段：
鄭州不孕不育醫院:http://jbk.39.net/yiyuanzaixian/zztjyy/
(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執行備份需要的緩衝區的數量和大小
| 多路複用級別 | 輸入磁盤緩衝區大小 |
| <=4 | 16個1MB的緩衝區，分佈在所有輸入文件中 |
| > 5 & < 8 | 512MB的緩衝區，數量不定，以便將緩衝區 的總大小控制在16MB以內 |
| >8 | 4個128KB緩衝區（針對每個輸入文件的512KB） |
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選項，則備份將會終止並給出一個錯誤