[20161031]rman备份与数据文件变化2.txt

[20161031]rman备份与数据文件变化2.txt

--想象一下，如果备份文件时间很长，而这个时候数据文件大小发生了变化，oracle的备份如何解决这个问题呢？

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 2016-10-31 16:28:13 /mnt/ramdisk/book/sugar01.dbf

--当前大小10M+8k。 10*1024*1024+8192=10493952.

2.备份：

RMAN>  CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 128 K;
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

--开始备份：
RMAN> backup datafile 6 format '/u01/backup/d6_1_%U' ;
.....

--切换会话建立新表T2,T3。
create table t2 tablespace sugar as select rownum id ,lpad('B',32,'B') name from dual connect by level<=2e5;
--等1-2秒...
create table t3 tablespace sugar as select rownum id ,lpad('C',32,'C') name from dual connect by level<=2e5;
alter system checkponit;

$ ls -l /u01/backup/d6_1*
-rw-r----- 1 oracle oinstall 10518528 2016-10-31 16:45:06 /u01/backup/d6_1_0srjoknq_1_1
--可以发现是先产生备份文件的大小，然后再写入操作。

RMAN> backup datafile 6 format '/u01/backup/d6_1_%U' ;
Starting backup at 2016-10-31 16:44:41
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=46 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-10-31 16:44:42
channel ORA_DISK_1: finished piece 1 at 2016-10-31 16:46:07
piece handle=/u01/backup/d6_1_0srjoknq_1_1 tag=TAG20161031T164442 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:25
channel ORA_DISK_1: throttle time: 0:01:20
Finished backup at 2016-10-31 16:46:07
--需要将近1分20秒.

$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 27271168 2016-10-31 16:44:53 /mnt/ramdisk/book/sugar01.dbf

$ ls -l /u01/backup/d6_1*
-rw-r----- 1 oracle oinstall 6111232 2016-10-31 16:46:02 /u01/backup/d6_1_0srjoknq_1_1

--备份文件大小6111232/1024/1024=5.828125M,比开始生成的小。因为有一些是"NULL"块，我之所以带引号，主要是指先读位图信息，已
--经确定要扫描那些块。实际上那些块已经有数据写入。
--而现在数据文件已经是 27271168/1024/1024=26.0078125M.

--如果你查询BBBB，CCCC字符串可以发现根本不存在，也就是讲备份并没有做
$ strings  /u01/backup/d6_1* | grep 'BBBB'
$ strings  /u01/backup/d6_1* | grep 'CCCC'
$ strings  /u01/backup/d6_1_0srjoknq_1_1 | grep 'AAAA'|wc
100000  170040 3624269

SCOTT@book> select file#,CHECKPOINT_CHANGE#,ABSOLUTE_FUZZY_CHANGE# from v$backup_datafile;
FILE# CHECKPOINT_CHANGE# ABSOLUTE_FUZZY_CHANGE#
----- ------------------ ----------------------
    6            2374086                      0

--而且备份期间没有出现高于检查点scn高于2374086的scn号。

SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header where file#=6;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                                               TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------------------------- ------------------------------
    6            2374228 2016-10-31 16:44:53          2373657           2002065 ONLINE                 4 YES /mnt/ramdisk/book/sugar01.dbf                      SUGAR

--从这里可以看出备份时视乎已经确定要备份文件的大小，而且我觉得备份期间读取了位图信息，仅仅非NULL的块已经确定，应该是从文件头确定，而不管数据文件是否增加变大。
--你可以看出我已经发出了检查点，但是T2的信息，T3的信息并没有出现备份集中。

3.继续看看数据文件头在备份集什么位置：

--通过bbed观察：

BBED> set dba 6,1
        DBA             0x01800001 (25165825 6,1)

BBED> p kcvfh.kcvfhtln
ub2 kcvfhtln                                @336      0x0005

BBED> p kcvfh.kcvfhtnm
text kcvfhtnm[0]                            @338     S
text kcvfhtnm[1]                            @339     U
text kcvfhtnm[2]                            @340     G
text kcvfhtnm[3]                            @341     A
text kcvfhtnm[4]                            @342     R
text kcvfhtnm[5]                            @343
--可以发现表数据文件里面记录了表空间名字。前面一个字段kcvfh.kcvfhtln记录表空间名长度，正好是5。

$ strings -t d /u01/backup/d6_1_0srjoknq_1_1 | grep SUGAR
6095186 SUGAR

-- 6095186/8192=744.041259765625,相关记录在备份集中744块。也就是文件头最后写入备份集中。
-- 而实际备份集文件大小6111232, 6111232/8192=746块。也就是除掉备份集块头有745块(备份集也有1个OS块)

BBED> set filename '/u01/backup/d6_1_0srjoknq_1_1'
        FILENAME        /u01/backup/d6_1_0srjoknq_1_1

BBED> set block 744
        BLOCK#          744

BBED> p kcvfh.kcvfhtln
ub2 kcvfhtln                                @336      0x0005

BBED> p kcvfh.kcvfhtnm
text kcvfhtnm[0]                            @338     S
text kcvfhtnm[1]                            @339     U
text kcvfhtnm[2]                            @340     G
text kcvfhtnm[3]                            @341     A
text kcvfhtnm[4]                            @342     R
text kcvfhtnm[5]                            @343
...

BBED> set block 746
BBED-00309: out of range block number (746)

BBED> set block 745
        BLOCK#          745

BBED> set block 744
        BLOCK#          1350

BBED> p /d kcvfh.kcvfhcrs.kscnbas
ub4 kscnbas                                 @100      2373657

BBED> p /d kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas                                 @484      2374086

--//这个结果与数据块对应：

BBED> p  /d dba 6,1 kcvfh.kcvfhcrs.kscnbas
ub4 kscnbas                                 @100      2373657

BBED> p  /d dba 6,1 kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas                                 @484      2374228

--看看数据文件大小：
BBED> p /d dba 6,1  kcvfhhdr.kccfhfsz
ub4 kccfhfsz                                @44       5376

-- 5376*8192+8192=44048384
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 44048384 2016-10-31 12:10:13 /mnt/ramdisk/book/sugar01.dbf
--昏，估计触发了后台的11g表空间pre-allocation。现在变成26+16 =42M
--44048384-8192=44040192
--44040192/1024/1024=42M

BBED> p /d filename '/u01/backup/d6_1_0srjoknq_1_1' block 744 kcvfhhdr.kccfhfsz
ub4 kccfhfsz                                @44       1280

--1280*8192=10485760
--10485760/1024/1024=10M
--不过从这里看出是最后写文件头信息到备份集中的。

4.测试恢复看看：
SCOTT@book> alter database datafile 6 offline ;
Database altered.

RMAN> restore datafile 6;
Starting restore at 2016-10-31 17:04:53
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00006 to /mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: reading from backup piece /u01/backup/d6_1_0srjoknq_1_1
channel ORA_DISK_1: piece handle=/u01/backup/d6_1_0srjoknq_1_1 tag=TAG20161031T164442
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2016-10-31 17:04:54

$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 10493952 2016-10-31 17:04:53 /mnt/ramdisk/book/sugar01.dbf

$ strings  /mnt/ramdisk/book/sugar01.dbf | grep BBBB
$ strings  /mnt/ramdisk/book/sugar01.dbf | grep CCCC

--可以发现没有记录表T2,T3.

RMAN> recover datafile 6 ;

Starting recover at 2016-10-31 17:05:51
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2016-10-31 17:05:51

$ strings  /mnt/ramdisk/book/sugar01.dbf | grep BBBB|wc
200000  340080 7243181
$ strings  /mnt/ramdisk/book/sugar01.dbf | grep CCCC|wc
200000  340080 7243181
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 44048384 2016-10-31 17:05:51 /mnt/ramdisk/book/sugar01.dbf

--可以看到已经恢复。

SCOTT@book> alter database datafile 6 online ;
Database altered.

SCOTT@book> select rowid from t3 where rownum=1;
ROWID
------------------
AAAVsHAAGAAAAgDAAA

SCOTT@book> select rowid from t2 where rownum=1;
ROWID
------------------
AAAVsGAAGAAAAMDAAA

总结：
1.测试有一些乱，包括思路都有点乱。
2.我仅仅猜测备份时，文件大小就已经确定，最多10M。而具体读取那些块，我估计已经通过位图确定下来。
  你可以看到即使我发了alter system checkpoint命令，T2表的信息依旧没有备份。
3.我做了数据文件增加的情况，数据文件缩小有发生什么情况呢？看下一篇blog.