[20161101]rman备份与数据文件变化4.txt
--想象一下，如果备份文件时间很长，而这个时候数据文件大小发生了变化，oracle的备份如何解决这个问题呢？
--前面我已经做了增大数据文件，参考链接：http://blog.itpub.net/267265/viewspace-2127386/
--这次测试减少数据文件大小看看。
--早上的测试太乱了，重复做1次看看。
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 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
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;
--建立大小5M的表。
create table t2 tablespace sugar as select rownum id ,lpad('B',32,'B') name from dual connect by level<=2e5;
create table t3 tablespace sugar as select rownum id ,lpad('C',32,'C') name from dual connect by level<=2e5;
alter system checkpoint;
SCOTT@book> select sum(bytes) from dba_extents where owner=user and segment_name like 'T%';
SUM(BYTES)
------------
26214400
--大约占用26214400/1024/1024=25m。
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-01 11:18:21 /mnt/ramdisk/book/sugar01.dbf
--当前大小40M+8k。 40*1024*1024+8192=41951232
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_X_%U' ;
.....
--切换会话删除表T2,T3,操作有点多，写入1个脚本abc.sql执行它。
drop table t2 purge ;
host sleep 1.5
drop table t3 purge ;
host sleep 1
alter system checkpoint;
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
alter system checkpoint;
$ ls -l /u01/backup/d6_X*
-rw-r----- 1 oracle oinstall 41975808 2016-11-01 11:20:09 /u01/backup/d6_X_1drjqm2h_1_1
--可以发现是先产生备份文件的大小，然后再写入操作。
--脚本执行期间遇到
SCOTT@book> @ abc.sql
Table dropped.
Table dropped.
System altered.
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M
*
ERROR at line 1:
ORA-19567: cannot shrink file /mnt/ramdisk/book/sugar01.dbf because it is being backed up or copied
System altered.
--可以发现在备份期间不能shrink表。
==============
$ oerr ora 19567
19567, 00000, "cannot shrink file %s because it is being backed up or copied"
// *Cause: An ALTER statement attempted to reduce the size of the indicated
// file while the same file is being backed up or copied.
// *Action: Retry the resize after the backup or copy is complete.
====================================
SCOTT@book> ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
Database altered.
--奇怪我手工执行又ok。非常奇怪。
--说明：这里我重复多次，都是先报错ora-19567,第2次执行都可以通过，估计是bug吗?
--再次证明第2次ok，说明oracle这里应该是bug。
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-01 11:20:03 /mnt/ramdisk/book/sugar01.dbf
--但是文件大小没有改变。而且出现这种情况备份很慢，比原来增加4分钟。
RMAN> backup datafile 6 format '/u01/backup/d6_X_%U' ;
Starting backup at 2016-11-01 11:19:44
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=68 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-11-01 11:19:45
channel ORA_DISK_1: finished piece 1 at 2016-11-01 11:25:10
piece handle=/u01/backup/d6_X_1drjqm2h_1_1 tag=TAG20161101T111944 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:05:25
channel ORA_DISK_1: throttle time: 0:05:20
Finished backup at 2016-11-01 11:25:10
Starting Control File and SPFILE Autobackup at 2016-11-01 11:25:10
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2016_11_01/o1_mf_s_926767510_d1j2rp4w_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2016-11-01 11:25:11
--需要将近5分20秒.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-01 11:20:03 /mnt/ramdisk/book/sugar01.dbf
--可以发现文件并没有shrink到10m。
SCOTT@book> ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
Database altered.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-01 11:20:03 /mnt/ramdisk/book/sugar01.dbf
--可以发现这个时候已经出现异常，无法shrink。或者内部一些字典已经修改了。
BBED> p /d dba 6,1 kcvfhhdr.kccfhfsz
ub4 kccfhfsz @44 5120
--可以发现执行ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;是失败的。
-- 5120*8192+8192=41951232
$ ls -l /u01/backup/d6_X_1drjqm2h_1_1
-rw-r----- 1 oracle oinstall 26083328 2016-11-01 11:25:05 /u01/backup/d6_X_1drjqm2h_1_1
$ strings /u01/backup/d6_X* | grep 'BBBB'|wc
200000 340080 7243655
$ strings /u01/backup/d6_X* | grep 'CCCC'|wc
200000 340080 7243655
$ strings /u01/backup/d6_X* | grep 'AAAA'|wc
100000 170040 3624269
--可以发现备份也做了T2,T3备份。
SCOTT@book> select file#,CHECKPOINT_CHANGE#,ABSOLUTE_FUZZY_CHANGE#,CREATION_TIME from v$backup_datafile;
FILE# CHECKPOINT_CHANGE# ABSOLUTE_FUZZY_CHANGE# CREATION_TIME
---------- ------------------ ---------------------- -------------------
6 2410456 0 2016-11-01 11:18:01
--而且备份期间没有出现高于检查点scn高于2410456的scn号。如果在备份期间，某个没有数据块写盘，SCN高于2410456，会记录在ABSOLUTE_FUZZY_CHANGE#最高的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 2410525 2016-11-01 11:20:03 2409950 2002065 ONLINE 8 YES /mnt/ramdisk/book/sugar01.dbf SUGAR
--从这里可以看出备份时视乎已经确定要备份文件的大小，而且我觉得备份期间读取了位图信息，仅仅非NULL的块已经确定，应该是从文
--件头位图确定，这个时候实际上不能缩小数据文件的。
--你可以看出我已经发出了检查点，但是T2的信息，T3的信息依旧出现备份集中。
--而且从前面的测试，明显存在问题，建议不要在备份期间做shrink数据文件的错误。数据字典已经不一致。
3.这个时候做一个备份看看：
RMAN> backup datafile 6 format '/u01/backup/d6_Y_%U' ;
Starting backup at 2016-11-01 11:36:55
using channel ORA_DISK_1
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-11-01 11:36:56
channel ORA_DISK_1: finished piece 1 at 2016-11-01 11:42:21
piece handle=/u01/backup/d6_Y_1grjqn2o_1_1 tag=TAG20161101T113655 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:05:25
channel ORA_DISK_1: throttle time: 0:05:20
Finished backup at 2016-11-01 11:42:21
Starting Control File and SPFILE Autobackup at 2016-11-01 11:42:21
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2016_11_01/o1_mf_s_926768541_d1j3rx58_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2016-11-01 11:42:22
--很奇怪依旧需要5分钟，估计是读太多了。
$ ls -l /u01/backup/d6_*
-rw-r----- 1 oracle oinstall 26083328 2016-11-01 11:25:05 /u01/backup/d6_X_1drjqm2h_1_1
-rw-r----- 1 oracle oinstall 21880832 2016-11-01 11:42:16 /u01/backup/d6_Y_1grjqn2o_1_1
--可以备份大小存在问题，正常不应该备份T2，T3对应的块，实际上现在存在问题的。
$ strings -t d /u01/backup/d6_Y_1grjqn2o_1_1 | grep BBBB |wc
116438 314501 5189314
$ strings -t d /u01/backup/d6_Y_1grjqn2o_1_1 | grep CCCC |wc
200000 540080 9043655
$ strings -t d /u01/backup/d6_Y_1grjqn2o_1_1 | grep AAAA |wc
100000 270040 4424269
--可以发现很奇怪的现象。
SCOTT@book> ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
Database altered.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-01 11:36:56 /mnt/ramdisk/book/sugar01.dbf
--//无效!!
SCOTT@book> ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 11M;
Database altered.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2016-11-01 11:36:56 /mnt/ramdisk/book/sugar01.dbf
--//无效!!
--仅仅设置9M,50M有效。
SCOTT@book> ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 50M;
Database altered.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 52436992 2016-11-01 11:49:51 /mnt/ramdisk/book/sugar01.dbf
--//有效!!
--//继续做备份测试：
RMAN> backup datafile 6 format '/u01/backup/d6_Z_%U' ;
Starting backup at 2016-11-01 11:50:42
using channel ORA_DISK_1
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-11-01 11:50:42
channel ORA_DISK_1: finished piece 1 at 2016-11-01 11:57:27
piece handle=/u01/backup/d6_Z_1irjqnsi_1_1 tag=TAG20161101T115042 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:06:45
channel ORA_DISK_1: throttle time: 0:06:40
Finished backup at 2016-11-01 11:57:27
Starting Control File and SPFILE Autobackup at 2016-11-01 11:57:27
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2016_11_01/o1_mf_s_926769447_d1j4o7g7_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2016-11-01 11:57:28
$ ls -l /u01/backup/d6_*
-rw-r----- 1 oracle oinstall 26083328 2016-11-01 11:25:05 /u01/backup/d6_X_1drjqm2h_1_1
-rw-r----- 1 oracle oinstall 21880832 2016-11-01 11:42:16 /u01/backup/d6_Y_1grjqn2o_1_1
-rw-r----- 1 oracle oinstall 6111232 2016-11-01 11:57:22 /u01/backup/d6_Z_1irjqnsi_1_1
--这次大小正确了。
$ strings -t d /u01/backup/d6_Z_1irjqnsi_1_1 | grep AAAA |wc
100000 270040 4424269
$ strings -t d /u01/backup/d6_Z_1irjqnsi_1_1 | grep BBBB |wc
0 0 0
$ strings -t d /u01/backup/d6_Z_1irjqnsi_1_1 | grep CCCC |wc
0 0 0
--看来以后不要在备份期间做维护操作。
4.重复测试：
SCOTT@book> ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 40M;
Database altered.
SCOTT@book> create table t2 tablespace sugar as select rownum id ,lpad('B',32,'B') name from dual connect by level<=2e5;
Table created.
SCOTT@book> create table t3 tablespace sugar as select rownum id ,lpad('C',32,'C') name from dual connect by level<=2e5;
Table created.
$ cat abc.sql
host sleep 1.5
drop table t2 purge ;
host sleep 1.5
drop table t3 purge ;
host sleep 1
alter system checkpoint;
@ &r/10046on 12
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
@ &r/10046off
alter system checkpoint;
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 128 K;
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
RMAN> backup datafile 6 format '/u01/backup/d6_A1_%U' ;
Starting backup at 2016-11-01 14:54:08
...
SCOTT@book> @ abc.sql
Table dropped.
Table dropped.
System altered.
old 1: alter session set events '10046 trace name context forever, level &1'
new 1: alter session set events '10046 trace name context forever, level 12'
Session altered.
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M
*
ERROR at line 1:
ORA-19567: cannot shrink file /mnt/ramdisk/book/sugar01.dbf because it is being backed up or copied
Session altered.
System altered.
SCOTT@book> select * from DBA_DATA_FILES;
FILE_NAME FILE_ID TABLESPACE_NAME BYTES BLOCKS STATUS RELATIVE_FNO AUT MAXBYTES MAXBLOCKS INCREMENT_BY USER_BYTES USER_BLOCKS ONLINE_
-------------------------------- ------- --------------- --------- ------ --------- ------------ --- ------------ ------------ ------------ ------------ ------------ -------
/mnt/ramdisk/book/users01.dbf 4 USERS 52428800 6400 AVAILABLE 4 YES 34359721984 4194302 160 51380224 6272 ONLINE
/mnt/ramdisk/book/undotbs01.dbf 3 UNDOTBS1 89128960 10880 AVAILABLE 3 YES 1073741824 131072 640 88080384 10752 ONLINE
/mnt/ramdisk/book/sysaux01.dbf 2 SYSAUX 817889280 99840 AVAILABLE 2 YES 34359721984 4194302 1280 816840704 99712 ONLINE
/mnt/ramdisk/book/system01.dbf 1 SYSTEM 786432000 96000 AVAILABLE 1 YES 34359721984 4194302 1280 785383424 95872 SYSTEM
/mnt/ramdisk/book/example01.dbf 5 EXAMPLE 328335360 40080 AVAILABLE 5 YES 34359721984 4194302 80 327286784 39952 ONLINE
/mnt/ramdisk/book/sugar01.dbf 6 SUGAR 10485760 1280 AVAILABLE 6 YES 34359721984 4194302 2048 9437184 1152 ONLINE
6 rows selected.
--实际上第1次执行ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M,问题已经再现，第2次仅仅是1个假象。
RMAN> backup datafile 6 format '/u01/backup/d6_A1_%U' ;
Starting backup at 2016-11-01 14:54:08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=68 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-11-01 14:54:08
channel ORA_DISK_1: finished piece 1 at 2016-11-01 14:59:33
piece handle=/u01/backup/d6_A1_1krjr2kg_1_1 tag=TAG20161101T145408 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:05:25
channel ORA_DISK_1: throttle time: 0:05:20
Finished backup at 2016-11-01 14:59:33
Starting Control File and SPFILE Autobackup at 2016-11-01 14:59:33
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2016_11_01/o1_mf_s_926780373_d1jhbodd_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2016-11-01 14:59:34
--//跟踪文件如下：
=====================
PARSING IN CURSOR #140274325604320 len=66 dep=0 uid=83 oct=35 lid=83 tim=1477983255600631 hv=1840685487 ad='7def9f20' sqlid='58jj94jqvd8dg'
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M
END OF STMT
PARSE #140274325604320:c=1000,e=759,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1477983255600626
WAIT #140274325604320: nam='control file sequential read' ela= 13 file#=0 block#=1 blocks=1 obj#=-1 tim=1477983255601009
WAIT #140274325604320: nam='control file sequential read' ela= 8 file#=1 block#=1 blocks=1 obj#=-1 tim=1477983255601063
WAIT #140274325604320: nam='control file sequential read' ela= 8 file#=0 block#=16 blocks=1 obj#=-1 tim=1477983255601093
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=0 block#=18 blocks=1 obj#=-1 tim=1477983255601121
WAIT #140274325604320: nam='control file sequential read' ela= 10 file#=0 block#=32 blocks=1 obj#=-1 tim=1477983255601160
WAIT #140274325604320: nam='control file sequential read' ela= 9 file#=0 block#=1 blocks=1 obj#=-1 tim=1477983255601239
WAIT #140274325604320: nam='control file sequential read' ela= 6 file#=1 block#=1 blocks=1 obj#=-1 tim=1477983255601278
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=0 block#=16 blocks=1 obj#=-1 tim=1477983255601306
WAIT #140274325604320: nam='control file sequential read' ela= 6 file#=0 block#=18 blocks=1 obj#=-1 tim=1477983255601333
WAIT #140274325604320: nam='control file sequential read' ela= 11 file#=0 block#=23 blocks=1 obj#=-1 tim=1477983255601382
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=0 block#=32 blocks=1 obj#=-1 tim=1477983255601423
WAIT #140274325604320: nam='control file sequential read' ela= 9 file#=0 block#=1 blocks=1 obj#=-1 tim=1477983255601506
WAIT #140274325604320: nam='control file sequential read' ela= 6 file#=1 block#=1 blocks=1 obj#=-1 tim=1477983255601545
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=0 block#=16 blocks=1 obj#=-1 tim=1477983255601573
WAIT #140274325604320: nam='control file sequential read' ela= 6 file#=0 block#=18 blocks=1 obj#=-1 tim=1477983255601600
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=0 block#=23 blocks=1 obj#=-1 tim=1477983255601633
WAIT #140274325604320: nam='db file sequential read' ela= 6 file#=6 block#=1 blocks=1 obj#=-1 tim=1477983255601665
WAIT #140274325604320: nam='control file sequential read' ela= 8 file#=0 block#=32 blocks=1 obj#=-1 tim=1477983255601700
WAIT #140274325604320: nam='control file sequential read' ela= 9 file#=0 block#=1 blocks=1 obj#=-1 tim=1477983255601780
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=1 block#=1 blocks=1 obj#=-1 tim=1477983255601819
WAIT #140274325604320: nam='control file sequential read' ela= 6 file#=0 block#=16 blocks=1 obj#=-1 tim=1477983255601846
WAIT #140274325604320: nam='control file sequential read' ela= 6 file#=0 block#=18 blocks=1 obj#=-1 tim=1477983255601874
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=0 block#=23 blocks=1 obj#=-1 tim=1477983255601931
WAIT #140274325604320: nam='control file sequential read' ela= 7 file#=0 block#=32 blocks=1 obj#=-1 tim=1477983255601961
WAIT #140274325604320: nam='db file sequential read' ela= 6 file#=6 block#=1 blocks=1 obj#=-1 tim=1477983255601991
WAIT #140274325604320: nam='Disk file operations I/O' ela= 420 FileOperation=2 fileno=0 filetype=2 obj#=-1 tim=1477983255602438
WAIT #140274325604320: nam='Disk file operations I/O' ela= 11 FileOperation=5 fileno=0 filetype=2 obj#=-1 tim=1477983255602543
EXEC #140274325604320:c=2000,e=1977,p=0,cr=0,cu=2,mis=0,r=0,dep=0,og=1,plh=0,tim=1477983255602708
ERROR #140274325604320:err=19567 tim=1477983255602733
=====================
SYS@book> execute dbms_space_admin.tablespace_dump_bitmaps('SUGAR');
PL/SQL procedure successfully completed.
--跟踪文件内容：
Header Control:
RelFno: 6, Unit: 8, Size: 1280, Flag: 9
AutoExtend: YES, Increment: 2048, MaxSize: 4194302
Initial Area: 126, Tail: 1279, First: 0, Free: 64
Deallocation scn: 2417402.0
Header Opcode:
Save: No Pending Op
File Space Bitmap Block:
BitMap Control:
RelFno: 6, BeginBlock: 128, Flag: 0, First: 80, Free: 63408
FFFFFFFFFFFFFFFF FFFF000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
-- 1bit 表示 64K。 F(0x1111) 表示4 bits.
-- 20*4*64*1024/8192=640块 ,640*8192/1024/1024=5M, 位图信息对的。
SYS@book> alter session set events 'immediate trace name controlf level 12';
Session altered.
--跟踪文件内容：
DATA FILE #6:
name #10: /mnt/ramdisk/book/sugar01.dbf
creation size=5120 block size=8192 status=0xe head=10 tail=10 dup=1
tablespace 7, index=7 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:15 scn: 0x0000.0024e303 11/01/2016 14:54:15
Stop scn: 0xffff.ffffffff 11/01/2016 11:18:01
Creation Checkpointed at scn: 0x0000.0024c5de 11/01/2016 11:18:01
thread:1 rba:(0x15.12e7a.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 5
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
--估计存在不一致导致的问题。但是rman备份导致如何决定那些块需要备份呢,这个超出我的能力范围，放弃!!
总之：
在数据库备份期间最好不做数据库维护方面的工作。
