[20171123]rman備份與資料檔案變化6.txt
[20171123]rman備份與資料檔案變化6.txt
--//想象一下，如果備份檔案時間很長，而這個時候資料檔案大小發生了變化，oracle的備份如何解決這個問題呢？
--//去年已經測試了建立備份集的情況,一直想做一次image copy的測試,一直脫,主要原因自己不想做這個測試....
--//而且當時的測試很亂,自己主要一邊做一邊想....
--//連結:
http://blog.itpub.net/267265/viewspace-2127386/
http://blog.itpub.net/267265/viewspace-2127569/
http://blog.itpub.net/267265/viewspace-2127424/
http://blog.itpub.net/267265/viewspace-2127396/
--//本次測試在做image copy時,資料檔案增加的情況,實際上根據前面的測試可以想像備份檔案的大小不應該隨資料檔案大小而變化,
--//因為備份前要建立SNAPSHOT CONTROLFILE,一般以這個控制檔案為準做的備份.
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 2017-11-23 09:14:20 /mnt/ramdisk/book/sugar01.dbf
--//當前大小10M+8k。 10*1024*1024+8192=10493952.
2.備份前準備以及備份：
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 128 K;
using target database control file instead of recovery catalog
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
3.開始備份：
--//建立測試指令碼:
$ cat df_change.sh
#! /bin/bash
rman target / <<EOF &
backup as copy datafile 7 format '/home/oracle/backup/%b' ;
quit
EOF
echo 'sleep 56 '
sleep 56
sqlplus scott/book <<EOF
create table t2 tablespace sugar as select rownum id ,lpad('B',32,'B') name from dual connect by level<=2e5;
create table t3 tablespace sugar as select rownum id ,lpad('C',32,'C') name from dual connect by level<=2e5;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
EOF
--//說明備份10M檔案,前面1M是OS塊,檔案頭,點陣圖區,加上t1表5M,我選擇備份到7M時開始建立表並且擴充套件表空間.
--//7*1024/128=56,備份到這個位置需要56秒.T2,T3大約每個佔10M,這樣需要1+5+10+10=26M,因為這個過程可能要觸發pre-allocation,
--//這樣最後的資料檔案要再加16M(表空間定義AUTOEXTEND ON NEXT 16M),大約42M上下.
$ . df_change.sh
sleep 56
Recovery Manager: Release 11.2.0.4.0 - Production on Thu Nov 23 09:15:07 2017
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: BOOK (DBID=1337401710)
RMAN>
Starting backup at 2017-11-23 09:15:08
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=144 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00007 name=/mnt/ramdisk/book/sugar01.dbf
--//.....等56秒
SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 23 09:16:03 2017
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SCOTT@book>
Table created.
SCOTT@book>
Table created.
SCOTT@book>
System altered.
SCOTT@book>
System altered.
SCOTT@book>
System altered.
SCOTT@book>
System altered.
SCOTT@book> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
--//等剩下的備份結束...
With the Partitioning, OLAP, Data Mining and Real Application Testing options
$ output file name=/home/oracle/backup/sugar01.dbf tag=TAG20171123T091509 RECID=35 STAMP=960801389
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:25
channel ORA_DISK_1: throttle time: 0:01:20
Finished backup at 2017-11-23 09:16:34
Starting Control File and SPFILE Autobackup at 2017-11-23 09:16:34
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2017_11_23/o1_mf_s_960801394_f1d8cl9h_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2017-11-23 09:16:35
RMAN>
Recovery Manager complete.
[1]+ Done rman target / <<EOF
backup as copy datafile 7 format '/home/oracle/backup/%b' ;
quit
EOF
--//在備份中間觀察:
$ ls -l sugar01.dbf
-rw-r----- 1 oracle oinstall 10493952 2017-11-23 09:03:26 sugar01.dbf
--//可以發現先生成10M的image copy.
--//完成後分析:
$ ls -l /mnt/ramdisk/book/sugar01.dbf /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 10493952 2017-11-23 09:16:29 /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 27271168 2017-11-23 09:16:03 /mnt/ramdisk/book/sugar01.dbf
--//資料檔案現在是27271168/1024/1024=26.0078125M.而備份映像10M+8K.
$ strings /mnt/ramdisk/book/sugar01.dbf | grep "AAAA" |wc
100000 170040 3624077
$ strings /mnt/ramdisk/book/sugar01.dbf | grep "BBBB" |wc
200000 340080 7243181
$ strings /mnt/ramdisk/book/sugar01.dbf | grep "CCCC" |wc
200000 340080 7243181
--//資料檔案存在發現BBBB，CCCC字串.
$ strings /home/oracle/backup/sugar01.dbf | grep "AAAA" |wc
100000 170040 3624077
$ strings /home/oracle/backup/sugar01.dbf | grep "BBBB" |wc
0 0 0
$ strings /home/oracle/backup/sugar01.dbf | grep "CCCC" |wc
0 0 0
--//查詢備份映像發現BBBB，CCCC字串可以發現根本不存在，也就是講這部分的備份並沒有做,這點我覺得有點出乎我的意外!!
--//可以猜測oracle 做映像備份與建立備份集一樣,也是根據資料檔案點陣圖區確定讀取那些資料塊,這樣在備份開始後新建立的塊不會備份.
RMAN> list datafilecopy all;
using target database control file instead of recovery catalog
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time
------- ---- - ------------------- ---------- -------------------
35 7 A 2017-11-23 09:16:29 13279893698 2017-11-23 09:15:09
Name: /home/oracle/backup/sugar01.dbf
Tag: TAG20171123T091509
RMAN> validate copy of datafile 7 ;
Starting validate at 2017-11-23 09:37:11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=67 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: including datafile copy of datafile 00007 in backup set
input file name=/home/oracle/backup/sugar01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafile Copies
=======================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
7 OK 0 541 1280 13279893572
File Name: /home/oracle/backup/sugar01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 594
Index 0 0
Other 0 145
Finished validate at 2017-11-23 09:37:12
SCOTT@book> select recid,file#,NAME,CHECKPOINT_CHANGE#,ABSOLUTE_FUZZY_CHANGE# from v$datafile_copy where recid=35 ;
RECID FILE# NAME CHECKPOINT_CHANGE# ABSOLUTE_FUZZY_CHANGE#
----- ----- ------------------------------- ------------------ ----------------------
35 7 /home/oracle/backup/sugar01.dbf 13279893698 0
--//而且備份期間沒有出現高於檢查點scn高於13279893698的scn號。ABSOLUTE_FUZZY_CHANGE#的記錄是0.
--//換一句話T2,T3佔用的資料庫根本不備份.
--//這樣更前面測試使用備份集的模式一樣,備份時建立SNAPSHOT CONTROLFILE,備份檔案大小已經確定,備份期間讀取了資料塊點陣圖資訊，
--//這樣需要備份的塊也確定,而T2,T3表佔用塊是後面的建立的,即使我發了檢查點,oracle也不會讀取,寫入備份集合.
4.觀察一個資料塊看看.
SCOTT@book> select rowid,t2.* from t2 where id=1;
ROWID ID NAME
------------------ --- --------------------------------
AAAWKKAAHAAAAMDAAA 1 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
SCOTT@book> @ &r/rowid AAAWKKAAHAAAAMDAAA
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
------------ ------------ ------------ ------------ -------------------- -------------------- ----------------------------------------
90762 7 771 0 0x1C00303 7,771 alter system dump datafile 7 block 771 ;
BBED> dump /v filename '/home/oracle/backup/sugar01.dbf' block 771 offset 0 count 256
File: /home/oracle/backup/sugar01.dbf (0)
Block: 771 Offsets: 0 to 255 Dba:0x00000000
-----------------------------------------------------------------------------------------------------------
00a20000 0303c001 00000000 00000105 c3a50000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
<32 bytes per line>
BBED> dump /v filename '/home/oracle/backup/sugar01.dbf' block 771 offset 8000 count 192
File: /home/oracle/backup/sugar01.dbf (0)
Block: 771 Offsets: 8000 to 8191 Dba:0x00000000
-----------------------------------------------------------------------------------------------------------
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 l ................................
<32 bytes per line>
--//可以發現備份映像對應的塊是空的,也就是根本沒有讀取,我估計是"構造"出來的.
BBED> dump /v filename '/mnt/ramdisk/book/sugar01.dbf' block 771 offset 0 count 256
File: /mnt/ramdisk/book/sugar01.dbf (7)
Block: 771 Offsets: 0 to 255 Dba:0x01c00303
-----------------------------------------------------------------------------------------------------------
06a20000 0303c001 04198b17 03000204 84400000 01000000 8a620100 fe188b17 l .................@.......b......
03000000 03003200 0003c001 ffff0000 00000000 00000000 00000000 00800300 l ......2.........................
fe188b17 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 0001ae00 l ................................
ffff6e01 b4044603 46030000 ae00591f 321f0b1f e41ebd1e 961e6f1e 481e211e l ..n...F.F.....Y.2.........o.H.!.
fa1dd31d ac1d851d 5e1d371d 101de91c c21c9b1c 741c4d1c 261cff1b d81bb11b l ........^.7.........t.M.&.......
8a1b631b 3c1b151b ee1ac71a a01a791a 521a2b1a 041add19 b6198f19 68194119 l ..c.<.........y.R.+.........h.A.
1a19f318 cc18a518 7e185718 30180918 e217bb17 94176d17 46171f17 f816d116 l ........~.W.0.........m.F.......
<32 bytes per line>
BBED> dump /v filename '/mnt/ramdisk/book/sugar01.dbf' block 771 offset 8000 count 192
File: /mnt/ramdisk/book/sugar01.dbf (7)
Block: 771 Offsets: 8000 to 8191 Dba:0x01c00303
-----------------------------------------------------------------------------------------------------------
42424242 42424242 42424242 42424242 42424242 42424242 42424242 42424242 l BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
2c000202 c1052042 42424242 42424242 42424242 42424242 42424242 42424242 l ,..... BBBBBBBBBBBBBBBBBBBBBBBBB
42424242 4242422c 000202c1 04204242 42424242 42424242 42424242 42424242 l BBBBBBB,..... BBBBBBBBBBBBBBBBBB
42424242 42424242 42424242 42422c00 0202c103 20424242 42424242 42424242 l BBBBBBBBBBBBBB,..... BBBBBBBBBBB
42424242 42424242 42424242 42424242 42424242 422c0002 02c10220 42424242 l BBBBBBBBBBBBBBBBBBBBB,..... BBBB
42424242 42424242 42424242 42424242 42424242 42424242 42424242 02060419 l BBBBBBBBBBBBBBBBBBBBBBBBBBBB....
<32 bytes per line>
--//可以發現對應資料檔案的資料塊.
總結：
1.我僅僅猜測備份時，檔案大小就已經確定(估計透過SNAPSHOT CONTROLFILE)，最多10M。而具體讀取那些塊，我估計已經透過點陣圖確定下來。
這個與前面測試備份集的情況一樣.
你可以看到即使我發了alter system checkpoint命令，T2,T3表的資訊依舊沒有備份。
2.我做了資料檔案增加的情況，資料檔案縮小有發生什麼情況呢？看下一篇blog.
3.做了這麼多這類測試,我的感覺最好建立一個大的資料檔案不要擴充套件,也不要做收縮操作(即使做也最好避開rman備份視窗),特別是收縮操作!!
4.在寫這篇blog快結束時:
$ ls -l /mnt/ramdisk/book/sugar01.dbf /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 10493952 2017-11-23 09:16:29 /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 44048384 2017-11-23 09:36:37 /mnt/ramdisk/book/sugar01.dbf
--//可以發現資料檔案變成了42M,而前面測試結束時是26M:
$ ls -l /mnt/ramdisk/book/sugar01.dbf /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 10493952 2017-11-23 09:16:29 /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 27271168 2017-11-23 09:16:03 /mnt/ramdisk/book/sugar01.dbf
--//注意看檔案時間戳不一樣,也就是在這期間觸發pre-allocation.oracle在資料檔案快滿的時候,觸發pre-allocation,擴充套件了16M.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2147642/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20161031]rman備份與資料檔案變化3.txt
- [20161031]rman備份與資料檔案變化2.txt
- RMAN說，我能備份(4)--RMAN備份資料檔案和控制檔案
- [20161101]rman備份與資料檔案變化4.txt
- [20161102]rman備份與資料檔案變化5.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在歸檔與非歸檔時備份資料庫的簡單示例資料庫