RMAN備份恢復——備份到帶庫的效能
簡單測試了一下rac環境透過RMAN備份到帶庫的功能。
資料庫:Oracle 10203 RAC for Solaris8
帶庫:Quantum PX502
備份軟體:Veritas netbackup 6.0
由於帶庫是502,因此包含兩個控制器。也就是說,應該可以透過兩個控制性並行寫入來提高備份的效能。不過測試發現似乎和我預想的有些出入。
首先看看在一個節點上啟動一個channel進行備份:
$ rman target /
恢復管理器: Release 10.2.0.3.0 - Production on 星期四 5月 10 16:42:19 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
連線到目標資料庫: TESTRAC (DBID=4291216984)
RMAN> run
2> {
3> allocate channel c1 device type sbt;
4> backup database;
5> }
分配的通道: c1通道 c1: sid=296 例項=testrac1 devtype=SBT_TAPE通道c1: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)
啟動 backup 於 11-5月 -07通道 c1: 啟動全部資料檔案備份集通道 c1: 正在指定備份集中的資料檔案輸入資料檔案 fno=00006 name=+DISK/testrac/datafile/zhejiang01.dbf輸入資料檔案 fno=00007 name=+DISK/testrac/datafile/zhejiang02.dbf輸入資料檔案 fno=00009 name=+DISK/testrac/datafile/zhejiang03.dbf輸入資料檔案 fno=00011 name=+DISK/testrac/datafile/zhejiang04.dbf輸入資料檔案 fno=00012 name=+DISK/testrac/datafile/zhejiang05.dbf輸入資料檔案 fno=00014 name=+DISK/testrac/datafile/zhejiang06.dbf輸入資料檔案 fno=00008 name=+DISK/testrac/datafile/ndmain01.dbf輸入資料檔案 fno=00002 name=+DISK/testrac/datafile/undotbs1.263.618591197輸入資料檔案 fno=00004 name=+DISK/testrac/datafile/undotbs2.266.618591249輸入資料檔案 fno=00010 name=+DISK/testrac/datafile/ndindex01.dbf輸入資料檔案 fno=00013 name=+DISK/testrac/datafile/lt_index_ts01.dbf輸入資料檔案 fno=00001 name=+DISK/testrac/datafile/system.262.618591167輸入資料檔案 fno=00003 name=+DISK/testrac/datafile/sysaux.264.618591225輸入資料檔案 fno=00005 name=+DISK/testrac/datafile/users.267.618591279通道 c1: 正在啟動段 1 於 11-5月 -07通道 c1: 已完成段 1 於 11-5月 -07段控制程式碼=1qihelgr_1_1 標記=TAG20070511T091922 註釋=API Version 2.0,MMS Version 5.0.0.0通道 c1: 備份集已完成, 經過時間:01:25:45通道 c1: 啟動全部資料檔案備份集通道 c1: 正在指定備份集中的資料檔案備份集中包括當前控制檔案在備份集中包含當前的 SPFILE通道 c1: 正在啟動段 1 於 11-5月 -07通道 c1: 已完成段 1 於 11-5月 -07段控制程式碼=1riheqhl_1_1 標記=TAG20070511T091922 註釋=API Version 2.0,MMS Version 5.0.0.0通道 c1: 備份集已完成, 經過時間:00:00:57完成 backup 於 11-5月 -07釋放的通道: c1
RMAN>
可以看到備份大約花費了1小時25分鐘左右。
下面嘗試在一個節點上分配兩個CHANNEL來備份:
RMAN> run
2> {
3> allocate channel c1 device type sbt;
4> allocate channel c2 device type sbt;
5> backup database;
6> }
分配的通道: c1通道 c1: sid=296 例項=testrac1 devtype=SBT_TAPE通道c1: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)
分配的通道: c2通道 c2: sid=301 例項=testrac1 devtype=SBT_TAPE通道c2: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)
啟動 backup 於 11-5月 -07通道 c1: 啟動全部資料檔案備份集通道 c1: 正在指定備份集中的資料檔案輸入資料檔案 fno=00006 name=+DISK/testrac/datafile/zhejiang01.dbf輸入資料檔案 fno=00009 name=+DISK/testrac/datafile/zhejiang03.dbf輸入資料檔案 fno=00012 name=+DISK/testrac/datafile/zhejiang05.dbf輸入資料檔案 fno=00008 name=+DISK/testrac/datafile/ndmain01.dbf輸入資料檔案 fno=00010 name=+DISK/testrac/datafile/ndindex01.dbf輸入資料檔案 fno=00001 name=+DISK/testrac/datafile/system.262.618591167輸入資料檔案 fno=00005 name=+DISK/testrac/datafile/users.267.618591279通道 c1: 正在啟動段 1 於 11-5月 -07通道 c2: 啟動全部資料檔案備份集通道 c2: 正在指定備份集中的資料檔案輸入資料檔案 fno=00007 name=+DISK/testrac/datafile/zhejiang02.dbf輸入資料檔案 fno=00011 name=+DISK/testrac/datafile/zhejiang04.dbf輸入資料檔案 fno=00014 name=+DISK/testrac/datafile/zhejiang06.dbf輸入資料檔案 fno=00002 name=+DISK/testrac/datafile/undotbs1.263.618591197輸入資料檔案 fno=00004 name=+DISK/testrac/datafile/undotbs2.266.618591249輸入資料檔案 fno=00013 name=+DISK/testrac/datafile/lt_index_ts01.dbf輸入資料檔案 fno=00003 name=+DISK/testrac/datafile/sysaux.264.618591225通道 c2: 正在啟動段 1 於 11-5月 -07通道 c1: 已完成段 1 於 11-5月 -07段控制程式碼=1siheql7_1_1 標記=TAG20070511T104702 註釋=API Version 2.0,MMS Version 5.0.0.0通道 c1: 備份集已完成, 經過時間:00:42:17通道 c1: 啟動全部資料檔案備份集通道 c1: 正在指定備份集中的資料檔案備份集中包括當前控制檔案通道 c1: 正在啟動段 1 於 11-5月 -07通道 c2: 已完成段 1 於 11-5月 -07段控制程式碼=1tiheql8_1_1 標記=TAG20070511T104702 註釋=API Version 2.0,MMS Version 5.0.0.0通道 c2: 備份集已完成, 經過時間:01:24:33通道 c2: 啟動全部資料檔案備份集通道 c2: 正在指定備份集中的資料檔案在備份集中包含當前的 SPFILE通道 c2: 正在啟動段 1 於 11-5月 -07通道 c1: 已完成段 1 於 11-5月 -07段控制程式碼=1uihet4g_1_1 標記=TAG20070511T104702 註釋=API Version 2.0,MMS Version 5.0.0.0通道 c1: 備份集已完成, 經過時間:00:43:03通道 c2: 已完成段 1 於 11-5月 -07段控制程式碼=1vihevjp_1_1 標記=TAG20070511T104702 註釋=API Version 2.0,MMS Version 5.0.0.0通道 c2: 備份集已完成, 經過時間:00:01:31完成 backup 於 11-5月 -07釋放的通道: c1釋放的通道: c2
RMAN>
發現雖然分配了兩個channel,第一個channel備份用時42分鐘,第二個channel用時仍然達到了1小時24分鐘。也就是說,沒有任何的效能的提高。
備份的同時,用root啟動jnbSA圖形介面,發現只有一個控制器在工作,也就是說,雖然分配了兩個channel,但是兩個channel仍然是序列工作,當第一個備份結束後,開始進行第二個channel的備份工作。所以,總的消耗時間仍然是那麼多。
為了使得兩個控制性同時工作,可以考慮採用分配兩個channel並連線到兩個不同的例項上,方法如下:
RMAN> RUN
2> {
3> ALLOCATE CHANNEL C1 DEVICE TYPE SBT CONNECT ;
4> ALLOCATE CHANNEL C2 DEVICE TYPE SBT CONNECT ;
5> BACKUP DATABASE;
6> }
分配的通道: C1通道 C1: sid=293 例項=testrac1 devtype=SBT_TAPE通道C1: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)
分配的通道: C2通道 C2: sid=289 例項=testrac2 devtype=SBT_TAPE通道C2: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)
啟動 backup 於 11-5月 -07通道 C1: 啟動全部資料檔案備份集通道 C1: 正在指定備份集中的資料檔案輸入資料檔案 fno=00006 name=+DISK/testrac/datafile/zhejiang01.dbf輸入資料檔案 fno=00009 name=+DISK/testrac/datafile/zhejiang03.dbf輸入資料檔案 fno=00012 name=+DISK/testrac/datafile/zhejiang05.dbf輸入資料檔案 fno=00008 name=+DISK/testrac/datafile/ndmain01.dbf輸入資料檔案 fno=00010 name=+DISK/testrac/datafile/ndindex01.dbf輸入資料檔案 fno=00001 name=+DISK/testrac/datafile/system.262.618591167輸入資料檔案 fno=00005 name=+DISK/testrac/datafile/users.267.618591279通道 C1: 正在啟動段 1 於 11-5月 -07通道 C2: 啟動全部資料檔案備份集通道 C2: 正在指定備份集中的資料檔案輸入資料檔案 fno=00007 name=+DISK/testrac/datafile/zhejiang02.dbf輸入資料檔案 fno=00011 name=+DISK/testrac/datafile/zhejiang04.dbf輸入資料檔案 fno=00014 name=+DISK/testrac/datafile/zhejiang06.dbf輸入資料檔案 fno=00002 name=+DISK/testrac/datafile/undotbs1.263.618591197輸入資料檔案 fno=00004 name=+DISK/testrac/datafile/undotbs2.266.618591249輸入資料檔案 fno=00013 name=+DISK/testrac/datafile/lt_index_ts01.dbf輸入資料檔案 fno=00003 name=+DISK/testrac/datafile/sysaux.264.618591225通道 C2: 正在啟動段 1 於 11-5月 -07通道 C2: 已完成段 1 於 11-5月 -07段控制程式碼=21ihf3gn_1_1 標記=TAG20070511T131819 註釋=API Version 2.0,MMS Version 5.0.0.0通道 C2: 備份集已完成, 經過時間:00:41:01通道 C2: 啟動全部資料檔案備份集通道 C2: 正在指定備份集中的資料檔案備份集中包括當前控制檔案通道 C2: 正在啟動段 1 於 11-5月 -07通道 C2: 已完成段 1 於 11-5月 -07段控制程式碼=22ihf5tl_1_1 標記=TAG20070511T131819 註釋=API Version 2.0,MMS Version 5.0.0.0通道 C2: 備份集已完成, 經過時間:00:01:06通道 C2: 啟動全部資料檔案備份集通道 C2: 正在指定備份集中的資料檔案在備份集中包含當前的 SPFILE通道 C2: 正在啟動段 1 於 11-5月 -07通道 C2: 已完成段 1 於 11-5月 -07段控制程式碼=23ihf5vn_1_1 標記=TAG20070511T131819 註釋=API Version 2.0,MMS Version 5.0.0.0通道 C2: 備份集已完成, 經過時間:00:01:07通道 C1: 已完成段 1 於 11-5月 -07段控制程式碼=20ihf3gs_1_1 標記=TAG20070511T131819 註釋=API Version 2.0,MMS Version 5.0.0.0通道 C1: 備份集已完成, 經過時間:00:44:39完成 backup 於 11-5月 -07釋放的通道: C1釋放的通道: C2
RMAN>
這種方法進行備份,每個節點會備份一部分資料檔案,從圖形介面觀察,兩個控制器同時工作,從最終的備份時間也可以看出,整個備份僅用了44分鐘左右,執行時間縮短了一半。
由於對硬體和備份軟體都不是很熟悉,不清楚是否一個節點只能使用一個控制器。不過,對於這種預設的情況,RAC環境可以透過最後的這種方式來提高備份的效能。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4227/viewspace-69272/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- RMAN備份恢復效能優化優化
- rman 增量備份恢復
- RMAN備份恢復技巧
- ORACLE DG從庫 Rman備份恢復Oracle
- RMAN備份恢復典型案例——RMAN備份&系統變慢
- RMAN備份異機恢復
- RMAN備份與恢復測試
- 備份與恢復:polardb資料庫備份與恢復資料庫
- Oracle 備份恢復篇之RMAN catalogOracle
- rman備份異機恢復(原創)
- RMAN備份恢復典型案例——資料庫卡頓資料庫
- 12 使用RMAN備份和恢復檔案
- RMAN備份恢復典型案例——ORA-00245
- RAC備份恢復之Voting備份與恢復
- RMAN備份恢復典型案例——異機恢復未知DBID
- 資料庫備份恢復資料庫
- Windows oracle 11g rman備份恢復到linux系統WindowsOracleLinux
- 備份恢復Lesson 04.Using the RMAN Recovery Catalog
- 在DG備庫備份資料庫並恢復到一個主機上,報錯RMAN-06820資料庫
- MySQL備份與恢復——基於Xtrabackup物理備份恢復MySql
- 【RMAN】在多租戶環境下的RMAN備份及恢復
- Mysql備份與恢復(1)---物理備份MySql
- mydumper備份恢復
- Mysql備份恢復MySql
- 備份和恢復
- GitLab的自動備份、清理備份與恢復Gitlab
- 透過RMAN備份standby database成功恢復還原Database
- dg丟失歸檔,使用rman增量備份恢復
- Mysql備份與恢復(2)---邏輯備份MySql
- 【RMAN】Oracle12c以後rman 備份恢復命令參考Oracle
- 使用RMAN備份資料庫資料庫
- PostgreSql資料庫的備份和恢復SQL資料庫
- 詳解叢集級備份恢復:物理細粒度備份恢復
- MySQL備份與恢復——基於MyDumper/MyLoader 邏輯備份恢復MySql
- RMAN的備份原理
- 利用innobackupex備份集恢復指定庫
- Mysql資料庫備份及恢復MySql資料庫
- 達夢資料庫備份恢復資料庫
- postgresql備份與恢復資料庫SQL資料庫