[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

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>
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.

--//資料檔案存在發現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.

[20171123]rman備份與資料檔案變化6.txt

相關文章