[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
--//哈哈,如此惊人的吻合,也验证我的判断是对的.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/267265/viewspace-2147673/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/267265/viewspace-2147673/
扫一扫
382
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
