[20161102]rman備份與資料檔案變化5.txt
[20161102]rman備份與資料檔案變化5.txt
--想象一下，如果備份檔案時間很長，而這個時候資料檔案大小發生了變化，oracle的備份如何解決這個問題呢？
--前面我已經做了增大資料檔案，參考連結：http://blog.itpub.net/267265/viewspace-2127386/
--這次測試減少資料檔案大小看看。相關連結：
http://blog.itpub.net/267265/viewspace-2127424/
http://blog.itpub.net/267265/viewspace-2127396/
http://blog.itpub.net/267265/viewspace-2127386/
--昨天的測試思路很亂,我有點搞不清楚為什麼第2次備份依舊很大,跟我對rman的理解不吻合.
$ ls -l /u01/backup/d6_*
-rw-r----- 1 oracle oinstall 26083328 2016-11-01 11:25:05 /u01/backup/d6_X_1drjqm2h_1_1
-rw-r----- 1 oracle oinstall 21880832 2016-11-01 11:42:16 /u01/backup/d6_Y_1grjqn2o_1_1
--在回家的路上我才想起來,問題在那裡,兩個備份大約相差4M，實際上10M以上的非空塊,雖然在前面的點陣圖塊已經為0(標識未使用),
--但是屬於異常情況,oracle認為只要是格式化的塊,就都做了備份.還是重複做例子來說明問題.
1.環境：
SCOTT@book> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
CREATE TABLESPACE SUGAR DATAFILE
'/mnt/ramdisk/book/sugar01.dbf' SIZE 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;
create table t1 tablespace sugar as select rownum id ,to_char(rownum,'000000')||lpad('A',26,'A') name from dual connect by level<=1e5;
--建立大小5M的表。
create table t2 tablespace sugar as select rownum id ,to_char(rownum,'000000')||lpad('B',26,'B') name from dual connect by level<=2e5;
create table t3 tablespace sugar as select rownum id ,to_char(rownum,'000000')||lpad('C',26,'C') name from dual connect by level<=2e5;
alter system checkpoint;
--一些細節不再重複了.....
2.備份：
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 128 K;
new RMAN configuration parameters:
CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 128 K;
new RMAN configuration parameters are successfully stored
--//主要目的減慢備份速度。
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored
--開始備份：
RMAN> backup datafile 6 format '/u01/backup/d6_AA_%U' ;
.....
--切換會話刪除表T2,T3,操作有點多，寫入1個指令碼abc.sql執行它。
drop table t2 purge ;
host sleep 1.5
drop table t3 purge ;
host sleep 1
alter system checkpoint;
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
alter system checkpoint;
--指令碼執行期間遇到
SCOTT@book> @ abc.sql
Table dropped.
Table dropped.
System altered.
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M
*
ERROR at line 1:
ORA-19567: cannot shrink file /mnt/ramdisk/book/sugar01.dbf because it is being backed up or copied
System altered.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-02 11:46:32 /mnt/ramdisk/book/sugar01.dbf
==============
$ oerr ora 19567
19567, 00000, "cannot shrink file %s because it is being backed up or copied"
// *Cause: An ALTER statement attempted to reduce the size of the indicated
// file while the same file is being backed up or copied.
// *Action: Retry the resize after the backup or copy is complete.
====================================
--我個人認為這個是一個bug.實際上這個時候查詢檢視DBA_DATA_FILES已經出現異常.
SCOTT@book> select * from DBA_DATA_FILES;
FILE_NAME FILE_ID TABLESPACE_NAME BYTES BLOCKS STATUS RELATIVE_FNO AUT MAXBYTES MAXBLOCKS INCREMENT_BY USER_BYTES USER_BLOCKS ONLINE_
------------------------------- ------- --------------- ---------- ---------- --------- ------------ --- ---------- ---------- ------------ ---------- ----------- -------
/mnt/ramdisk/book/users01.dbf 4 USERS 52428800 6400 AVAILABLE 4 YES 3.4360E+10 4194302 160 51380224 6272 ONLINE
/mnt/ramdisk/book/undotbs01.dbf 3 UNDOTBS1 89128960 10880 AVAILABLE 3 YES 1073741824 131072 640 88080384 10752 ONLINE
/mnt/ramdisk/book/sysaux01.dbf 2 SYSAUX 817889280 99840 AVAILABLE 2 YES 3.4360E+10 4194302 1280 816840704 99712 ONLINE
/mnt/ramdisk/book/system01.dbf 1 SYSTEM 786432000 96000 AVAILABLE 1 YES 3.4360E+10 4194302 1280 785383424 95872 SYSTEM
/mnt/ramdisk/book/example01.dbf 5 EXAMPLE 328335360 40080 AVAILABLE 5 YES 3.4360E+10 4194302 80 327286784 39952 ONLINE
/mnt/ramdisk/book/sugar01.dbf 6 SUGAR 10485760 1280 AVAILABLE 6 YES 3.4360E+10 4194302 2048 9437184 1152 ONLINE
6 rows selected.
--但是檔案大小沒有改變。
RMAN> backup datafile 6 format '/u01/backup/d6_AA_%U' ;
Starting backup at 2016-11-02 11:46:21
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-11-02 11:46:21
channel ORA_DISK_1: finished piece 1 at 2016-11-02 11:51:46
piece handle=/u01/backup/d6_AA_1srjtc0d_1_1 tag=TAG20161102T114621 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:05:25
channel ORA_DISK_1: throttle time: 0:05:20
Finished backup at 2016-11-02 11:51:46
Starting Control File and SPFILE Autobackup at 2016-11-02 11:51:46
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2016_11_02/o1_mf_s_926855506_d1lrpll2_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2016-11-02 11:51:47
--需要將近5分20秒.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-02 11:46:32 /mnt/ramdisk/book/sugar01.dbf
--可以發現檔案並沒有shrink到10m。
$ strings -t d /u01/backup/d6_AA_1srjtc0d_1_1 | grep AAAA |wc
100000 301360 4524254
$ strings -t d /u01/backup/d6_AA_1srjtc0d_1_1 | grep BBBB |wc
200000 602720 9169972
$ strings -t d /u01/backup/d6_AA_1srjtc0d_1_1 | grep CCCC |wc
200000 602720 9243626
--可以發現T2,T3表的資訊也做了備份。
3.繼續做一個備份：
RMAN> backup datafile 6 format '/u01/backup/d6_BB_%U' diskratio=0;
Starting backup at 2016-11-02 12:00:38
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-11-02 12:00:38
channel ORA_DISK_1: finished piece 1 at 2016-11-02 12:06:03
piece handle=/u01/backup/d6_BB_1urjtcr6_1_1 tag=TAG20161102T120038 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:05:25
channel ORA_DISK_1: throttle time: 0:05:20
Finished backup at 2016-11-02 12:06:03
Starting Control File and SPFILE Autobackup at 2016-11-02 12:06:03
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2016_11_02/o1_mf_s_926856363_d1lskcp2_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2016-11-02 12:06:04
--忘記重新設定disk rate了。
$ ls -l /u01/backup/d6*
-rw-r----- 1 oracle oinstall 26681344 2016-11-02 11:51:41 /u01/backup/d6_AA_1srjtc0d_1_1
-rw-r----- 1 oracle oinstall 22478848 2016-11-02 12:05:58 /u01/backup/d6_BB_1urjtcr6_1_1
$ strings -t d /u01/backup/d6_BB_1urjtcr6_1_1 | grep AAAA |wc
100000 301360 4524254
[oracle@gxqyydg4 IP=100.78 ~/0729/0901 103]$ strings -t d /u01/backup/d6_BB_1urjtcr6_1_1 | grep BBBB |wc
118416 356880 5401085
[oracle@gxqyydg4 IP=100.78 ~/0729/0901 104]$ strings -t d /u01/backup/d6_BB_1urjtcr6_1_1 | grep CCCC |wc
200000 602720 9243626
--可以發現備份依舊備份T2.T3表的塊。備份檔案大小並沒有縮小多少。
-- 26681344 - 22478848=4202496 , 4202496/8192=513塊，大約4M。
$ strings -t d /u01/backup/d6_BB_1urjtcr6_1_1 | grep BBBB | head
6227229 1! 081748BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227271 0! 081747BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227313 /! 081746BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227355 .! 081745BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227397 -! 081744BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227439 ,! 081743BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227481 +! 081742BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227523 *! 081741BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227565 )! 081740BBBBBBBBBBBBBBBBBBBBBBBBBB,
6227607 (! 081739BBBBBBBBBBBBBBBBBBBBBBBBBB,
)
-- 6227229/8192=760.1597900390625,可以發現在備份塊760.
-- 如果前面10M按照正常的讀取點陣圖區的話，那麼10*1024*1024/8192+1=1281,那麼備份塊760備份應該是資料檔案的128x塊(可能有assm的點陣圖)。
-- 驗證看看我的判斷是否正常。
BBED> set filename '/u01/backup/d6_BB_1urjtcr6_1_1'
FILENAME /u01/backup/d6_BB_1urjtcr6_1_1
BBED> set block 760
BLOCK# 760
BBED> p rdba_kcbh
ub4 rdba_kcbh @4 0x018005f8
SCOTT@book> @ &r/dfb16 0x018005f8
RFILE# BLOCK# TEXT
---------- ---------- ------------------------------------------------------------
6 1528 alter system dump datafile 6 block 1528 ;
--we@#$%,不對。
$ ls -l /u01/backup/d6*
-rw-r----- 1 oracle oinstall 26681344 2016-11-02 11:51:41 /u01/backup/d6_AA_1srjtc0d_1_1
-rw-r----- 1 oracle oinstall 22478848 2016-11-02 12:05:58 /u01/backup/d6_BB_1urjtcr6_1_1
--26681344 - 22478848=4202496, 4202496/8192=513 相差513，大約4M。
--備份表T2的記錄是118416，佔118416/200000=.59208,0.59*10=5.9M,大約佔6M，證明我的分析方法沒有問題。
--直接掃描資料檔案看看。
$ strings -t d /mnt/ramdisk/book/sugar01.dbf | grep 081748BBBBBBBBBBBBBBBBBBBBBBBBBB
10503453 1! 081748BBBBBBBBBBBBBBBBBBBBBBBBBB,
SCOTT@book> select 10503453/8192 from dual;
10503453/8192
-------------
1282.15979
BBED> x /rnc dba 6,1282 *kdbr[163]
rowdata[0] @1302
----------
flag@1302: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@1303: 0x00
cols@1304: 2
col 0[4] @1305: 81748
col 1[33] @1310: 081748BBBBBBBBBBBBBBBBBBBBBBBBBB
--說明資料從塊底部開始插入，所以這條記錄應該是這塊的最後1條。所以訪問的是*kdbr[163]
--這裡有問題，為什麼這條記錄的資料檔案的偏移在1282塊，這個是符合我的推測的，但是rman備份集的記錄為什麼是1528塊呢？
BBED> set filename '/u01/backup/d6_BB_1urjtcr6_1_1'
FILENAME /u01/backup/d6_BB_1urjtcr6_1_1
BBED> p block 760 rdba_kcbh
ub4 rdba_kcbh @4 0x018005f8
BBED> p block 761 rdba_kcbh
ub4 rdba_kcbh @4 0x018005f9
BBED> p block 762 rdba_kcbh
ub4 rdba_kcbh @4 0x018005fa
BBED> p block 763 rdba_kcbh
ub4 rdba_kcbh @4 0x018005fb
BBED> p block 764 rdba_kcbh
ub4 rdba_kcbh @4 0x018005fc
BBED> p block 765 rdba_kcbh
ub4 rdba_kcbh @4 0x018005fd
BBED> p block 766 rdba_kcbh
ub4 rdba_kcbh @4 0x018005fe
BBED> p block 767 rdba_kcbh
ub4 rdba_kcbh @4 0x018005ff
BBED> p block 768 rdba_kcbh
ub4 rdba_kcbh @4 0x01800580
BBED> p block 769 rdba_kcbh
ub4 rdba_kcbh @4 0x01800581
--出現一個我認為奇怪的情況備份的塊dba是0x01800580,比前面0x018005f8小。
BBED> set block 768
BLOCK# 768
BBED> x /rnc *kdbr[0]
rowdata[6844] @8146
-------------
flag@8146: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8147: 0x00
cols@8148: 2
col 0[4] @8149: 82897
col 1[33] @8154: 082897BBBBBBBBBBBBBBBBBBBBBBBBBB
--而這個記錄id=82897.明顯在資料檔案這個塊應該在name=' 081748BBBBBBBBBBBBBBBBBBBBBBBBBB'之後。
--為此我建立的相似的表空間，按照前面的順序建立表。
CREATE TABLESPACE tea DATAFILE
'/mnt/ramdisk/book/sugar01.dbf' SIZE 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;
create table ta tablespace sugar as select rownum id ,to_char(rownum,'000000')||lpad('A',26,'A') name from dual connect by level<=1e5;
create table tb tablespace sugar as select rownum id ,to_char(rownum,'000000')||lpad('B',26,'B') name from dual connect by level<=2e5;
create table tc tablespace sugar as select rownum id ,to_char(rownum,'000000')||lpad('C',26,'C') name from dual connect by level<=2e5;
alter system checkpoint;
SCOTT@book> select rowid x,tb.* from tb where id in (82897,81748);
X ID NAME
------------------------------ ---------- ---------------------------------
AAAVsjAAHAAAAUCACj 81748 081748BBBBBBBBBBBBBBBBBBBBBBBBBB
AAAVsjAAHAAAAUKAAA 82897 082897BBBBBBBBBBBBBBBBBBBBBBBBBB
SCOTT@book> @ &r/rowid AAAVsjAAHAAAAUCACj
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------
88867 7 1282 163 0x1C00502 7,1282 alter system dump datafile 7 block 1282
SCOTT@book> @ &r/rowid AAAVsjAAHAAAAUKAAA
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------
88867 7 1290 0 0x1C0050A 7,1290 alter system dump datafile 7 block 1290
--很明顯位置不對。
4.利用備份恢復就明白了：
SCOTT@book> alter tablespace sugar offline ;
Tablespace altered.
--移動做保留，方便比較。
$ mv sugar01.dbf /u01/backup/
RMAN> restore tablespace sugar;
Starting restore at 2016-11-03 09:42:11
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00006 to /mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: reading from backup piece /u01/backup/d6_BB_1urjtcr6_1_1
channel ORA_DISK_1: piece handle=/u01/backup/d6_BB_1urjtcr6_1_1 tag=TAG20161102T120038
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 2016-11-03 09:42:13
BBED> x /rnc dba 6,1528 *kdbr[163]
rowdata[0] @1301
----------
flag@1301: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@1302: 0x00
cols@1303: 2
col 0[4] @1304: 121764
col 1[33] @1309: 121764BBBBBBBBBBBBBBBBBBBBBBBBBB
BBED> x /rnc dba 6,1282 *kdbr[163]
rowdata[0] @1302
----------
flag@1302: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@1303: 0x00
cols@1304: 2
col 0[4] @1305: 81748
col 1[33] @1310: 081748BBBBBBBBBBBBBBBBBBBBBBBBBB
BBED> x /rnc dba 6,1290 *kdbr[0]
rowdata[6844] @8146
-------------
flag@8146: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8147: 0x00
cols@8148: 2
col 0[4] @8149: 82897
col 1[33] @8154: 082897BBBBBBBBBBBBBBBBBBBBBBBBBB
--寫回來還是對的。
--從這裡可以看出：資料檔案10M以前的資訊應該透過點陣圖確定來備份，而10M以上的塊這個時候按照已經格式化的塊做備份。
5.再看看前面的第1次備份的情況：
$ strings -t d /u01/backup/d6_AA_1srjtc0d_1_1 | grep 081748BBBBBBBBBBBBBBBBBBBBBBBBBB
10413341 1! 081748BBBBBBBBBBBBBBBBBBBBBBBBBB,
-- 10413341/8192=1271.1597900390625,位於1271塊中。
BBED> set filename '/u01/backup/d6_AA_1srjtc0d_1_1'
FILENAME /u01/backup/d6_AA_1srjtc0d_1_1
BBED> p block 1271 rdba_kcbh
ub4 rdba_kcbh @4 0x018005f7
BBED> set dba 0x018005f7
DBA 0x018005f7 (25167351 6,1527)
--在dba6，1527明顯也是不對的。正常記錄應該在6，1282.
BBED> x /rnc filename '/u01/backup/d6_AA_1srjtc0d_1_1' block 1271 *kdbr[163]
rowdata[0] @1302
----------
flag@1302: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@1303: 0x00
cols@1304: 2
col 0[4] @1305: 81748
col 1[33] @1310: 081748BBBBBBBBBBBBBBBBBBBBBBBBBB
BBED> x /rnc dba 6,1282 *kdbr[163]
rowdata[0] @1302
----------
flag@1302: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@1303: 0x00
cols@1304: 2
col 0[4] @1305: 81748
col 1[33] @1310: 081748BBBBBBBBBBBBBBBBBBBBBBBBBB
$ strings -t d /u01/backup/d6_AA_1srjtc0d_1_1 | grep 099990AAAAAAAAAAAA
6191558 d[! 099990AAAAAAAAAAAAAAAAAAAAAAAAAA,
--6191558/8192=755.805419921875
BBED> x /rnc filename '/u01/backup/d6_AA_1srjtc0d_1_1' block 755 *kdbr[37]
rowdata[418] @6592
------------
flag@6592: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@6593: 0x00
cols@6594: 2
col 0[4] @6595: 99990
col 1[33] @6600: 099990AAAAAAAAAAAAAAAAAAAAAAAAAA
BBED> p filename '/u01/backup/d6_AA_1srjtc0d_1_1' block 755 rdba_kcbh
ub4 rdba_kcbh @4 0x018002f3
BBED> x /rnc dba 0x018002f3 *kdbr[37]
BBED-00400: invalid blocktype (00)
BBED> x /rnc dba 0x018002f2 *kdbr[37]
rowdata[418] @6592
------------
flag@6592: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@6593: 0x00
cols@6594: 2
col 0[4] @6595: 99990
col 1[33] @6600: 099990AAAAAAAAAAAAAAAAAAAAAAAAAA
--也不對，難道備份是要重新編碼嗎？也許這點是我錯了。而且為什麼變成這樣，搞不懂................
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2127569/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20161031]rman備份與資料檔案變化3.txt
- [20161031]rman備份與資料檔案變化2.txt
- RMAN說，我能備份(4)--RMAN備份資料檔案和控制檔案
- [20161101]rman備份與資料檔案變化4.txt
- [20171123]rman備份與資料檔案變化6.txt
- [20161101]rman備份與資料檔案變化7.txt
- RMAN備份資料檔案+控制檔案+歸檔日誌
- rman備份-（1） 利用備份級恢復資料檔案和控制檔案
- rman備份但丟失一個資料檔案,但有歸檔備份
- rman備份恢復-rman恢復資料檔案測試
- RMAN說，我能備份(5)--RMAN備份歸檔檔案
- RMAN備份檔案格式
- 非歸檔資料庫RMAN備份資料庫
- rman恢復資料庫--用備份的控制檔案資料庫
- rman備份檔案的格式
- Backup And Recovery User's Guide-備份資料庫-使用RMAN備份資料庫檔案GUIIDE資料庫
- [20161031]rman備份與資料檔案OS塊.txt
- rman全庫備份備份歸檔日誌檔案
- Backup And Recovery User's Guide-備份資料庫-使用RMAN備份控制檔案GUIIDE資料庫
- RMAN備份恢復典型案例——資料檔案存在壞快
- 非系統資料檔案損壞，rman備份恢復
- RMAN 驗證 資料檔案 和 備份 的有效性
- [20121127]rman備份資料檔案大小與truncate.txt
- Oracle RMAN 不完全恢復（只有資料檔案備份，丟失歸檔日誌備份）Oracle
- RMAN備份檔案遠大於資料庫大小的原因分析資料庫
- Backup And Recovery User's Guide-備份資料庫-使用RMAN備份表空間和資料檔案GUIIDE資料庫
- 基於oracle 11.2.0.4 rman data file copy以及增量scn備份資料檔案持續變化系列之一Oracle
- 基於oracle 11.2.0.4 rman data file copy以及增量scn備份資料檔案持續變化系列之二Oracle
- 用rman建立dataguard備用資料庫繼續(無法找到備份檔案)資料庫
- ORACLE 只讀資料檔案備份與恢復Oracle
- 【備份恢復】歸檔模式下丟失系統關鍵資料檔案 利用RMAN備份恢復模式
- rman資料庫全庫備份與恢復資料庫
- Oracle資料庫備份與恢復之RMANOracle資料庫
- 使用RMAN備份資料庫資料庫
- 【備份】RMAN中對控制檔案的幾種備份方法
- rman恢復--歸檔模式有備份，丟失資料檔案的恢復模式
- rman恢復--歸檔模式無備份，丟失資料檔案的恢復模式
- rman在歸檔與非歸檔時備份資料庫的簡單示例資料庫