只讀數(shù)據(jù)文件損壞恢復(fù)實(shí)驗(yàn)記錄

1、只讀表空間的數(shù)據(jù)文件指為只讀數(shù)據(jù)文件(read only)，當(dāng)一個(gè)表空間從read write更改為read only時(shí)，該數(shù)據(jù)文件里已經(jīng)產(chǎn)生的臟塊兒都會(huì)由DBWn寫(xiě)到磁盤(pán)，完成一次不完整的完全檢查點(diǎn)。從這一刻起，該數(shù)據(jù)文件數(shù)據(jù)塊和文件頭信息都不再更新，包括檢查點(diǎn)。在以后open數(shù)據(jù)庫(kù)時(shí)實(shí)例也忽略該只讀數(shù)據(jù)文件文件頭的檢查點(diǎn)SCN與其他數(shù)據(jù)文件或聯(lián)機(jī)REDO日志的同步。我們可以通過(guò)以下命令在read only和read write之間進(jìn)行更改read write > read only:alter tablespace tablespace_name read only;read onl

2、y > read write:alter tablespace tablespace_name read write;查看系統(tǒng)里的只讀表空間及其只讀數(shù)據(jù)文件：sysMAA> col TABLESPACE_NAME for a20sysMAA> col FILE_NAME for a65sysMAA> select t.tablespace_name, d.file_id, d.file_name from dba_tablespaces t, dba_data_files d 2 where t.tablespace_name=d.tablespace_name 3 a

3、nd t.status='READ ONLY' 4 /TABLESPACE_NAME FILE_ID FILE_NAME- - -LTB 12 /u01/app/oracle/oradata/ltb01.dbf下面我們針對(duì)以下幾種場(chǎng)景進(jìn)行恢復(fù)：1）控制文件無(wú)損，數(shù)據(jù)庫(kù)運(yùn)行時(shí)丟失了只讀數(shù)據(jù)文件，訪問(wèn)其內(nèi)數(shù)據(jù)報(bào)錯(cuò)2）控制文件無(wú)損，只讀數(shù)據(jù)文件丟失，數(shù)據(jù)庫(kù)無(wú)法OPEN3）控制文件無(wú)損，只讀數(shù)據(jù)文件頭部損壞4）控制文件無(wú)損，有讀寫(xiě)狀態(tài)時(shí)候的備份，后來(lái)更改為只讀狀態(tài)，只讀狀態(tài)時(shí)數(shù)據(jù)文件損壞5）控制文件無(wú)損，有只讀狀態(tài)時(shí)候的備份，后來(lái)更改為讀寫(xiě)狀態(tài)，讀寫(xiě)狀態(tài)時(shí)數(shù)據(jù)文件損壞6）控制文件損壞，

4、只讀數(shù)據(jù)文件損壞7）控制文件損壞，有只讀數(shù)據(jù)文件狀態(tài)時(shí)候的控制文件備份，后來(lái)數(shù)據(jù)文件改為讀寫(xiě)，讀寫(xiě)狀態(tài)時(shí)數(shù)據(jù)文件損壞8）控制文件損壞，在線(xiàn)日志文件沒(méi)有損壞，歸檔日志丟失，有舊的跟蹤控制文件trace，數(shù)據(jù)庫(kù)里有只讀數(shù)據(jù)文件前提條件，有相應(yīng)的備份。操作環(huán)境：· OS : Oracle Enterprise Linux 5.5 64Bit· DB Type : Oracle Restart· DB Version : 11.2.0.3準(zhǔn)備一個(gè)實(shí)驗(yàn)對(duì)象只讀表空間sysMAA> create tablespace ltb datafile '/u01/app

5、/oracle/oradata/ltb01.dbf' size 50M;sysMAA> create user l identified by oracle default tablespace ltb;sysMAA> grant resource, connect to l;sysMAA> create table l.luocs(domain varchar2(100);sysMAA> insert into l.luocs values('');sysMAA> commit;sysMAA> alter tablespace lt

6、b read only;場(chǎng)景1：控制文件無(wú)損，數(shù)據(jù)庫(kù)運(yùn)行時(shí)只讀數(shù)據(jù)文件損壞，訪問(wèn)其內(nèi)數(shù)據(jù)報(bào)錯(cuò)備份只讀表空間ltbRMAN> backup tablespace ltb;Starting backup at 23-DEC-2012 18:29:30using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=44 device type=DISKchannel ORA_DISK_1: starting full datafi

7、le backup setchannel ORA_DISK_1: specifying datafile(s) in backup setinput datafile file number=00012 name=/u01/app/oracle/oradata/ltb01.dbfchannel ORA_DISK_1: starting piece 1 at 23-DEC-2012 18:29:31channel ORA_DISK_1: finished piece 1 at 23-DEC-2012 18:29:32piece handle=/u01/recovery/MAA/backupset

8、/2012_12_23/o1_mf_nnndf_TAG20121223T182931_8ffq8cbz_.bkp tag=TAG20121223T182931 comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:01Finished backup at 23-DEC-2012 18:29:32數(shù)據(jù)庫(kù)運(yùn)行狀態(tài)下，破壞只讀數(shù)據(jù)文件以模擬損壞oraclemaa3 $ dd if=/dev/zero of=/u01/app/oracle/oradata/ltb01.dbf bs=10M count=55+0

9、records in5+0 records out52428800 bytes (52 MB) copied, 0.04918 seconds, 1.1 GB/s查看v$datafile內(nèi)容時(shí)，返回正常sysMAA> col NAME for a65sysMAA> select checkpoint_change# from v$datafile where file#=12;CHECKPOINT_CHANGE# - 3567837 但日志里將報(bào)錯(cuò)：Hex dump of (file 12, block 1) in trace file /u01/app/oracle/diag/r

10、dbms/maa/maa/trace/maa_m000_5343.trcCorrupt block relative dba: 0x03000001 (file 12, block 1)Completely zero block found during kcvxfh v8Reading datafile '/u01/app/oracle/oradata/ltb01.dbf' for corruption at rdba: 0x03000001 (file 12, block 1)Reread (file 12, block 1) found different corrupt

11、 data (no logical check)Hex dump of (file 12, block 1) in trace file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_m000_5343.trcCorrupt block relative dba: 0x03000001 (file 12, block 1)Completely zero block found during reread訪問(wèn)該數(shù)據(jù)文件里的數(shù)據(jù)：sysMAA> select * from l.luocs;select * from l.luocs*ERROR at

12、 line 1:ORA-01578: ORACLE data block corrupted (file # 12, block # 138)ORA-01110: data file 12: '/u01/app/oracle/oradata/ltb01.dbf'告警日志也會(huì)拋出相應(yīng)錯(cuò)誤信息：Hex dump of (file 12, block 2) in trace file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ora_5220.trcCorrupt block relative dba: 0x03000002 (file

13、 12, block 2)Completely zero block found during buffer readReading datafile '/u01/app/oracle/oradata/ltb01.dbf' for corruption at rdba: 0x03000002 (file 12, block 2)Reread (file 12, block 2) found same corrupt data (no logical check)Sun Dec 23 19:56:00 2012Corrupt Block Found TSN = 7, TSNAME

14、 = LTB RFN = 12, BLK = 2, RDBA = 50331650 OBJN = -1, OBJD = -1, OBJECT = , SUBOBJECT = SEGMENT OWNER = , SEGMENT TYPE = Errors in file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ora_5220.trc (incident=31391):ORA-01578: ORACLE data block corrupted (file # 12, block # 2)ORA-01110: data file 12: '

15、;/u01/app/oracle/oradata/ltb01.dbf'Hex dump of (file 12, block 1) in trace file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ora_5220.trcCorrupt block relative dba: 0x00000001 (file 12, block 1)Completely zero block found during validating datafile for block rangeReread of blocknum=1, file=/u01/

16、app/oracle/oradata/ltb01.dbf. found same corrupt dataReread of blocknum=1, file=/u01/app/oracle/oradata/ltb01.dbf. found same corrupt dataReread of blocknum=1, file=/u01/app/oracle/oradata/ltb01.dbf. found same corrupt dataReread of blocknum=1, file=/u01/app/oracle/oradata/ltb01.dbf. found same corr

17、upt dataReread of blocknum=1, file=/u01/app/oracle/oradata/ltb01.dbf. found same corrupt dataErrors in file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ora_5220.trc:ORA-19563: datafile header validation failed for file /u01/app/oracle/oradata/ltb01.dbfORA-01251: Unknown File Header Version read for

18、 file number 12ORA-01578: ORACLE data block corrupted (file # 12, block # 2)ORA-01110: data file 12: '/u01/app/oracle/oradata/ltb01.dbf'Sun Dec 23 19:56:01 2012Sweep inc31391: completed但此時(shí)只讀數(shù)據(jù)文件狀態(tài)還是ONLINEsysMAA> col FILE_NAME for a65sysMAA> select file_id, file_name, online_status from

19、 dba_data_files where tablespace_name='LTB' FILE_ID FILE_NAME ONLINE_STATUS- - - 12 /u01/app/oracle/oradata/ltb01.dbf ONLINE這里恢復(fù)需要注意，如果只是有數(shù)據(jù)訛誤塊兒導(dǎo)致數(shù)據(jù)訪問(wèn)報(bào)錯(cuò)，那可以簡(jiǎn)單通過(guò)RMAN的塊恢復(fù)命令進(jìn)行塊級(jí)別恢復(fù)。但這里我是將整個(gè)數(shù)據(jù)文件破壞掉了，因此需要RMAN來(lái)還原數(shù)據(jù)文件，恢復(fù)可以在數(shù)據(jù)文件OPEN模式進(jìn)行這時(shí)候我們直接RESTORE DATAFILE是不可行的，我們需要先將只讀數(shù)據(jù)文件脫機(jī)處理，還原之后再ONLINERMAN>

20、; restore tablespace ltb;Starting restore at 23-DEC-2012 19:46:43using channel ORA_DISK_1channel ORA_DISK_1: starting datafile backup set restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setchannel ORA_DISK_1: restoring datafile 00012 to /u01/app/oracle/oradata/ltb01.dbfchann

21、el ORA_DISK_1: reading from backup piece /u01/recovery/MAA/backupset/2012_12_23/o1_mf_nnndf_TAG20121223T184851_8ffrdmhg_.bkpRMAN-00571: =RMAN-00569: = ERROR MESSAGE STACK FOLLOWS =RMAN-00571: =RMAN-03002: failure of restore command at 12/23/2012 19:46:44ORA-19870: error while restoring backup piece

22、/u01/recovery/MAA/backupset/2012_12_23/o1_mf_nnndf_TAG20121223T184851_8ffrdmhg_.bkpORA-19573: cannot obtain exclusive enqueue for datafile 12正確的做法RMAN> run2> sql 'alter database datafile 12 offline'3> restore tablespace ltb;4> sql 'alter database datafile 12 online'5>

23、sql statement: alter database datafile 12 offlineStarting restore at 23-DEC-2012 19:50:41using channel ORA_DISK_1channel ORA_DISK_1: starting datafile backup set restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setchannel ORA_DISK_1: restoring datafile 00012 to /u01/app/oracl

24、e/oradata/ltb01.dbfchannel ORA_DISK_1: reading from backup piece /u01/recovery/MAA/backupset/2012_12_23/o1_mf_nnndf_TAG20121223T184851_8ffrdmhg_.bkpchannel ORA_DISK_1: piece handle=/u01/recovery/MAA/backupset/2012_12_23/o1_mf_nnndf_TAG20121223T184851_8ffrdmhg_.bkp tag=TAG20121223T184851channel ORA_D

25、ISK_1: restored backup piece 1channel ORA_DISK_1: restore complete, elapsed time: 00:00:03Finished restore at 23-DEC-2012 19:50:44sql statement: alter database datafile 12 online恢復(fù)后數(shù)據(jù)訪問(wèn)正常：sysMAA> select * from l.luocs;DOMAIN-當(dāng)然我們要是有鏡像備份文件，也可以SWITCHRMAN> backup as copy tablespace ltb;Starting b

26、ackup at 23-DEC-2012 19:54:34using channel ORA_DISK_1channel ORA_DISK_1: starting datafile copyinput datafile file number=00012 name=/u01/app/oracle/oradata/ltb01.dbfoutput file name=/u01/recovery/MAA/datafile/o1_mf_ltb_8ffw7tk0_.dbf tag=TAG20121223T195434 RECID=23 STAMP=802814075channel ORA_DISK_1:

27、 datafile copy complete, elapsed time: 00:00:01Finished backup at 23-DEC-2012 19:54:35在發(fā)現(xiàn)只讀數(shù)據(jù)文件損壞的情況下RMAN> run2> sql 'alter database datafile 12 offline'3> switch datafile 12 to datafilecopy '/u01/recovery/MAA/datafile/o1_mf_ltb_8ffw7tk0_.dbf'4> sql 'alter database da

28、tafile 12 online'5> sql statement: alter database datafile 12 offlinedatafile 12 switched to datafile copyinput datafile copy RECID=23 STAMP=802814075 file name=/u01/recovery/MAA/datafile/o1_mf_ltb_8ffw7tk0_.dbfsql statement: alter database datafile 12 online已經(jīng)成功SWITCH，可查看v$datafile進(jìn)行確認(rèn)sysMAA

29、> select checkpoint_change#, name from v$datafile where file#=12;CHECKPOINT_CHANGE# NAME- - 3567837 /u01/recovery/MAA/datafile/o1_mf_ltb_8ffw7tk0_.dbf查看數(shù)據(jù)也正常sysMAA> select * from l.luocs;DOMAIN-最后別忘了將損壞了SWITCH之前的數(shù)據(jù)文件進(jìn)行刪除oraclemaa3 $ rm -rf /u01/app/oracle/oradata/ltb01.dbf那有人可能會(huì)奇怪，如果直接刪除掉只讀數(shù)據(jù)文

30、件，那不也是一樣的效果嗎？但其實(shí)不然刪除只讀數(shù)據(jù)文件以模擬丟失oraclemaa3 $ rm -rf /u01/app/oracle/oradata/ltb01.dbfsysMAA> alter system checkpoint;System altered.sysMAA> alter system flush buffer_cache;System altered.sysMAA> select * from l.luocs;DOMAIN-可見(jiàn)我們數(shù)據(jù)依然正常訪問(wèn)，這里需要了解文件描述符的知識(shí)EYGLE的數(shù)據(jù)安全警示錄里有通過(guò)文件描述符進(jìn)行恢復(fù)的案例，其中有下面這么一段話(huà)：

31、在UNIX、Linux系統(tǒng)中，誤刪除數(shù)據(jù)文件后，雖然該文件已從操作系統(tǒng)中刪除，但是其文件句柄仍由數(shù)據(jù)庫(kù)進(jìn)程打開(kāi)持有，所以在數(shù)據(jù)庫(kù)層面仍然不會(huì)釋放其鏈表信息，因而也就能夠從進(jìn)程的地址信息中，通過(guò)復(fù)制將其直接恢復(fù)。但是請(qǐng)注意，這要求數(shù)據(jù)庫(kù)不能中途關(guān)閉，如果關(guān)閉了數(shù)據(jù)庫(kù)，則所有文件句柄被釋放，文件就真的難以回歸了。下面我從文件描述符中進(jìn)行數(shù)據(jù)文件的恢復(fù)：oraclemaa3 $ ps -ef | grep dbw | grep -v grepgrid 4817 1 0 Dec19 ? 00:00:00 asm_dbw0_+ASMoracle 6578 1 0 20:39 ? 00:00:00 ora

32、_dbw0_maarootmaa3 # ls /proc/6578/fd0 1 10 11 12 13 14 15 16 17 2 20 21 22 23 24 25 256 257 26 27 28 3 4 5 6 7 8 9rootmaa3 # ls -l /proc/6578/fd/12 lr-x- 1 root root 64 Dec 23 21:05 /proc/6578/fd/12 -> /dev/nullrootmaa3 # ls -l /proc/6578/fd/ | grep oracle lrwx- 1 root root 64 Dec 23 21:05 11 -&g

33、t; /u01/app/oracle/product/11.2.0/dbhome_1/dbs/hc_maa.datlr-x- 1 root root 64 Dec 23 21:05 13 -> /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/mesg/oraus.msblrwx- 1 root root 64 Dec 23 21:05 15 -> /u01/app/oracle/product/11.2.0/dbhome_1/dbs/hc_maa.datlrwx- 1 root root 64 Dec 23 21:05 16 ->

34、/u01/app/oracle/product/11.2.0/dbhome_1/dbs/lkMAAlrwx- 1 root root 64 Dec 23 21:05 17 -> /dev/oracleasm/iid/000000000000000Flrwx- 1 root root 64 Dec 23 21:05 256 -> /u01/app/oracle/oradata/luocs01.dbflrwx- 1 root root 64 Dec 23 21:05 257 -> /u01/app/oracle/oradata/ltb01.dbf (deleted)lr-x- 1

35、 root root 64 Dec 23 21:05 27 -> /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/mesg/oraus.msblrwx- 1 root root 64 Dec 23 21:05 5 -> /u01/app/oracle/product/11.2.0/dbhome_1/dbs/hc_maa.dat- 可以發(fā)現(xiàn)/u01/app/oracle/oradata/ltb01.dbf (deleted)已刪除標(biāo)記我從文件描述符中將文件拷貝到原位置：rootmaa3 # cp /proc/6578/fd/257 /u01

36、/app/oracle/oradata/ltb01.dbf -poraclemaa3 $ ls /u01/app/oracle/oradata/ltb01.dbf-rw-r- 1 oracle asmadmin 52436992 Dec 23 20:50 /u01/app/oracle/oradata/ltb01.dbf重啟數(shù)據(jù)庫(kù)，正常sysMAA> startup forceORACLE instance started.Total System Global Area 1252663296 bytesFixed Size 2227944 bytesVariable Size 8556

37、38296 bytesDatabase Buffers 385875968 bytesRedo Buffers 8921088 bytesDatabase mounted.Database opened.sysMAA> select checkpoint_change#, name from v$datafile where file#=12;CHECKPOINT_CHANGE# NAME- - 3654318 /u01/app/oracle/oradata/ltb01.dbf數(shù)據(jù)訪問(wèn)正常sysMAA> select * from l.luocs;DOMAIN-這里之所以不需要RE

38、COVER數(shù)據(jù)庫(kù)，是因?yàn)槲覀儾僮鞯膶?duì)象為只讀數(shù)據(jù)文件。如果是讀寫(xiě)狀態(tài)下的數(shù)據(jù)文件，將文件拷貝過(guò)來(lái)之后需要先offline datafile后recover datafile，然后再online datafile。另外，只讀數(shù)據(jù)文件刪除之后如果重啟數(shù)據(jù)庫(kù)，依然會(huì)報(bào)ORA-01110錯(cuò)誤，這個(gè)在場(chǎng)景2中說(shuō)明。場(chǎng)景2：控制文件無(wú)損，只讀數(shù)據(jù)文件丟失，數(shù)據(jù)庫(kù)無(wú)法OPEN刪除只讀數(shù)據(jù)文件以模擬丟失oraclemaa3 $ rm -rf /u01/app/oracle/oradata/ltb01.dbf數(shù)據(jù)庫(kù)啟動(dòng)時(shí)報(bào)錯(cuò)sysMAA> startup forceORACLE instance star

39、ted.Total System Global Area 1252663296 bytesFixed Size 2227944 bytesVariable Size 855638296 bytesDatabase Buffers 385875968 bytesRedo Buffers 8921088 bytesDatabase mounted.ORA-01157: cannot identify/lock data file 12 - see DBWR trace fileORA-01110: data file 12: '/u01/app/oracle/oradata/ltb01.d

40、bf'只讀數(shù)據(jù)文件恢復(fù)時(shí)我們不需要recover過(guò)程，數(shù)據(jù)庫(kù)啟動(dòng)時(shí)已經(jīng)到MOUNT狀態(tài)，通過(guò)RMAN還原該數(shù)據(jù)文件RMAN> restore tablespace ltb;Starting restore at 23-DEC-2012 18:36:54using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=22 device type=DISKchannel ORA_DISK_1: starting data

41、file backup set restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setchannel ORA_DISK_1: restoring datafile 00012 to /u01/app/oracle/oradata/ltb01.dbfchannel ORA_DISK_1: reading from backup piece /u01/recovery/MAA/backupset/2012_12_23/o1_mf_nnndf_TAG20121223T182931_8ffq8cbz_.b

42、kpchannel ORA_DISK_1: piece handle=/u01/recovery/MAA/backupset/2012_12_23/o1_mf_nnndf_TAG20121223T182931_8ffq8cbz_.bkp tag=TAG20121223T182931channel ORA_DISK_1: restored backup piece 1channel ORA_DISK_1: restore complete, elapsed time: 00:00:01Finished restore at 23-DEC-2012 18:36:57打開(kāi)數(shù)據(jù)文件RMAN> a

43、lter database open;database openedsysMAA> select * from luocs;DOMAIN-場(chǎng)景3：控制文件無(wú)損，只讀數(shù)據(jù)文件頭部損壞我使用BBED工具破壞頭部信息oraclemaa3 $ cat bbed.par 12 /u01/app/oracle/oradata/ltb01.dbforaclemaa3 $ cd $ORACLE_HOME/rdbms/liboraclemaa3 lib$ bbed listfile=/home/oracle/bbed.par blocksize=8192 mode=editPassword: BBED:

44、Release 2.0.0.0.0 - Limited Production on Sun Dec 23 21:42:22 2012Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.* ! For Oracle Internal Use only ! *BBED> info File# Name Size(blks) - - - 12 /u01/app/oracle/oradata/ltb01.dbf 0BBED> m /c Warning: contents of previou

45、s BIFILE will be lost. Proceed? (Y/N) Y File: /u01/app/oracle/oradata/ltb01.dbf (12) Block: 1 Offsets: 0 to 511 Dba:0x03000001- 7777772e 6c756f63 732e636f 6d000104 ea850000 00000000 0000200b b90df827 4d414100 00000000 fd140000 00190000 00200000 0c000300 00000000 00000000 54414732 30313231 32323354 3

46、2313234 33320000 00000000 00000000 00000000 00000000 ba163800 00000000 470dda2f 791c352f 01000000 00000000 00000000 00000000 00000000 00000000 03000000 00000000 02000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000

47、0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 07000000 03004c54 4200000

48、0 00000000 00000000 00000000 00000000 00000000 00000000 0c000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0

49、0000000 00000000 f5173800 00000000 780dda2f 01000020 5e000000 83010000 1000a600 <32 bytes per line>BBED> sum applyCheck value for File 12, Block 1:current = 0x2a9e, required = 0x2a9eBBED> verifyDBVERIFY - Verification startingFILE = /u01/app/oracle/oradata/ltb01.dbfBLOCK = 1Block 1 is co

50、rruptCorrupt block relative dba: 0x63400001 (file 0, block 1)Bad header found during verificationData in bad block: type: 119 format: 7 rdba: 0x636f756c last change scn: 0x006d.6f632e73 seq: 0x1 flg: 0x04 spare1: 0x77 spare2: 0x2e spare3: 0x0 consistency value in tail: 0x00000b01 check value in bloc

51、k header: 0x2a9e computed block checksum: 0x0DBVERIFY - Verification completeTotal Blocks Examined : 1Total Blocks Processed (Data) : 0Total Blocks Failing (Data) : 0Total Blocks Processed (Index): 0Total Blocks Failing (Index): 0Total Blocks Empty : 0Total Blocks Marked Corrupt : 1Total Blocks Influx : 0Message 531 not found; product=RDBMS; facility=BBED訪問(wèn)v$datafile里查看檢查點(diǎn)sysMAA> select checkpoint_change#