[20161031]rman備份與資料檔案變化2.txt
[20161031]rman備份與資料檔案變化2.txt
--想象一下，如果備份檔案時間很長，而這個時候資料檔案大小發生了變化，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 10M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;
--注意要選擇LOGGING。第1次沒有選擇，測試存在錯誤，浪費了時間。
SCOTT@book> create table t1 tablespace sugar as select rownum id ,lpad('A',32,'A') name from dual connect by level<=1e5;
Table created.
SCOTT@book> select sum(bytes) from dba_extents where owner=user and segment_name='T1';
SUM(BYTES)
------------
5242880
--大約佔用5242880/1024/1024=5M.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 10493952 2016-10-31 16:28:13 /mnt/ramdisk/book/sugar01.dbf
--當前大小10M+8k。 10*1024*1024+8192=10493952.
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_1_%U' ;
.....
--切換會話建立新表T2,T3。
create table t2 tablespace sugar as select rownum id ,lpad('B',32,'B') name from dual connect by level<=2e5;
--等1-2秒...
create table t3 tablespace sugar as select rownum id ,lpad('C',32,'C') name from dual connect by level<=2e5;
alter system checkponit;
$ ls -l /u01/backup/d6_1*
-rw-r----- 1 oracle oinstall 10518528 2016-10-31 16:45:06 /u01/backup/d6_1_0srjoknq_1_1
--可以發現是先產生備份檔案的大小，然後再寫入操作。
RMAN> backup datafile 6 format '/u01/backup/d6_1_%U' ;
Starting backup at 2016-10-31 16:44:41
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=46 device type=DISK
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-10-31 16:44:42
channel ORA_DISK_1: finished piece 1 at 2016-10-31 16:46:07
piece handle=/u01/backup/d6_1_0srjoknq_1_1 tag=TAG20161031T164442 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:25
channel ORA_DISK_1: throttle time: 0:01:20
Finished backup at 2016-10-31 16:46:07
--需要將近1分20秒.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 27271168 2016-10-31 16:44:53 /mnt/ramdisk/book/sugar01.dbf
$ ls -l /u01/backup/d6_1*
-rw-r----- 1 oracle oinstall 6111232 2016-10-31 16:46:02 /u01/backup/d6_1_0srjoknq_1_1
--備份檔案大小6111232/1024/1024=5.828125M,比開始生成的小。因為有一些是"NULL"塊，我之所以帶引號，主要是指先讀點陣圖資訊，已
--經確定要掃描那些塊。實際上那些塊已經有資料寫入。
--而現在資料檔案已經是 27271168/1024/1024=26.0078125M.
--如果你查詢BBBB，CCCC字串可以發現根本不存在，也就是講備份並沒有做
$ strings /u01/backup/d6_1* | grep 'BBBB'
$ strings /u01/backup/d6_1* | grep 'CCCC'
$ strings /u01/backup/d6_1_0srjoknq_1_1 | grep 'AAAA'|wc
100000 170040 3624269
SCOTT@book> select file#,CHECKPOINT_CHANGE#,ABSOLUTE_FUZZY_CHANGE# from v$backup_datafile;
FILE# CHECKPOINT_CHANGE# ABSOLUTE_FUZZY_CHANGE#
----- ------------------ ----------------------
6 2374086 0
--而且備份期間沒有出現高於檢查點scn高於2374086的scn號。
SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE# , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name FROM v$datafile_header where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME CREATION_CHANGE# RESETLOGS_CHANGE# STATUS CHECKPOINT_COUNT FUZ NAME TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------------------------- ------------------------------
6 2374228 2016-10-31 16:44:53 2373657 2002065 ONLINE 4 YES /mnt/ramdisk/book/sugar01.dbf SUGAR
--從這裡可以看出備份時視乎已經確定要備份檔案的大小，而且我覺得備份期間讀取了點陣圖資訊，僅僅非NULL的塊已經確定，應該是從檔案頭確定，而不管資料檔案是否增加變大。
--你可以看出我已經發出了檢查點，但是T2的資訊，T3的資訊並沒有出現備份集中。
3.繼續看看資料檔案頭在備份集什麼位置：
--透過bbed觀察：
BBED> set dba 6,1
DBA 0x01800001 (25165825 6,1)
BBED> p kcvfh.kcvfhtln
ub2 kcvfhtln @336 0x0005
BBED> p kcvfh.kcvfhtnm
text kcvfhtnm[0] @338 S
text kcvfhtnm[1] @339 U
text kcvfhtnm[2] @340 G
text kcvfhtnm[3] @341 A
text kcvfhtnm[4] @342 R
text kcvfhtnm[5] @343
--可以發現表資料檔案裡面記錄了表空間名字。前面一個欄位kcvfh.kcvfhtln記錄表空間名長度，正好是5。
$ strings -t d /u01/backup/d6_1_0srjoknq_1_1 | grep SUGAR
6095186 SUGAR
-- 6095186/8192=744.041259765625,相關記錄在備份集中744塊。也就是檔案頭最後寫入備份集中。
-- 而實際備份集檔案大小6111232, 6111232/8192=746塊。也就是除掉備份集塊頭有745塊(備份集也有1個OS塊)
BBED> set filename '/u01/backup/d6_1_0srjoknq_1_1'
FILENAME /u01/backup/d6_1_0srjoknq_1_1
BBED> set block 744
BLOCK# 744
BBED> p kcvfh.kcvfhtln
ub2 kcvfhtln @336 0x0005
BBED> p kcvfh.kcvfhtnm
text kcvfhtnm[0] @338 S
text kcvfhtnm[1] @339 U
text kcvfhtnm[2] @340 G
text kcvfhtnm[3] @341 A
text kcvfhtnm[4] @342 R
text kcvfhtnm[5] @343
...
BBED> set block 746
BBED-00309: out of range block number (746)
BBED> set block 745
BLOCK# 745
BBED> set block 744
BLOCK# 1350
BBED> p /d kcvfh.kcvfhcrs.kscnbas
ub4 kscnbas @100 2373657
BBED> p /d kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas @484 2374086
--//這個結果與資料塊對應：
BBED> p /d dba 6,1 kcvfh.kcvfhcrs.kscnbas
ub4 kscnbas @100 2373657
BBED> p /d dba 6,1 kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas @484 2374228
--看看資料檔案大小：
BBED> p /d dba 6,1 kcvfhhdr.kccfhfsz
ub4 kccfhfsz @44 5376
-- 5376*8192+8192=44048384
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 44048384 2016-10-31 12:10:13 /mnt/ramdisk/book/sugar01.dbf
--昏，估計觸發了後臺的11g表空間pre-allocation。現在變成26+16 =42M
--44048384-8192=44040192
--44040192/1024/1024=42M
BBED> p /d filename '/u01/backup/d6_1_0srjoknq_1_1' block 744 kcvfhhdr.kccfhfsz
ub4 kccfhfsz @44 1280
--1280*8192=10485760
--10485760/1024/1024=10M
--不過從這裡看出是最後寫檔案頭資訊到備份集中的。
4.測試恢復看看：
SCOTT@book> alter database datafile 6 offline ;
Database altered.
RMAN> restore datafile 6;
Starting restore at 2016-10-31 17:04:53
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_1_0srjoknq_1_1
channel ORA_DISK_1: piece handle=/u01/backup/d6_1_0srjoknq_1_1 tag=TAG20161031T164442
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2016-10-31 17:04:54
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 10493952 2016-10-31 17:04:53 /mnt/ramdisk/book/sugar01.dbf
$ strings /mnt/ramdisk/book/sugar01.dbf | grep BBBB
$ strings /mnt/ramdisk/book/sugar01.dbf | grep CCCC
--可以發現沒有記錄表T2,T3.
RMAN> recover datafile 6 ;
Starting recover at 2016-10-31 17:05:51
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2016-10-31 17:05:51
$ strings /mnt/ramdisk/book/sugar01.dbf | grep BBBB|wc
200000 340080 7243181
$ strings /mnt/ramdisk/book/sugar01.dbf | grep CCCC|wc
200000 340080 7243181
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 44048384 2016-10-31 17:05:51 /mnt/ramdisk/book/sugar01.dbf
--可以看到已經恢復。
SCOTT@book> alter database datafile 6 online ;
Database altered.
SCOTT@book> select rowid from t3 where rownum=1;
ROWID
------------------
AAAVsHAAGAAAAgDAAA
SCOTT@book> select rowid from t2 where rownum=1;
ROWID
------------------
AAAVsGAAGAAAAMDAAA
總結：
1.測試有一些亂，包括思路都有點亂。
2.我僅僅猜測備份時，檔案大小就已經確定，最多10M。而具體讀取那些塊，我估計已經透過點陣圖確定下來。
你可以看到即使我發了alter system checkpoint命令，T2表的資訊依舊沒有備份。
3.我做了資料檔案增加的情況，資料檔案縮小有發生什麼情況呢？看下一篇blog.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2127386/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20161031]rman備份與資料檔案變化3.txt
- [20161031]rman備份與資料檔案OS塊.txt
- RMAN說，我能備份(4)--RMAN備份資料檔案和控制檔案
- [20161101]rman備份與資料檔案變化4.txt
- [20161102]rman備份與資料檔案變化5.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資料庫
- 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在歸檔與非歸檔時備份資料庫的簡單示例資料庫