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

[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备份导致如何决定那些块需要备份呢,这个超出我的能力范围，放弃!!

总之：
在数据库备份期间最好不做数据库维护方面的工作。

时间： 2024-10-24 16:12:48

[20161101]rman备份与数据文件变化4.txt的相关文章

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

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

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

[20161031]rman备份与数据文件变化3.txt --想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --前面我已经做了增大数据文件,参考链接:http://blog.itpub.net/267265/viewspace-2127386/ --这次测试减少数据文件大小看看. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BAN

[20161102]rman备份与数据文件变化5.txt

[20161102]rman备份与数据文件变化5.txt --想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --前面我已经做了增大数据文件,参考链接:http://blog.itpub.net/267265/viewspace-2127386/ --这次测试减少数据文件大小看看.相关链接: http://blog.itpub.net/267265/viewspace-2127424/ http://blog.itpub.net/2672

[20171123]rman备份与数据文件变化6.txt

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

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

[20161031]rman备份与数据文件变化2.txt --想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -------------------------------------

[20161031]rman备份与数据文件OS块.txt

[20161031]rman备份与数据文件OS块.txt --每个数据文件都有一个OS块,位于数据文件的第1块(也是0块).通过bbed无法访问: BBED> set dba 7,0 BBED-00205: illegal or out of range DBA (File 7, Block 0) BBED> set dba 7,1         DBA             0x01c00001 (29360129 7,1) BBED> dump File: /mnt/ramdis

在open状态下恢复未备份的数据文件

        此文讲述如何恢复未备份的数据文件,在归档日志模式,如果dba增加了新的数据文件,当没有备份新的数据文件,那么该文件出现损坏时,可以恢复该数据文件.前提是 从建立新的数据文件到丢失为止的所有归档日志必须全部存在. 一 模拟实验环境.在数据文件test 里建立t1表 并插入数据,提交,归档日志文件. SQL> create table t(num number) tablespace test; 表已创建. SQL> insert into t values(1); 已创建 1 行

[20151125]数据文件的unrecover.txt

[20151125]数据文件的unrecover.txt --前一阵子我给别人演示truncate的不完全恢复,结果非常难堪的遇到无法恢复的情况. --问题是我建立的数据库按照这个链接建立的. http://blog.itpub.net/267265/viewspace-1845062/ --而这样建立的数据库表空间example的属性NOLOGGING. CREATE TABLESPACE EXAMPLE DATAFILE   '/mnt/ramdisk/book/example01.dbf'

[20171114]恢复数据文件块头2.txt

[20171114]恢复数据文件块头2.txt --//曾经写过一篇[20161111]数据库文件头的修复.txt,但是利用大小相似的数据文件头覆盖来恢复,那是属于特种恢复. --//参考链接:http://blog.itpub.net/267265/viewspace-2128309/ --//不在正常操作范围,完全是不得已而为之.基本写那篇在一年之前,这次做一个带引号"常规恢复"看看. --//后记:纯属无聊,千万不要把这当作常规的恢复. 1.环境: SCOTT@book>