[20161101]rman備份與資料檔案變化7.txt
[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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20161101]rman備份與資料檔案變化4.txt
- [20161031]rman備份與資料檔案變化3.txt
- [20161031]rman備份與資料檔案變化2.txt
- RMAN說，我能備份(4)--RMAN備份資料檔案和控制檔案
- [20161102]rman備份與資料檔案變化5.txt
- [20171123]rman備份與資料檔案變化6.txt
- RMAN備份資料檔案+控制檔案+歸檔日誌
- rman備份-（1） 利用備份級恢復資料檔案和控制檔案
- rman備份但丟失一個資料檔案,但有歸檔備份
- rman備份恢復-rman恢復資料檔案測試
- RMAN說，我能備份(5)--RMAN備份歸檔檔案
- RMAN備份檔案格式
- 非歸檔資料庫RMAN備份資料庫
- rman恢復資料庫--用備份的控制檔案資料庫
- rman備份檔案的格式
- Backup And Recovery User's Guide-備份資料庫-使用RMAN備份資料庫檔案GUIIDE資料庫
- [20161031]rman備份與資料檔案OS塊.txt
- rman全庫備份備份歸檔日誌檔案
- Backup And Recovery User's Guide-備份資料庫-使用RMAN備份控制檔案GUIIDE資料庫
- RMAN備份恢復典型案例——資料檔案存在壞快
- 非系統資料檔案損壞，rman備份恢復
- RMAN 驗證 資料檔案 和 備份 的有效性
- [20121127]rman備份資料檔案大小與truncate.txt
- Oracle RMAN 不完全恢復（只有資料檔案備份，丟失歸檔日誌備份）Oracle
- RMAN備份檔案遠大於資料庫大小的原因分析資料庫
- Backup And Recovery User's Guide-備份資料庫-使用RMAN備份表空間和資料檔案GUIIDE資料庫
- 基於oracle 11.2.0.4 rman data file copy以及增量scn備份資料檔案持續變化系列之一Oracle
- 基於oracle 11.2.0.4 rman data file copy以及增量scn備份資料檔案持續變化系列之二Oracle
- 用rman建立dataguard備用資料庫繼續(無法找到備份檔案)資料庫
- ORACLE 只讀資料檔案備份與恢復Oracle
- 使用RMAN備份資料庫資料庫
- rman資料庫全庫備份與恢復資料庫
- Oracle資料庫備份與恢復之RMANOracle資料庫
- 【備份恢復】歸檔模式下丟失系統關鍵資料檔案 利用RMAN備份恢復模式
- 【備份】RMAN中對控制檔案的幾種備份方法
- rman恢復--歸檔模式有備份，丟失資料檔案的恢復模式
- rman恢復--歸檔模式無備份，丟失資料檔案的恢復模式
- rman在歸檔與非歸檔時備份資料庫的簡單示例資料庫