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

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

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

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

--//上午的测试
http://blog.itpub.net/267265/viewspace-2147642/

--//本次测试在做image copy时,数据文件减少的情况,实际上根据前面的测试可以想像备份文件的大小不应该随数据文件大小而变化,
--//因为备份前要建立SNAPSHOT CONTROLFILE,一般以这个控制文件为准做的备份.

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 2017-11-23 15:41:17 /mnt/ramdisk/book/sugar01.dbf
--//当前大小40M+8k。 40*1024*1024+8192=41951232

2.备份前设置:

RMAN>  CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 256 K;
new RMAN configuration parameters:
CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 256 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> delete datafilecopy all;
RMAN> delete backup ;
--//删除旧备份.

3.开始备份:
--//建立测试脚本:
$ cat df_change1.sh
#! /bin/bash
rman target / <<EOF &
backup as copy datafile 7 format '/home/oracle/backup/%b' ;
quit
EOF
echo 'sleep 30 '
sleep 30
sqlplus scott/book <<EOF
drop table t2 purge ;
drop table t3 purge ;
alter system checkpoint;
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 10M;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
EOF

--//说明备份40M文件,前面1M是OS块,文件头,位图区,加上t1,t2,t3表5M,我选择备份到7M时开始删除表T2,T3,并且收缩表空间.
--//7*1024/256=28,备份到这个位置需要28秒(我设置30秒).

$ . df_change1.sh
$ . df_change1.sh
sleep 30

Recovery Manager: Release 11.2.0.4.0 - Production on Thu Nov 23 15:42:17 2017

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: BOOK (DBID=1337401710)

RMAN>
Starting backup at 2017-11-23 15:42:18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=132 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00007 name=/mnt/ramdisk/book/sugar01.dbf

SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 23 15:42:47 2017

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SCOTT@book>
Table dropped.

SCOTT@book>
Table dropped.

SCOTT@book>
System altered.

SCOTT@book> 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
--//执行收缩报错.

SCOTT@book>
System altered.

SCOTT@book>
System altered.

SCOTT@book>
System altered.

SCOTT@book>
System altered.

SCOTT@book>
Database altered.

SCOTT@book>
System altered.

SCOTT@book>
System altered.

SCOTT@book>
System altered.

SCOTT@book> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
--//注意看第2次执行没有报错.
$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 15:42:48 /mnt/ramdisk/book/sugar01.dbf
---//而实际上文件大小没有变化.所以在备份期间禁止做数据文件收缩操作!!

$ output file name=/home/oracle/backup/sugar01.dbf tag=TAG20171123T154219 RECID=37 STAMP=960824699
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:02:45
channel ORA_DISK_1: throttle time: 0:02:40
Finished backup at 2017-11-23 15:45:04

Starting Control File and SPFILE Autobackup at 2017-11-23 15:45:04
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2017_11_23/o1_mf_s_960824704_f1dz40to_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2017-11-23 15:45:05

RMAN>

Recovery Manager complete.

[1]+  Done                    rman target /  <<EOF
backup as copy datafile 7 format '/home/oracle/backup/%b' ;
quit
EOF

--//使用2:40秒完成备份.2*60+40=160秒.

$ ls -l /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 15:44:59 /home/oracle/backup/sugar01.dbf

--//可以发现完成备份后,与实际备份一样.

$ strings /home/oracle/backup/sugar01.dbf | grep "AAAA"|wc
100000  170040 3624077
$ strings /home/oracle/backup/sugar01.dbf | grep "BBBB"|wc
200000  340080 7243181
$ strings /home/oracle/backup/sugar01.dbf | grep "CCCC"|wc
200000  340080 7243181

--//可以发现即使我在备份中删除表T2,T3,实际上备份映像依旧备份.实际上与以前做备份集合的结果一样.

--//从这里可以看出备份时视乎已经确定要备份文件的大小,而且我觉得备份期间读取了位图信息,仅仅非NULL的块已经确定,应该是从文
--//件头位图确定,这个时候实际上不能缩小数据文件的。
--//你可以看出我已经发出了检查点,但是T2的信息,T3的信息依旧出现备份集中。
--//而且从前面的测试,明显存在问题,建议不要在备份期间做shrink数据文件的错误。数据字典已经不一致。

RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK clear;
using target database control file instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CHANNEL 1 DEVICE TYPE DISK RATE 256 K;
old RMAN configuration parameters are successfully deleted

RMAN> list datafilecopy all;
List of Datafile Copies
=======================

Key     File S Completion Time     Ckp SCN    Ckp Time
------- ---- - ------------------- ---------- -------------------
37      7    A 2017-11-23 15:44:59 13279924455 2017-11-23 15:42:19
        Name: /home/oracle/backup/sugar01.dbf
        Tag: TAG20171123T154219
--//备份的文件头scn=13279924455.

RMAN> validate copy of datafile 7 ;

Starting validate at 2017-11-23 15:51:03
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=67 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: including datafile copy of datafile 00007 in backup set
input file name=/home/oracle/backup/sugar01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafile Copies
=======================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
7    OK     0              1945         5120            13279924522
  File Name: /home/oracle/backup/sugar01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              2974
  Index      0              0
  Other      0              201
Finished validate at 2017-11-23 15:51:05

SCOTT@book> select recid,file#,NAME,CHECKPOINT_CHANGE#,ABSOLUTE_FUZZY_CHANGE# from v$datafile_copy where recid=37 ;
       RECID FILE# NAME                                               CHECKPOINT_CHANGE# ABSOLUTE_FUZZY_CHANGE#
------------ ----- -------------------------------------------------- ------------------ ----------------------
          37     7 /home/oracle/backup/sugar01.dbf                           13279924455            13279924523

--//有1个块scn号=13279924522.

select 13279924522,trunc(13279924522/power(2,32)) scn_wrap,mod(13279924522,power(2,32))  scn_base from dual
13279924522     SCN_WRAP     SCN_BASE SCN_WRAP16 SCN_BASE16
------------ ------------ ------------ ---------- ----------
13279924522            3    395022634          3   178b912a

--//反转以后 2a918b17

$ xxd -c 16 -g 4 /home/oracle/backup/sugar01.dbf | grep -i 2a918b17
1004000: 23a20000 0208c001 2a918b17 03001904  #.....?*.......

SCOTT@book> @ &r/16to10 1004000
16 to 10 DEC
------------
    16793600

--//16793600/8192=2050出现在2050块.

BBED> dump /v filename '/mnt/ramdisk/book/sugar01.dbf' block 130
File: /mnt/ramdisk/book/sugar01.dbf (7)
Block: 130                               Offsets:    0 to   63                            Dba:0x01c00082
-----------------------------------------------------------------------------------------------------------
23a20000 8200c001 f78f8b17 03000104 56df0000 00000000 00000000 00000000 l #...............V...............
00000000 14000000 80020000 9c0a0000 13000000 64000000 80000000 e402c001 l ....................d...........
<32 bytes per line>

BBED> dump /v filename '/mnt/ramdisk/book/sugar01.dbf' block 2050
File: /mnt/ramdisk/book/sugar01.dbf (7)
Block: 2050                              Offsets:    0 to   63                            Dba:0x01c00802
-----------------------------------------------------------------------------------------------------------
23a20000 0208c001 2a918b17 03001904 5adf0000 00000000 00000000 00000000 l #.......*.......Z...............
00000000 01000000 08000000 9c0a0000 01000000 42000000 80000000 c20cc001 l ....................B...........
<32 bytes per line>

--//类型=23是段头.

SCOTT@book> select OWNER,SEGMENT_NAME,SEGMENT_TYPE,HEADER_FILE,HEADER_BLOCK from dba_segments where owner=user and segment_name='T1';
OWNER  SEGMENT_NAME         SEGMENT_TYPE        HEADER_FILE HEADER_BLOCK
------ -------------------- ------------------ ------------ ------------
SCOTT  T1                   TABLE                         7          130

--//这也与我前面的测试是符合的,我备份开始后sleep 30秒,再删除表T2,T3.
--//30*256/1024=7.5,这样才7.5M的位置,而T1表占5M.前面占1M(OS 文件头 位图区).T2的文件头已经备份.而T3的还没有开始备份.

4.继续测试:
RMAN> backup as copy datafile 7 format '/home/oracle/backup/%b_xxx';
Starting backup at 2017-11-23 16:08:39
using channel ORA_DISK_1
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_xxx tag=TAG20171123T160839 RECID=39 STAMP=960826120
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 2017-11-23 16:08:41
Starting Control File and SPFILE Autobackup at 2017-11-23 16:08:41
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2017_11_23/o1_mf_s_960826121_f1f0j95x_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2017-11-23 16:08:42

$ ls -l /home/oracle/backup/sugar01*
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 15:44:59 /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 16:08:40 /home/oracle/backup/sugar01.dbf_xxx
--//大小是没有变化的.

$ strings /home/oracle/backup/sugar01.dbf_xxx | grep "AAAA" |wc
100000  170040 3624077
$ strings /home/oracle/backup/sugar01.dbf_xxx | grep "BBBB" |wc
200000  340080 7243181
$ strings /home/oracle/backup/sugar01.dbf_xxx | grep "CCCC" |wc
200000  340080 7243181
--//也许image备份只要格式化的块都备份.

--//做备份集备份看看:
RMAN> backup  datafile 7 format '/home/oracle/backup/suagr_xxx_%U';
--//不小心把sugar输错了!!
Starting backup at 2017-11-23 16:16:51
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=00007 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2017-11-23 16:16:51
channel ORA_DISK_1: finished piece 1 at 2017-11-23 16:16:52
piece handle=/home/oracle/backup/suagr_xxx_j6ska37j_1_1 tag=TAG20171123T161651 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2017-11-23 16:16:52
Starting Control File and SPFILE Autobackup at 2017-11-23 16:16:52
piece handle=/u01/app/oracle/fast_recovery_area/BOOK/autobackup/2017_11_23/o1_mf_s_960826612_f1f0znr4_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2017-11-23 16:16:53

$ ls -l /home/oracle/backup/su*
-rw-r----- 1 oracle oinstall 21880832 2017-11-23 16:16:51 /home/oracle/backup/suagr_xxx_j6ska37j_1_1
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 15:44:59 /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 16:08:40 /home/oracle/backup/sugar01.dbf_xxx

$ strings /home/oracle/backup/suagr_xxx_j6ska37j_1_1 | grep "AAAA" |wc
100000  170040 3624269
$ strings /home/oracle/backup/suagr_xxx_j6ska37j_1_1 | grep "BBBB" |wc
116438  198063 4220273
$ strings /home/oracle/backup/suagr_xxx_j6ska37j_1_1 | grep "CCCC" |wc
200000  340080 7243655

--//你可以发现T2表仅仅备份1部分,而T3表的块反而做了全部备份.实际上这个问题在我以前的测试中已经说明,看DBA_DATA_FILES已经出现错误.

SCOTT@book>  select * from DBA_DATA_FILES order by file_id;
FILE_NAME                        FILE_ID TABLESPACE_NAME        BYTES BLOCKS STATUS    RELATIVE_FNO AUT    MAXBYTES MAXBLOCKS INCREMENT_BY USER_BYTES  USER_BLOCKS ONLINE_
-------------------------------- ------- --------------- ------------ ------ --------- ------------ --- ----------- --------- ------------ ---------- ------------ -------
/mnt/ramdisk/book/system01.dbf         1 SYSTEM             796917760  97280 AVAILABLE            1 YES 34359721984   4194302         1280  795869184        97152 SYSTEM
/mnt/ramdisk/book/sysaux01.dbf         2 SYSAUX             985661440 120320 AVAILABLE            2 YES 34359721984   4194302         1280  984612864       120192 ONLINE
/mnt/ramdisk/book/undotbs01.dbf        3 UNDOTBS1          1127219200 137600 AVAILABLE            3 YES 34359721984   4194302          640 1126170624       137472 ONLINE
/mnt/ramdisk/book/users01.dbf          4 USERS             2271215616 277248 AVAILABLE            4 YES 34359721984   4194302          160 2270167040       277120 ONLINE
/mnt/ramdisk/book/example01.dbf        5 EXAMPLE            363069440  44320 AVAILABLE            5 YES 34359721984   4194302           80  362020864        44192 ONLINE
/mnt/ramdisk/book/tea01.dbf            6 TEA                 44040192   5376 AVAILABLE            6 YES 34359721984   4194302          128   42991616         5248 ONLINE
/mnt/ramdisk/book/sugar01.dbf          7 SUGAR               10485760   1280 AVAILABLE            7 YES 34359721984   4194302         2048    9437184         1152 ONLINE
7 rows selected.

--//注意看表空间SUGAR的BYTES=10485760,10M.而实际上现在看到的是40M.
--//我在链接做了一些猜测与说明:http://blog.itpub.net/267265/viewspace-2127569/
--//问题在于两个备份大约相差4M,实际上10M以上的非空块,虽然在前面的位图块已经为0(标识未使用),但是属于异常情况,oracle认为只要是格式化的块,就都做了备份.

--//理论如果T1,T2,T3都在备份大约1+5+10+10=26M.前面10M仅仅需要备份6M.后面16M也做了备份(只要是格式化的块,就都做了备份)
--//这样备份集合大小大约22M.存在一些误差.那篇文章分析太复杂了,总之大概就是这样.


5.出现这种情况如何解决呢?
--//如果执行如下,没用.

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 2017-11-23 16:16:51 /mnt/ramdisk/book/sugar01.dbf

--//resize在10M-40M之间也没用.
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 2017-11-23 16:16:51 /mnt/ramdisk/book/sugar01.dbf

SCOTT@book> select * from DBA_DATA_FILES where file_id=7 order by file_id ;
FILE_NAME                     FILE_ID TABLESPACE_NAME    BYTES       BLOCKS STATUS    RELATIVE_FNO AUT     MAXBYTES    MAXBLOCKS INCREMENT_BY   USER_BYTES  USER_BLOCKS ONLINE_
----------------------------- ------- --------------- -------- ------------ --------- ------------ --- ------------ ------------ ------------ ------------ ------------ -------
/mnt/ramdisk/book/sugar01.dbf       7 SUGAR           11534336         1408 AVAILABLE            7 YES  34359721984      4194302         2048     10485760         1280 ONLINE
--//你可以发现查询这个视图变成了11M,而是显示文件大小没有变化.
--//只有2种可能解决这个问题,resize大小在10-40M之外,比如9M,或者41M就ok了.(当前前提是还能收缩)

SCOTT@book> ALTER DATABASE DATAFILE '/mnt/ramdisk/book/sugar01.dbf' RESIZE 9M ;
Database altered.

$ ls -l /mnt/ramdisk/book/sugar01.dbf
-rw-r----- 1 oracle oinstall 9445376 2017-11-23 16:49:32 /mnt/ramdisk/book/sugar01.dbf

--//总之不要在备份期间做收缩数据文件的操作.这个时候做备份看看.

RMAN> backup  datafile 7 format '/home/oracle/backup/sugar_yyy_%U';
RMAN> backup as copy datafile 7 format '/home/oracle/backup/%b_yyy';

$ ls -l /home/oracle/backup/su*
-rw-r----- 1 oracle oinstall 21880832 2017-11-23 16:16:51 /home/oracle/backup/suagr_xxx_j6ska37j_1_1
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 15:44:59 /home/oracle/backup/sugar01.dbf
-rw-r----- 1 oracle oinstall 41951232 2017-11-23 16:08:40 /home/oracle/backup/sugar01.dbf_xxx
-rw-r----- 1 oracle oinstall  9445376 2017-11-23 16:50:59 /home/oracle/backup/sugar01.dbf_yyy
-rw-r----- 1 oracle oinstall  6111232 2017-11-23 16:50:48 /home/oracle/backup/sugar_yyy_j8ska578_1_1

$ strings /home/oracle/backup/sugar01.dbf_yyy |grep "BBBBB" |wc
  62394  106045 2256986

$ strings /home/oracle/backup/sugar01.dbf_yyy |grep "CCCC" |wc
      0       0       0
--//也再次说明image备份只要格式化的数据块都备份.

$ strings /home/oracle/backup/sugar_yyy_j8ska578_1_1 |grep "BBBB" |wc
      0       0       0
$ strings /home/oracle/backup/sugar_yyy_j8ska578_1_1 |grep "CCCC" |wc
      0       0       0

--//你可以发现现在的备份集合没有没有T2,T2的备份.
--//62394+116438=178832
--//200000-178832=21168
--//数据文件大小相差1M的量,因为resize 9M.差不多就是相差20000条.不再探究了.

总之:
--//再次提醒,在数据库备份期间最好不做数据库维护方面的工作。
--//补充还是探究看看1M大小到底放多少记录.

SCOTT@book> column PARTITION_NAME noprint
SCOTT@book> select * from dba_extents where segment_name='T1';
OWNER  SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID   BYTES BLOCKS RELATIVE_FNO
------ ------------ ------------ --------------- --------- ------- -------- ------- ------ ------------
SCOTT  T1           TABLE        SUGAR                   0       7      128   65536      8            7
SCOTT  T1           TABLE        SUGAR                   1       7      136   65536      8            7
SCOTT  T1           TABLE        SUGAR                   2       7      144   65536      8            7
SCOTT  T1           TABLE        SUGAR                   3       7      152   65536      8            7
SCOTT  T1           TABLE        SUGAR                   4       7      160   65536      8            7
SCOTT  T1           TABLE        SUGAR                   5       7      168   65536      8            7
SCOTT  T1           TABLE        SUGAR                   6       7      176   65536      8            7
SCOTT  T1           TABLE        SUGAR                   7       7      184   65536      8            7
SCOTT  T1           TABLE        SUGAR                   8       7      192   65536      8            7
SCOTT  T1           TABLE        SUGAR                   9       7      200   65536      8            7
SCOTT  T1           TABLE        SUGAR                  10       7      208   65536      8            7
SCOTT  T1           TABLE        SUGAR                  11       7      216   65536      8            7
SCOTT  T1           TABLE        SUGAR                  12       7      224   65536      8            7
SCOTT  T1           TABLE        SUGAR                  13       7      232   65536      8            7
SCOTT  T1           TABLE        SUGAR                  14       7      240   65536      8            7
SCOTT  T1           TABLE        SUGAR                  15       7      248   65536      8            7
SCOTT  T1           TABLE        SUGAR                  16       7      256 1048576    128            7
SCOTT  T1           TABLE        SUGAR                  17       7      384 1048576    128            7
SCOTT  T1           TABLE        SUGAR                  18       7      512 1048576    128            7
SCOTT  T1           TABLE        SUGAR                  19       7      640 1048576    128            7
20 rows selected.

SCOTT@book> select count(*) from t1 where DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid) between 256 and 383;
    COUNT(*)
------------
       21168

SCOTT@book> select count(*) from t1 where DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid) between 384 and 511;
    COUNT(*)
------------
       21168

SCOTT@book> select count(*) from t1 where DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid) between 512 and 639;
    COUNT(*)
------------
       21168

--//哈哈,如此惊人的吻合,也验证我的判断是对的.

目录
相关文章
|
SQL Oracle 关系型数据库
[20171225]没有备份数据文件的恢复.txt
[20171225]没有备份数据文件的恢复.txt --//别人问的问题,增加了数据文件没有备份,如何恢复,实际上很简单,因为当前控制文件有记录建立时间只要从建立数据文件开始的 --//归档日志都存在恢复是没有任何问题的.
893 0
|
Oracle 关系型数据库 OLAP
[20171123]rman备份与数据文件变化6.txt
[20171123]rman备份与数据文件变化6.txt --//想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --//去年已经测试了建立备份集的情况,一直想做一次image copy的测试,一直脱,主要原因自己不想做这个测试.
778 0
|
Oracle 关系型数据库 数据库
[20171122]恢复数据文件块头5.txt
[20171122]恢复数据文件块头5.txt --//前几天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//今天测试使用image copy来恢复.
1093 0
|
Oracle 关系型数据库 数据库
[20171114]恢复数据文件块头2.txt
[20171114]恢复数据文件块头2.txt --//曾经写过一篇[20161111]数据库文件头的修复.txt,但是利用大小相似的数据文件头覆盖来恢复,那是属于特种恢复.
1054 0
|
SQL Oracle 关系型数据库
[20170627]使用TSPITR恢复表空间.txt
[20170627]使用TSPITR恢复表空间.txt --//RMAN提供了一种实现所谓TSPITR(Tablespace Point-In-Time Recovery)的技术,通过简单的一个语句,就可以在主库不停库(很吸引人) --//的情况下,利用备份集和连续的归档日志,实现表空间级别的定点恢复。
881 0
|
Oracle 关系型数据库 数据库管理
[20161102]rman备份与数据文件变化5.txt
[20161102]rman备份与数据文件变化5.txt --想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --前面我已经做了增大数据文件,参考链接:http://blog.itpub.net/267265/viewspace-2127386/ --这次测试减少数据文件大小看看。
701 0

相关实验场景

更多