[20171121]rman backup as copy 2.txt

[20171121]rman backup as copy 2.txt

--//昨天测试backup as copy ,备份时备份文件的文件头什么时候更新.是最后完成后还是顺序写入备份文件.
--//我测试的数据文件使用数据文件2(表空间sysaux),也许是文件不够大,应该减慢备份速度来测试看看.

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

$ cat dump_head.sh
#! /bin/bash
for i in $(seq 1000)
do
#   echo $i
    xxd -c32 -g 2 -s 8192 -l 32 $1 >> /tmp/dump_head.txt 2>/dev/null
    sleep 1
done

2.测试:
--//首先启动dump_head.sh脚本,session 1:
$ .  dump_head.sh /home/oracle/backup/tea01.dbf &

--//在sesion 2,在rman下执行备份:
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 1M;
using target database control file instead of recovery catalog
new RMAN configuration parameters:
CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 1 M;
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 3 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

--//设置DISK RATE 1M,这样可以减慢备份的速度,便于观察.并且仅仅打开1个并行.

RMAN> backup as copy datafile 6 format '/home/oracle/backup/%b';
Starting backup at 2017-11-21 09:43:09
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00006 name=/mnt/ramdisk/book/tea01.dbf
output file name=/home/oracle/backup/tea01.dbf tag=TAG20171121T094309 RECID=17 STAMP=960630229
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:45
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
channel ORA_DISK_1: throttle time: 0:00:40
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Finished backup at 2017-11-21 09:43:54
Starting Control File and SPFILE Autobackup at 2017-11-21 09:43:54
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2017_11_21/o1_mf_s_960630234_f1716tsv_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2017-11-21 09:43:55
--//注意看下划线内容,throttle time: 0:00:40.
throttle
英 [?θr?tl] 美 [?θrɑ:tl]
n.
节流阀;喉咙，气管;[机]风门
vt.& vi.
扼杀，压制;勒死，使窒息;使节流;（用节汽阀等）调节
vi.
节流，减速;窒息
-----------------------------------------------
--//而我的备份文件就是40M+8k的数据文件.
$ ls -lh /home/oracle/backup/tea01.dbf
-rw-r----- 1 oracle oinstall 41M 2017-11-21 09:43:49 /home/oracle/backup/tea01.dbf
$ ls -l /home/oracle/backup/tea01.dbf
-rw-r----- 1 oracle oinstall 41951232 2017-11-21 09:43:49 /home/oracle/backup/tea01.dbf

--//session 1:
$ fg
. dump_head.sh /home/oracle/backup/tea01.dbf
^C^

3.检查/tmp/dump_head.txt输出记录:

$ uniq -c /tmp/dump_head.txt
      1 0002000: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ................................
     40 0002000: 00a2 0000 0100 8001 0000 0000 0000 0105 81a6 0000 0000 0000 0000 0000 0000 0000  ................................
     14 0002000: 0ba2 0000 0100 8001 0000 0000 0000 0104 61c1 0000 0000 0000 0004 200b 6e21 b74f  ................a?....... .n!.O

--//^_^,再次验证我的判断.
--//从以上输出可以发现使用backup as copy备份,一定先建立一个空文件,输出一堆0000(需要大约1秒),大小与数据文件一致,这样可以先检测是否磁盘满足备份需求.
--//然后写入开头00a2,出现40次(我脚本执行sleep 1,不考虑其它消耗正好是40秒).
--//到最后才更新as copy方式的备份映像的文件头.

--//oracle的设计确实考虑许多因素,与备份文件集模式一样最后写入文件头信息,这样保证使用备份image是正确的,
--//设想一下,如果顺序写入备份image文件,如果备份过程中发生中断,而那这个image备份文件来恢复,会发生什么情况呢?
--//而现在这样设计意味着发生中断,备份image的文件头是"坏"的,意味着不能用于恢复.

--//还有一个疑问,写入备份image的文件头信息是 开始备份前读取的文件头信息,然后最后完成备份在读取文件头信息呢?
--//我只要在备份过程发出alter system checkpoint就知道.
--//  重复测试看看.

RMAN> delete datafilecopy all ;
SYS@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                             TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------- ---------------
    1        13279819419 2017-11-21 10:22:57                7            925702 ONLINE              1246 YES /mnt/ramdisk/book/system01.dbf   SYSTEM
    2        13279819419 2017-11-21 10:22:57             1834            925702 ONLINE              1247 YES /mnt/ramdisk/book/sysaux01.dbf   SYSAUX
    3        13279819419 2017-11-21 10:22:57           923328            925702 ONLINE              1156 YES /mnt/ramdisk/book/undotbs01.dbf  UNDOTBS1
    4        13279819419 2017-11-21 10:22:57            16143            925702 ONLINE              1243 YES /mnt/ramdisk/book/users01.dbf    USERS
    5        13279819419 2017-11-21 10:22:57           952916            925702 ONLINE              1152 YES /mnt/ramdisk/book/example01.dbf  EXAMPLE
    6        13279819419 2017-11-21 10:22:57      13276257767            925702 ONLINE               634 YES /mnt/ramdisk/book/tea01.dbf      TEA
6 rows selected.
--//session 1:
RMAN> backup as copy datafile 6 format '/home/oracle/backup/%b';

Starting backup at 2017-11-21 10:26:10
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00006 name=/mnt/ramdisk/book/tea01.dbf
....等

--//session 2:
SYS@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                             TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------- ----------------
    1        13279819419 2017-11-21 10:22:57                7            925702 ONLINE              1246 YES /mnt/ramdisk/book/system01.dbf   SYSTEM
    2        13279819419 2017-11-21 10:22:57             1834            925702 ONLINE              1247 YES /mnt/ramdisk/book/sysaux01.dbf   SYSAUX
    3        13279819419 2017-11-21 10:22:57           923328            925702 ONLINE              1156 YES /mnt/ramdisk/book/undotbs01.dbf  UNDOTBS1
    4        13279819419 2017-11-21 10:22:57            16143            925702 ONLINE              1243 YES /mnt/ramdisk/book/users01.dbf    USERS
    5        13279819419 2017-11-21 10:22:57           952916            925702 ONLINE              1152 YES /mnt/ramdisk/book/example01.dbf  EXAMPLE
    6        13279819660 2017-11-21 10:26:10      13276257767            925702 ONLINE               635 YES /mnt/ramdisk/book/tea01.dbf      TEA
--//注意看数据文件6的CHECKPOINT_CHANGE#=13279819660(备份开始前CHECKPOINT_CHANGE#=13279819419),说明在备份开始时要做文件检查点, 更新文件头scn.

SYS@book> alter system checkpoint ;
System altered.

SYS@book> alter system checkpoint ;
System altered.

SYS@book> alter system checkpoint ;
System altered.
--//在备份的过程中我发3次alter system checkpoint ;

--//session 1:
RMAN> backup as copy datafile 6 format '/home/oracle/backup/%b';

Starting backup at 2017-11-21 10:26:10
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00006 name=/mnt/ramdisk/book/tea01.dbf
output file name=/home/oracle/backup/tea01.dbf tag=TAG20171121T102610 RECID=19 STAMP=960632810
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:45
channel ORA_DISK_1: throttle time: 0:00:39
Finished backup at 2017-11-21 10:26:55

Starting Control File and SPFILE Autobackup at 2017-11-21 10:26:55
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2017_11_21/o1_mf_s_960632816_f173qj22_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2017-11-21 10:26:57

--//session 2:
SYS@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                                               TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------------------------- ------------------------------
    1        13279819678 2017-11-21 10:26:26                7            925702 ONLINE              1249 YES /mnt/ramdisk/book/system01.dbf                     SYSTEM
    2        13279819678 2017-11-21 10:26:26             1834            925702 ONLINE              1250 YES /mnt/ramdisk/book/sysaux01.dbf                     SYSAUX
    3        13279819678 2017-11-21 10:26:26           923328            925702 ONLINE              1159 YES /mnt/ramdisk/book/undotbs01.dbf                    UNDOTBS1
    4        13279819678 2017-11-21 10:26:26            16143            925702 ONLINE              1246 YES /mnt/ramdisk/book/users01.dbf                      USERS
    5        13279819678 2017-11-21 10:26:26           952916            925702 ONLINE              1155 YES /mnt/ramdisk/book/example01.dbf                    EXAMPLE
    6        13279819678 2017-11-21 10:26:26      13276257767            925702 ONLINE               638 YES /mnt/ramdisk/book/tea01.dbf                        TEA
6 rows selected.

--//看看备份写入的scn是13279819678还是13279819660呢?

BBED> p /d filename '/home/oracle/backup/tea01.dbf' block 1 kcvfh.kcvfhckp.kcvcpscn
struct kcvcpscn, 8 bytes                    @484
   ub4 kscnbas                              @484      394917772
   ub2 kscnwrp                              @488      3

BBED> p /d filename '/mnt/ramdisk/book/tea01.dbf' block 1 kcvfh.kcvfhckp.kcvcpscn
struct kcvcpscn, 8 bytes                    @484
   ub4 kscnbas                              @484      394917790
   ub2 kscnwrp                              @488      3

SYS@book> select power(2,32)*3+394917772 from dual ;
POWER(2,32)*3+394917772
-----------------------
            13279819660

SYS@book> select power(2,32)*3+394917790 from dual ;
POWER(2,32)*3+394917790
-----------------------
            13279819678

--//从CHECKPOINT_CHANGE#的scn号可以看出是备份文件的文件头信息是备份时读取的文件头信息,而不是经过多次alter system checkpint后的信息.
--//也就是备份时已经读取这部分信息到内存(下面的补充测试也说明问题),最后在写入备份image的文件头的.

--//我再次修改我的测试脚本,-s 8676对应的CHECKPOINT_CHANGE#号信息.再次重复测试,仅仅贴出结果.

$ cat dump_head.sh
#! /bin/bash
for i in $(seq 1000)
do
#   echo $i
    xxd -c32 -g 2 -s 8192 -l 32 $1 >> /tmp/dump_head.txt 2>/dev/null
    xxd -c32 -g 2 -s 8676 -l 32 $1 >> /tmp/dump_head.txt 2>/dev/null
    sleep 1
done

$ grep "^0002000:" /tmp/dump_head.txt  | uniq -c
     40 0002000: 00a2 0000 0100 8001 0000 0000 0000 0105 81a6 0000 0000 0000 0000 0000 0000 0000  ................................
     39 0002000: 0ba2 0000 0100 8001 0000 0000 0000 0104 1292 0000 0000 0000 0004 200b 6e21 b74f  .......................... .n!.O

$ grep "^00021e4:" /tmp/dump_head.txt  | uniq -c
     40 00021e4: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ................................
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    
     77 00021e4: 73fc 8917 0300 0000 f91b 4239 0100 0000 c003 0000 875a 0100 1000 313b 0200 0000  s?.....?B9....?...Z....1;....

--//可以看出前面40秒,根本没有写入文件头scn信息.最后才写入的.

--//收尾还原:
RMAN> configure channel 1 device type disk clear;
old RMAN configuration parameters:
CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 1 M;
old RMAN configuration parameters are successfully deleted
released channel: ORA_DISK_1

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3 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 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored

时间： 2024-08-01 23:44:32

[20171121]rman backup as copy 2.txt的相关文章

[20171121]rman backup as copy.txt

[20171121]rman backup as copy.txt --//上个星期做数据文件块头恢复时,提到使用rman备份数据文件时,文件头数据库信息是最后写入备份集文件的,在filesperset=1的情况 --//下写入备份集文件中的倒数第2块就是文件头的备份.参考链接: http://blog.itpub.net/267265/viewspace-2147297/=>[20171115]恢复数据文件块头4补充.txt --//而且我最后还做了测试证明如果resotre数据文件,实际上文

[20171122]rman backup as copy的备份问题

[20171122]rman backup as copy的备份问题.txt --//以前曾经写过一篇[20160524]rman备份与检查点4.txt=>链接:http://blog.itpub.net/267265/viewspace-2106087/ --//里面提到加入备份时间很长,这样可能会出现数据块里面的scn号大于文件头scn号.我提到视图v$backup_datafile --//的ABSOLUTE_FUZZY_CHANGE#字段记录了备份时块最大的scn号.查询视图: sele

[20160329]backup as copy问题.txt

[20160329]backup as copy问题.txt --别人问的一个问题,想通过dg建立测试库,我建议他停止日志应用,然后使用拷贝的方式建立测试库,只要路径一样,生成一个新的控 --制文件就ok了.本来一个很简单通过nfs mount文件系统,cp就ok了.没有选择cp而使用rman的backup as copy命令方式,遇到一点点 --小问题,自己重复测试看看: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                   

[20160421]backup as copy问题2.txt

[20160421]backup as copy问题2.txt http://blog.itpub.net/267265/viewspace-2070878/ --前面提到使用backup as copy datafile 1 format '/home/oracle/backup/%b' ;这样的方式会报错 RMAN-03009: failure of backup command on ORA_DISK_1 channel at 03/29/2016 09:24:29 ORA-19715:

[20121126]backup as copy datafile 1的问题.txt

[20121126]backup as copy datafile 1的问题.txt SQL> select * from v$version where rownumBANNER--------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production RMA

[20171121]rman使用copy image恢复.txt

[20171121]rman使用copy image恢复.txt --//上个星期做数据文件块头恢复时,提到使用rman备份数据文件时,文件头数据库信息是最后写入备份集文件的,在filesperset=1的情况 --//下写入备份集文件中的倒数第2块就是文件头的备份.参考链接: http://blog.itpub.net/267265/viewspace-2147297/=>[20171115]恢复数据文件块头4补充.txt --//而且我最后还做了测试证明如果resotre数据文件,实际上文件

[20160524]rman备份与检查点4.txt

[20160524]rman备份与检查点4.txt --链接: http://blog.itpub.net/267265/viewspace-2105221/ http://blog.itpub.net/267265/viewspace-2105223/ --昨晚仔细思考,重复测试看看,使用新的控制文件是否可以恢复.感觉我的问题在于我做了catalog注册了备份文件时丢失某些信息.重新 --测试看看. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING      

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

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

[20150601]rman备份出现坏块.txt

[20150601]rman备份出现坏块.txt --昨天看链接: http://www.jydba.net/磁盘损坏造成RMAN备份文件有坏块的恢复案例/ --提到如果备份片存在坏块的恢复案例,他使用的参数,我自己从来没见过. alter system set event='19548 trace name context forever', '19549 trace name context forever' scope=spfile; -- oerr ora 19548,oerr ora