[20171130]关于rman备份疑问.txt

Posted 2020-10-16 lfree

[20171130]关于rman备份疑问.txt

--//前面测试太乱,重新做一些rman as copy相关测试.

1.环境:
[email protected]> @ &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

[email protected]> select rowid,ora_rowscn from t1 where rownum=1;
ROWID                ORA_ROWSCN
------------------ ------------
AAAWM5AAHAAAACDAAA  13280180120

[email protected]> 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;

[email protected]> 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

[email protected]> column name format a50
[email protected]> 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信息.

[email protected]> 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  [email protected] BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795603  B> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
16795685  B< BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,

--//16794947/8192=2050.1644287109375,在块2050位置.在偏移0.1644287109375*8192=1347处出现.

[email protected]> 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
-----------
[email protected]: 0x2c (KDRHFL, KDRHFF, KDRHFH)
[email protected]: 0x02
[email protected]:    2

col    0[4] @1345: 316577
col   1[32] @1350: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
--//偏移1350,如果注意看前面strings输出前面还有3个字符,这样就能对山了.
--//顺便说一下:定义字段name的长度32,这样长度指示器正好对应的ascii是空格.

--//感觉单个数据文件备份,会全部使用16M的内存作为input buffer,只有这样才能解析前面的测试.

[email protected]> 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跟踪就更好一些.