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

[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位置.验证我的判断应该是正确的.

--//更正前面的判断:
SCOTT@book> alter system dump datafile '/mnt/ramdisk/book/sugar01.dbf' block 2048;
System altered.

SCOTT@book> alter system dump datafile '/mnt/ramdisk/book/sugar01.dbf' block 2049;
System altered.

Dump all the blocks in range:
buffer tsn: 8 rdba: 0x01c00800 (7/2048)
scn: 0x0003.17719599 seq: 0x02 flg: 0x04 tail: 0x95992002
frmt: 0x02 chkval: 0x8a65 type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
...
Dump all the blocks in range:
buffer tsn: 8 rdba: 0x01c00801 (7/2049)
scn: 0x0003.17719599 seq: 0x02 flg: 0x04 tail: 0x95992002
frmt: 0x02 chkval: 0x8a27 type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1

--//dba 7,2048 7,2049是FIRST LEVEL BITMAP BLOCK.里面没有BBBB信息.应该缓存的是前面16M的信息.分析有错.
--//如果分析strace跟踪文件也可以发现:
$ grep "pwrite(259" /tmp/tt1.txt
49454 pwrite(259, "\0\242\0\0\1\0\300\1\0\0\0\0\0\0\1\5\301\246\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1040384, 8192) = 1040384
49454 pwrite(259, " \242\0\0\200\0\300\1\231\225q\27\3\0\4\4C\213\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 1048576) = 1048576
49454 pwrite(259, " \242\0\0\0\1\300\1\231\225q\27\3\0\2\4I\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 2097152) = 1048576
49454 pwrite(259, " \242\0\0\200\1\300\1\231\225q\27\3\0\2\4K\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 3145728) = 1048576
49454 pwrite(259, " \242\0\0\0\2\300\1\231\225q\27\3\0\2\4M\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 4194304) = 1048576
49454 pwrite(259, " \242\0\0\200\2\300\1\231\225q\27\3\0\2\4O\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 5242880) = 1048576
49454 pwrite(259, " \242\0\0\0\3\300\1\231\225q\27\3\0\2\4Q\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 6291456) = 1048576
49454 pwrite(259, " \242\0\0\200\3\300\1\231\225q\27\3\0\2\4S\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 7340032) = 1048576
49454 pwrite(259, " \242\0\0\0\4\300\1\231\225q\27\3\0\2\4U\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 8388608) = 1048576
49454 pwrite(259, " \242\0\0\200\4\300\1\231\225q\27\3\0\2\4W\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 9437184) = 1048576
49454 pwrite(259, " \242\0\0\0\5\300\1\231\225q\27\3\0\2\4Y\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 10485760) = 1048576
49454 pwrite(259, " \242\0\0\200\5\300\1\231\225q\27\3\0\2\4[\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 11534336) = 1048576
49454 pwrite(259, " \242\0\0\0\6\300\1\231\225q\27\3\0\2\4]\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 12582912) = 1048576
49454 pwrite(259, " \242\0\0\200\6\300\1\231\225q\27\3\0\2\4_\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 13631488) = 1048576
49454 pwrite(259, " \242\0\0\0\7\300\1\231\225q\27\3\0\2\4a\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 14680064) = 1048576
49454 pwrite(259, " \242\0\0\200\7\300\1\231\225q\27\3\0\2\4c\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 15728640) = 1048576
49454 pwrite(259, " \242\0\0\0\10\300\1\231\225q\27\3\0\2\4e\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 16777216) = 1048576
49454 pwrite(259, " \242\0\0\200\10\300\1\231\225q\27\3\0\2\4g\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 17825792) = 1048576
49454 pwrite(259, " \242\0\0\0\t\300\1\231\225q\27\3\0\2\4i\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 18874368) = 1048576
49454 pwrite(259, " \242\0\0\200\t\300\1\231\225q\27\3\0\2\4k\212\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 19922944) = 1048576
49454 pwrite(259, "\0\242\0\0\0\n\300\1\0\0\0\0\0\0\1\5\300\254\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576, 20971520) = 1048576
49454 pwrite(259, "\0\242\0\0\200\n\300\1\0\0\0\0\0\0\1\5@\254\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192, 22020096) = 8192
49454 pwrite(259, "\v\242\0\0\1\0\300\1\0\0\0\0\0\0\1\4l/\0\0\0\0\0\0\0\4 \vn!\267O"..., 8192, 8192) = 8192

--//仔细看pwrite写出的偏移都是对齐1M的整数倍偏移,除了第1个,最后2个调用.
--//第1个实际上写入1040384/8192=127块,从8192偏移,就是写入文件头以及位图区信息.
--//最后1个实际上重写文件头.

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

时间： 2024-09-20 12:30:30

[20171130]关于rman备份疑问.txt的相关文章

[20171204]关于rman备份疑问4.txt

[20171204]关于rman备份疑问4.txt --//上午排除我几天在做rman测试的疑问. --//链接如下:http://blog.itpub.net/267265/viewspace-2148029/ --//顺便测试备份集包含5个数据文件的情况(本来不想做,还是做看看),验证自己的判断是否正确. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER -----------

[20130412]rman备份文件大小.txt

[20130412]rman备份文件大小.txt 记得以前看rman的书,rman仅仅备份已经格式话的块,如果这样一个表被truncate后,即使空间回收了.但是在rman备份时,备份大小不会变化太多,这些前面使用的块一定会备份.实际的测试情况是,备份文件会变小. 测试的链接:http://space.itpub.net/267265/viewspace-750049 如果是索引删除的情况呢?自己不能凭想象,还是做测试来看看. 1.测试环境: SQL> @verBANNER-----------

[20161118]rman备份的疑问2.txt

[20161118]rman备份的疑问2.txt --这个是我前几天做测试时遇到的疑问,不知道为什么rman 备份要修改数据块的dba地址. --我在itpub上也问了这个问题,链接http://www.itpub.net/thread-2071504-1-1.html,可惜没有人解答. --具体细节不清楚,读取数据文件然后重新编码组织数据,将kcbh.rdba_kcbh的后2位放入tailchk中,设置spare3_kcbh=0x0001, --也许为了区分备份与数据文件,当然还有别的目的,再

[20161114]rman备份的疑问.txt

[20161114]rman备份的疑问.txt --这个是我前几天做测试时遇到的疑问,不知道为什么rman 备份要修改数据块的dba地址. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ---------------------------------------------------

[20171130]关于rman的一些总结.txt

[20171130]关于rman的一些总结.txt --//最近一直做rman相关测试,测试那个乱,没办法.无法从周围的人获得帮助,纯粹是自己的乱猜,乱测,不知道别人是否能看懂我写的东西. --//有必要做一些总结,不一定对,仅仅是我当前的看法. 1.数据文件备份集中,文件头是最后写到备份集文件的. 2.使用备份集恢复也是一样,文件头也是最好写入的. 3.以上情况对as copy的方式也是一样. --//oracle这样操作主要目的保证备份是好的可用,反之恢复也是一样. 4.关于备份参数file

[20160523]rman备份与检查点2.txt

[20160523]rman备份与检查点2.txt --写过几篇关于检查点的文章,测试看看如果rman做备份时是否写检查点. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING         VERSION        BANNER ------------------- -------------- ---------------------------------------------------------------------------- x86

[20160523]rman备份与检查点3.txt

[20160523]rman备份与检查点3.txt --从前面的测试可以发现: --1.通过以上信息可以确定备份文件会写检查点. --2.而且备份文件是先写检查点,再做备份. --我这里就产生1个疑问,假设某个数据文件备份时间很长,这样数据文件的某个数据块的scn可能大于文件头的CHECKPOINT_CHANGE#.当我 --们恢复使用不完全恢复到某个时间点或者SCN,应该使用那个备份文件呢?做一个测试来说明问题. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRIN

[20161220]rman恢复时间点的疑问.txt

[20161220]rman恢复时间点的疑问.txt --昨天在恢复时遇到缺少归档的问题,自己开始感觉奇怪,做一点分析记录. RMAN> list backupset summary ; List of Backups =============== Key     TY LV S Device Type Completion Time     #Pieces #Copies Compressed Tag ------- -- -- - ----------- -----------------

[20161101]rman备份与数据文件变化7.txt

[20161101]rman备份与数据文件变化7.txt --//想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --//去年已经测试了建立备份集的情况,一直想做一次image copy的测试,一直脱,主要原因自己不想做这个测试.... --//而且当时的测试很乱,自己主要一边做一边想.... --//链接: http://blog.itpub.net/267265/viewspace-2127386/ http://blog.itpub