[20171130]關於rman備份疑問.txt--//前面測試太亂,重新做一些rman as copy相關測試.1.環境:SCOTT@book> @ &r/ver1PORT_STRING VERSION BANNER x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Da ...
[20171130]關於rman備份疑問.txt
--//前面測試太亂,重新做一些rman as copy相關測試.
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 6M AUTOEXTEND OFF
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;
create table t1 tablespace sugar as select rownum id ,lpad('A',32,'A') name from dual connect by level<=1e5;
alter system checkpoint ;
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
--//主要目的減慢備份速度。
2.測試1:
--//測試腳本:
$ cat t1.sh
#! /bin/bash
rman target / <<EOF >> /tmp/t1.txt &
backup as copy datafile 7 format '/home/oracle/backup/%b_1' ;
#backup datafile 7 format '/home/oracle/backup/sugar01.dbf_1_%U' ;
quit
EOF
echo "sleep $1 "
sleep $1
sqlplus -s scott/book <<EOF
set numw 12
update t1 set name=lpad('B',32,'B') where mod(id,2)=1;
commit;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
select dbms_flashback.get_system_change_number,sysdate from dual;
host strings /mnt/ramdisk/book/sugar01.dbf | grep "BBBB" |wc
EOF
$ . t1.sh 6
sleep 6
50000 rows updated.
Commit complete.
System altered.
System altered.
System altered.
System altered.
GET_SYSTEM_CHANGE_NUMBER SYSDATE
------------------------ -------------------
13280180133 2017-11-29 16:37:08
50000 84680 1811356
SCOTT@book> select rowid,ora_rowscn from t1 where rownum=1;
ROWID ORA_ROWSCN
------------------ ------------
AAAWM5AAHAAAACDAAA 13280180120
SCOTT@book> select file#,CHECKPOINT_CHANGE#,ABSOLUTE_FUZZY_CHANGE# from v$datafile_copy order by 2 ;
FILE# CHECKPOINT_CHANGE# ABSOLUTE_FUZZY_CHANGE#
----- ------------------ ----------------------
7 13280180084 0
RMAN> list copy of database;
using target database control file instead of recovery catalog
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time
------- ---- - ------------------- ---------- -------------------
76 7 A 2017-11-29 16:37:54 13280180084 2017-11-29 16:37:06
Name: /home/oracle/backup/sugar01.dbf_1
Tag: TAG20171129T163706
$ strings sugar01.dbf_1 | grep "AAAA"|wc
100000 170040 3624077
$ strings sugar01.dbf_1 | grep "BBBB"|wc
0 0 0
--//文件頭scn=13280180084開始備份,而過了6秒,我修改一部分數據(提交scn=13280180120),這個時候還沒讀到相應表T1段.
--//為什麼寫入備份image的沒有BBBB信息呢?我當時做測試非常不理解..........
3.從電子文檔<Oracle RMAN 11g Backup and Recovery.pdf>中發現如下內容:
--//鏈接:http://blog.itpub.net/267265/viewspace-2147878/
作者:Robert G. Freeman Matthew Hart
頁數:689
出版社:Mc graw hill
出版號: ISBN: 978-0-07-162861-7
MHID: 0-07-162861-4
RMAN in Memory P80
RMAN builds buffers in memory through which it streams data blocks for potential backup. This
memory utilization counts against the total size of the PGA and, sometimes, the SGA. There are
two kinds of memory buffers. Input buffers are the buffers that are filled with data blocks read
from files that are being backed up. Output buffers are the buffers that are filled when the
memory-to-memory write occurs to determine whether a particular block needs to be backed up.
When the output buffer is filled, it is written to the backup location. The memory buffers differ
depending on whether you are backing up to or restoring from disk or tape. Figure 2-3 illustrates
input and output buffer allocation. It illustrates a backup of two datafiles being multiplexed into
a single backup set.
Input Memory Buffers
When you are backing up the database, the size and number of input memory buffers depend on
the exact backup command being executed. Primarily, they depend on the number of files being
multiplexed into a single backup. Multiplexing refers to the number of files that will have their
blocks backed up to the same backup piece. To keep the memory allocation within reason, the
following rules are applied to the memory buffer sizes based on the number of files being backed
up together:
■ If the number of files going into the backup set is four or less, then RMAN allocates four
buffers per file at 1MB per buffer. The total will be 16MB or less.
...
--//我仔細閱讀文檔,對於備份1個數據文件,按照介紹,數據塊先導入PGA(我感覺這裡就進入input buffer),"處理"後放入output buffer,
--//如果output buffer滿了,寫出到備份文件對應位置.
--//換一句話講,如果數據塊已經讀入PGA,即使在相應數據塊發生DML,oracle也不會再重讀數據文件.只有這樣,才可能出現我前面備份的
--//情況.4M的位置已經可以排除(因為我前面設置數據文件大小6M),這樣剩下應該出現在16M開始的位置.
CREATE TABLESPACE SUGAR DATAFILE
'/mnt/ramdisk/book/sugar01.dbf' SIZE 21M AUTOEXTEND OFF
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;
create table t1 tablespace sugar as select rownum id ,lpad('A',32,'A') name from dual connect by level<=4e5;
SCOTT@book> select sum(bytes) from dba_extents where segment_name='T1';
SUM(BYTES)
----------
19922944
--//占19922944/1024/1024= 19M.
$ . t1.sh 6
sleep 6
200000 rows updated.
Commit complete.
System altered.
System altered.
System altered.
System altered.
GET_SYSTEM_CHANGE_NUMBER SYSDATE
------------------------ -------------------
13280219948 2017-11-30 10:49:13
200000 339280 7260120
--//等備份完成:
Starting backup at 2017-11-30 10:49:08
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=94 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00007 name=/mnt/ramdisk/book/sugar01.dbf
output file name=/home/oracle/backup/sugar01.dbf_1 tag=TAG20171130T104908 RECID=85 STAMP=961411917
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:02:55
channel ORA_DISK_1: throttle time: 0:02:48
Finished backup at 2017-11-30 10:52:04
Starting Control File and SPFILE Autobackup at 2017-11-30 10:52:04
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2017_11_30/o1_mf_s_961411924_f1ywln5x_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2017-11-30 10:52:05
SCOTT@book> column name format a50
SCOTT@book> select recid,file#,NAME,CHECKPOINT_CHANGE#,ABSOLUTE_FUZZY_CHANGE# from v$datafile_copy where recid=85 ;
RECID FILE# NAME CHECKPOINT_CHANGE# ABSOLUTE_FUZZY_CHANGE#
------------ ------------ -------------------------------------------------- ------------------ ----------------------
85 7 /home/oracle/backup/sugar01.dbf_1 13280219895 13280219934
--//最高塊scn=13280219934,應該備份有BBBB信息.
SCOTT@book> select rowid,ora_rowscn from t1 where rownum=1;
ROWID ORA_ROWSCN
------------------ ------------
AAAWNaAAHAAAACDAAA 13280219933
$ strings -t d sugar01.dbf_1 | grep "AAAAA" |wc
358205 968151 16037238
$ strings -t d sugar01.dbf_1 | grep "BBBBBB" |wc
41795 113154 1909462
--//哈哈,終於出現,現在驗證是否在數據文件16M的位置最早出現BBBBB.
$ strings -t d sugar01.dbf_1 | grep "BBBBBB" |head
16794947 BN BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795029 BL BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795111 BJ BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795193 BH BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795275 BF BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795357 BD BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795439 BB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795521 B@ BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795603 B> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795685 B< BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
--//16794947/8192=2050.1644287109375,在塊2050位置.在偏移0.1644287109375*8192=1347處出現.
SCOTT@book> select 2050*8192/1024/1024 from dual ;
2050*8192/1024/1024
-------------------
16.015625
--//就是大約在16M的位置.
--//0.015625*1024*1024=16384.還差2塊(數據塊大小8192),我推測OS頭,文件頭讀取(但是不進入input buffer),因為這個是構造出來,
--//說明:如果做備份集備份,是找不到OS頭備份的.而文件頭實際上是最後寫入備份文件的.
--//基本在16M位置.驗證我的判斷應該是正確的.
BBED> x /rnc filename "/home/oracle/backup/sugar01.dbf_1" block 2050 *kdbr[166]
rowdata[41] @1342
-----------
flag@1342: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@1343: 0x02
cols@1344: 2
col 0[4] @1345: 316577
col 1[32] @1350: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
--//偏移1350,如果註意看前面strings輸出前面還有3個字元,這樣就能對山了.
--//順便說一下:定義欄位name的長度32,這樣長度指示器正好對應的ascii是空格.
--//感覺單個數據文件備份,會全部使用16M的記憶體作為input buffer,只有這樣才能解析前面的測試.
SCOTT@book> select count(*) from t1 where DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid) >=2050 and name=LPAD('B',32,'B');
COUNT(*)
------------
41795
--//也與查詢備份image的結果一致.
$ strings -t d sugar01.dbf_1 | grep "BBBBBB" |wc
41795 113154 1909462
--//終於把自己的困惑解開....以後不再做這樣測試,累..
--//感覺自己在測試方法,工具選擇上存在問題.比如最後將文件頭寫入備份映像的測試,實際上只要strace跟蹤就更好一些.
