1.关于heartbeat和checkpoint
在这次的删除过程中我没有执行commit,而是直接abort数据库。整个删除过程执行了近6分钟,控制文件的心跳每三秒进行一次,心跳是把low cache rba记录到了控制文件中,而没有真正的把全部的脏数据写入到磁盘( 只有发生了checkpoint时候,才会把相关的脏数据写入到磁盘,而这里的控制文件的heartbeat和checkpoint是两回事,checkpoint一般是在切换日志,数据文件正常离线,执行begin backup命令时发生,昨晚晚上后面的一个困惑就是上面的英文描述,让我把这两者搞混淆了)
2.三种rba解释
low rba :在buffer cache中的数据块第一次数据改变所对应的RAB。
high rba :在buffer cache中的数据块最近一次数据改变时所对应的RAB。
on-disk rba:是 lgwr 写日志文件的最末位置的地址。
3.实例恢复过程解释
实例恢复的时候,是从控制文件heartbeat记录的low rba开始读redo log数据(会多读取一点,因为heartbeat是每三秒执行一次,假设在2.9秒的时候,数据库异常down了,控制文件中记录的还是2.9秒前的low rba,这个时候,从该点开始读取redo),恢复到on-disk rba,而不是high rba(high rba一般情况下会大于on-disk rba,但是因为high rba比on-disk rba多的部分记录在redo log buffer中,在实例恢复的时候,因为其未被记录到redo log file中,所以不能被恢复,其实也没有必要恢复,因为该数据肯定是没有commit或者rollback)
具体内容和实验请见:RBA和实例恢复关系
Category Archives: Oracle备份恢复
ORA-600 kcratr_nab_less_than_odr故障解决
朋友的数据库服务器出现ORA-00600[kcratr_nab_less_than_odr],不能open数据库
1.open数据库报ORA-00600[kcratr_nab_less_than_odr]
SQL> ALTER DATABASE OPEN; ALTER DATABASE OPEN * 第 1 行出现错误: ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], []
2.查看alert日志
Wed Jan 11 13:56:16 2012 ALTER DATABASE OPEN Beginning crash recovery of 1 threads parallel recovery started with 2 processes Started redo scan Completed redo scan read 54591 KB redo, 0 data blocks need recovery Errors in file d:\dbdms\diag\rdbms\dbdms\dbdms\trace\dbdms_ora_3108.trc (incident=818557): ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], [] Incident details in: d:\dbdms\diag\rdbms\dbdms\dbdms\incident\incdir_818557\dbdms_ora_3936_i818557.trc Aborting crash recovery due to error 600 Errors in file d:\dbdms\diag\rdbms\dbdms\dbdms\trace\dbdms_ora_3108.trc: ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], [] Errors in file d:\dbdms\diag\rdbms\dbdms\dbdms\trace\dbdms_ora_3108.trc: ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], [] ORA-600 signalled during: ALTER DATABASE OPEN... Trace dumping is performing id=[cdmp_20120110214555]
3.查看trace文件
Trace file d:\dbdms\diag\rdbms\dbdms\dbdms\trace\dbdms_ora_3108.trc Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Windows NT Version V6.1 Service Pack 1 CPU : 2 - type 8664, 2 Physical Cores Process Affinity : 0x0x0000000000000000 Memory (Avail/Total): Ph:2250M/4060M, Ph+PgF:5868M/8119M Instance name: dbdms Redo thread mounted by this instance: 1 Oracle process number: 17 Windows thread id: 3108, image: ORACLE.EXE (SHAD) ………………………… WARNING! Crash recovery of thread 1 seq 99189 is ending at redo block 43531 but should not have ended before redo block 43569 Incident 826550 created, dump file: d:\dbdms\diag\rdbms\dbdms\dbdms\incident\incdir_826550\dbdms_ora_3108_i826550.trc ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], [] ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], [] ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], []
通过alert和trace中的内容可以知道,数据库需要恢复到rba到43569,但是因为某种原因实例恢复的时候,只能利用1 thread 99189 seq#,恢复rba到43531。从而导致数据库无法正常open
This Problem is caused by Storage Problem of the Database Files. The Subsystem (eg. SAN) crashed while the Database was open. The Database then crashed since the Database Files were not accessible anymore. This caused a lost Write into the Online RedoLogs and so Instance Recovery is not possible and raising the ORA-600.
4.解决方法
SQL> SELECT STATUS FROM V$INSTANCE; STATUS ------------ MOUNTED --尝试直接recover database SQL> RECOVER DATABASE ; ORA-00283: 恢复会话因错误而取消 ORA-00264: 不要求恢复 --提示不用恢复 --再打开数据库,还是kcratr_nab_less_than_odr错误警告 SQL> ALTER DATABASE OPEN; ALTER DATABASE OPEN * 第 1 行出现错误: ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], [] --尝试不完全恢复 SQL> RECOVER DATABASE UNTIL CANCEL; ORA-10879: error signaled in parallel recovery slave ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误 ORA-01152: 文件 1 没有从过旧的备份中还原 ORA-01110: 数据文件 1: 'D:\DBDMS\DATA\SYSTEM01.DBF' --重建控制文件 SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'D:/1.TXT'; 数据库已更改。 SQL> SHUTDOWN IMMEDIATE; ORA-01109: 数据库未打开 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> STARTUP NOMOUNT; ORACLE 例程已经启动。 Total System Global Area 417546240 bytes Fixed Size 2176328 bytes Variable Size 268438200 bytes Database Buffers 138412032 bytes Redo Buffers 8519680 bytes SQL> CREATE CONTROLFILE REUSE DATABASE "DBDMS" NORESETLOGS NOARCHIVELOG 2 MAXLOGFILES 16 3 MAXLOGMEMBERS 3 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 18688 7 LOGFILE 8 GROUP 1 'D:\DBDMS\LOG\REDO01.LOG' SIZE 50M BLOCKSIZE 512, 9 GROUP 2 'D:\DBDMS\LOG\REDO02.LOG' SIZE 50M BLOCKSIZE 512, 10 GROUP 3 'D:\DBDMS\LOG\REDO03.LOG' SIZE 50M BLOCKSIZE 512 11 DATAFILE 12 'D:\DBDMS\DATA\SYSTEM01.DBF', 13 'D:\DBDMS\DATA\SYSAUX01.DBF', 14 'D:\DBDMS\DATA\RBSG01.DBF', 15 'D:\DBDMS\DATA\DATA01.DBF', 16 'D:\DBDMS\DATA\INDX01.DBF', 17 'D:\DBDMS\DATA\DATA02.DBF', 18 'D:\DBDMS\DATA\DATA03.DBF', 19 'D:\DBDMS\DATA\DATA04.DBF', 20 'D:\DBDMS\DATA\INDX02.DBF', 21 'D:\DBDMS\DATA\SYSTEM02.DBF' 22 CHARACTER SET ZHS16GBK 23 ; 控制文件已创建。 --继续尝试恢复 SQL> RECOVER DATABASE ; 完成介质恢复。 SQL> ALTER DATABASE OPEN; 数据库已更改。 --open成功
在这次恢复中,主要就是重建控制文件,然后直接恢复成功,如果redo有损坏,那么可能需要使用不完全恢复,然后使用resetlogs打开数据库
恢复被rm意外删除数据文件
一.模拟数据文件删除
[oracle@node1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Sat Dec 31 22:00:52 2011
Copyright (c) 1982, 2011, Oracle. All rights reserved.
--数据库版本
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
--所有数据文件
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/opt/oracle/oradata/ora11g/system01.dbf
/opt/oracle/oradata/ora11g/sysaux01.dbf
/opt/oracle/oradata/ora11g/undotbs01.dbf
/opt/oracle/oradata/ora11g/users01.dbf
/opt/oracle/oradata/ora11g/example01.dbf
--删除example01.dbf数据文件
SQL> !rm /opt/oracle/oradata/ora11g/example01.dbf
SQL> !ls -l /opt/oracle/oradata/ora11g/example01.dbf
ls: /opt/oracle/oradata/ora11g/example01.dbf: 没有那个文件或目录
--因为数据文件被删除,创建表失败
SQL> create table t_xifenfei tablespace example
2 as select * from dba_tables;
as select * from dba_tables
*
ERROR at line 2:
ORA-01116: error in opening database file 5
ORA-01110: data file 5: '/opt/oracle/oradata/ora11g/example01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
二.找回数据文件
--查找dbw进程spid [oracle@node1 ~]$ ps -ef|grep dbw|grep -v grep oracle 18387 1 0 Dec22 ? 00:00:12 ora_dbw0_ora11g --查看该进程所有文件句柄 [oracle@node1 ~]$ ll /proc/18387/fd 总计 0 lr-x------ 1 oracle oinstall 64 12-31 22:03 0 -> /dev/null l-wx------ 1 oracle oinstall 64 12-31 22:03 1 -> /dev/null lr-x------ 1 oracle oinstall 64 12-31 22:03 10 -> /dev/zero lr-x------ 1 oracle oinstall 64 12-31 22:03 11 -> /dev/zero lr-x------ 1 oracle oinstall 64 12-31 22:03 12 -> /opt/oracle/product/11.2.0/db_1/rdbms/mesg/orazhs.msb lrwx------ 1 oracle oinstall 64 12-31 22:03 13 -> /opt/oracle/product/11.2.0/db_1/dbs/hc_ora11g.dat lr-x------ 1 oracle oinstall 64 12-31 22:03 14 -> /proc/18387/fd lr-x------ 1 oracle oinstall 64 12-31 22:03 15 -> /dev/zero lr-x------ 1 oracle oinstall 64 12-31 22:03 16 -> /opt/oracle/product/11.2.0/db_1/rdbms/mesg/oraus.msb lrwx------ 1 oracle oinstall 64 12-31 22:03 17 -> /opt/oracle/product/11.2.0/db_1/dbs/hc_ora11g.dat lrwx------ 1 oracle oinstall 64 12-31 22:03 18 -> /opt/oracle/product/11.2.0/db_1/dbs/lkORA11G lr-x------ 1 oracle oinstall 64 12-31 22:03 19 -> /opt/oracle/product/11.2.0/db_1/rdbms/mesg/orazhs.msb l-wx------ 1 oracle oinstall 64 12-31 22:03 2 -> /dev/null lr-x------ 1 oracle oinstall 64 12-31 22:03 20 -> /opt/oracle/product/11.2.0/db_1/rdbms/mesg/oraus.msb lrwx------ 1 oracle oinstall 64 12-31 22:03 21 -> socket:[441562] lrwx------ 1 oracle oinstall 64 12-31 22:03 256 -> /opt/oracle/oradata/ora11g/control01.ctl lrwx------ 1 oracle oinstall 64 12-31 22:03 257 -> /opt/oracle/oradata/ora11g/system01.dbf lrwx------ 1 oracle oinstall 64 12-31 22:03 258 -> /opt/oracle/oradata/ora11g/sysaux01.dbf lrwx------ 1 oracle oinstall 64 12-31 22:03 259 -> /opt/oracle/oradata/ora11g/undotbs01.dbf lrwx------ 1 oracle oinstall 64 12-31 22:03 260 -> /opt/oracle/oradata/ora11g/users01.dbf lrwx------ 1 oracle oinstall 64 12-31 22:03 261 -> /opt/oracle/oradata/ora11g/example01.dbf (deleted) lrwx------ 1 oracle oinstall 64 12-31 22:03 262 -> /opt/oracle/oradata/ora11g/temp01.dbf lr-x------ 1 oracle oinstall 64 12-31 22:03 3 -> /dev/null lr-x------ 1 oracle oinstall 64 12-31 22:03 4 -> /dev/null lrwx------ 1 oracle oinstall 64 12-31 22:03 5 -> /opt/oracle/product/11.2.0/db_1/dbs/hc_ora11g.dat lr-x------ 1 oracle oinstall 64 12-31 22:03 6 -> /dev/null lr-x------ 1 oracle oinstall 64 12-31 22:03 7 -> /dev/null lr-x------ 1 oracle oinstall 64 12-31 22:03 8 -> /dev/null lr-x------ 1 oracle oinstall 64 12-31 22:03 9 -> /dev/null --通过句柄恢复数据文件[被删除数据文件会被标示(deleted)] [oracle@node1 ~]$ cp /proc/18387/fd/261 /opt/oracle/oradata/ora11g/example01.dbf --确认该数据文件已经恢复成功 [oracle@node1 ~]$ ll /opt/oracle/oradata/ora11g/example01.dbf -rw-r----- 1 oracle oinstall 362422272 12-31 22:05 /opt/oracle/oradata/ora11g/example01.dbf
三.数据文件online
SQL> alter database datafile 5 offline; Database altered. SQL> recover datafile 5; Media recovery complete. SQL> alter database datafile 5 online; Database altered. SQL> create table t_xifenfei tablespace example 2 as select * from dba_tables; Table created.
四.补充说明
在意外使用os命令删除掉数据文件时,千万不要慌张重启数据库或者操作系统,可以通过dbwn进程相关句柄找回数据文件
记录一次oer 8102.2处理
1.alert日志
Tue Dec 20 22:09:45 2011 Errors in file /opt/app/oracle/admin/BAS/bdump/bas_m000_27442.trc: Wed Dec 21 22:10:45 2011 Errors in file /opt/app/oracle/admin/BAS/bdump/bas_m000_32761.trc: Thu Dec 22 22:11:46 2011 Errors in file /opt/app/oracle/admin/BAS/bdump/bas_m000_5935.trc: Fri Dec 23 22:12:47 2011 Errors in file /opt/app/oracle/admin/BAS/bdump/bas_m000_11382.trc:
Mnnn performs manageability tasks dispatched to them by MMON. Tasks performed include taking Automatic Workload Repository snapshots and Automatic Database Diagnostic Monitor analysis.
从这个时间点来看,应该是数据库启动GATHER_STATS_JOB收集统计信息时发现这个错误。
2.bas_m000_11382.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options ORACLE_HOME = /opt/app/oracle/product/10.2.0/db_1 System name: Linux Node name: bas Release: 2.6.9-78.ELsmp Version: #1 SMP Wed Jul 9 15:46:26 EDT 2008 Machine: x86_64 Instance name: BAS Redo thread mounted by this instance: 1 Oracle process number: 24 Unix process pid: 11382, image: oracle@bas (m000) *** ACTION NAME:(Auto-Purge Slave Action) 2011-12-23 22:12:47.074 *** MODULE NAME:(MMON_SLAVE) 2011-12-23 22:12:47.074 *** SERVICE NAME:(SYS$BACKGROUND) 2011-12-23 22:12:47.074 *** SESSION ID:(5465.2033) 2011-12-23 22:12:47.074 oer 8102.2 - obj# 4152, rdba: 0x00401f7c(afn 1, blk# 8060) kdk key 8102.2: ncol: 2, len: 10 key: (10): 02 c1 0a 06 00 c0 04 dc 00 00 mask: (4096): 09 00 00 00 00 fb d1 c0 00 00 00 00 00 70 f8 fe bf 7f 00 00 00 cd 7d 5d 01
oer 8102.<code> - obj# <object id>, rdba: <rdba value>(afn <file#>, blk# <block#>) kdk key 8102.2: ncol: <number of columns in the key including the rowid>, len: <key length> key: (<length>):<hexadecimal value> obj#: object_id for the affected index in dba_objects. rdba: relative data block address where the key is supposed to be stored in the index. afn: absolute file number where the affected index block is stored. (file_id in dba_data_files, file# in v$datafile). blk#: Index block number where the key is supposed to be stored.
出现oer 8102.2的错误,有两种可能:1.坏块,2.表和索引数据不一致
3.找出相关对象
SQL> col object_name for a30 SQL> col owner for a10 SQL> select object_name,owner,object_type 2 from dba_objects where object_id=4152; OBJECT_NAME OWNER OBJECT_TYPE ------------------------------ ---------- ------------------- WRI$_SEGADV_OBJLIST_IDX_TS SYS INDEX SQL> select OWNER,TABLE_NAME from dba_indexes 2 where index_name='WRI$_SEGADV_OBJLIST_IDX_TS'; OWNER TABLE_NAME ---------- ------------------------------ SYS WRI$_SEGADV_OBJLIST SQL> ANALYZE TABLE sys.WRI$_SEGADV_OBJLIST VALIDATE STRUCTURE CASCADE; ANALYZE TABLE sys.WRI$_SEGADV_OBJLIST VALIDATE STRUCTURE CASCADE * ERROR at line 1: ORA-01499: table/index cross reference failure - see trace file
4.分析坏块(逻辑/物理)
SQL> ANALYZE INDEX WRI$_SEGADV_OBJLIST_IDX_TS VALIDATE STRUCTURE; Index analyzed. SQL> ANALYZE TABLE WRI$_SEGADV_OBJLIST VALIDATE STRUCTURE; Table analyzed. [oracle@bas bdump]$ dbv file=/opt/app/oracle/oradata/BAS/system01.dbf DBVERIFY: Release 10.2.0.1.0 - Production on Sat Dec 24 21:14:38 2011 Copyright (c) 1982, 2005, Oracle. All rights reserved. DBVERIFY - Verification starting : FILE = /opt/app/oracle/oradata/BAS/system01.dbf DBVERIFY - Verification complete Total Pages Examined : 552960 Total Pages Processed (Data) : 360156 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 167596 Total Pages Failing (Index): 0 Total Pages Processed (Other): 1961 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 23247 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Highest block SCN : 2890198330 (2750.2890198330)
检测证明,对象以及对象所属的数据文件,无坏块现象
5.分析表和index不一致
--找出index对应列
SQL> SELECT table_name , column_name from dba_ind_columns
2 WHERE index_name='WRI$_SEGADV_OBJLIST_IDX_TS' order by table_name;
TABLE_NAME COLUMN_NAME
------------------------------ --------------------
WRI$_SEGADV_OBJLIST TS_ID
--确定对应列是否允许为null
SQL> desc WRI$_SEGADV_OBJLIST
Name Null? Type
----------------------------------------- -------- ----------------------------
AUTO_TASKID NUMBER
TS_ID NUMBER
OBJN NUMBER
OBJD NUMBER
STATUS VARCHAR2(40)
TASK_ID NUMBER
REASON VARCHAR2(40)
REASON_VALUE NUMBER
CREATION_TIME TIMESTAMP(6)
PROC_TASKID NUMBER
END_TIME TIMESTAMP(6)
SEGMENT_OWNER VARCHAR2(30)
SEGMENT_NAME VARCHAR2(81)
PARTITION_NAME VARCHAR2(30)
SEGMENT_TYPE VARCHAR2(18)
TABLESPACE_NAME VARCHAR2(30)
--确认在表中对应列是否有空值
SQL> SELECT /*+ FULL(t1) */ count(TS_ID)
2 FROM WRI$_SEGADV_OBJLIST t1
3 WHERE t1.TS_ID IS NULL;
COUNT(TS_ID)
------------
0
--表比index多数据
SQL> SELECT /*+ FULL(t1) */ TS_ID
2 FROM WRI$_SEGADV_OBJLIST t1
3 MINUS
4 SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID
5 FROM WRI$_SEGADV_OBJLIST t where ts_id is not null;
no rows selected
--index中数据条数
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ count(TS_ID)
2 FROM WRI$_SEGADV_OBJLIST t
3 where ts_id is not null;
COUNT(TS_ID)
------------
901
--表中数据条数
SQL> SELECT /*+ FULL(t1) */ count(TS_ID)
2 FROM WRI$_SEGADV_OBJLIST t1 ;
COUNT(TS_ID)
------------
937
--index中不同值数量
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */
2 COUNT(DISTINCT TS_ID)
3 FROM WRI$_SEGADV_OBJLIST t WHERE TS_ID IS NOT NULL;
COUNT(DISTINCTTS_ID)
--------------------
5
--表中不同值数量
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID
2 FROM WRI$_SEGADV_OBJLIST t WHERE ts_id IS NOT NULL
3 MINUS
4 SELECT /*+ FULL(t1) */ TS_ID
5 FROM WRI$_SEGADV_OBJLIST t1 ;
TS_ID
----------
4
--对比可以知道index中的唯一值比表中,这个也就解释了,为什么表中总条数多,
--但是他们两做减法的时候,记录为空
--索引表比表多数据
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID
2 FROM WRI$_SEGADV_OBJLIST t WHERE ts_id IS NOT NULL
3 MINUS
4 SELECT /*+ FULL(t1) */ TS_ID
5 FROM WRI$_SEGADV_OBJLIST t1 ;
TS_ID
----------
4
上面的检测证明:1.表中有索引中无的数据,2.索引中有表中不存在数据
6.解决问题
SQL> alter index WRI$_SEGADV_OBJLIST_IDX_TS rebuild online;
Index altered.
--测试index中总条数
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ count(TS_ID)
2 FROM WRI$_SEGADV_OBJLIST t
3 where ts_id is not null;
COUNT(TS_ID)
------------
937
--无多余index项(以前唯一值为4的记录已经不存在)
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID
2 FROM WRI$_SEGADV_OBJLIST t WHERE ts_id IS NOT NULL
3 MINUS
4 SELECT /*+ FULL(t1) */ TS_ID
5 FROM WRI$_SEGADV_OBJLIST t1 ;
no rows selected
--通过上述测试,证明表和index不一致问题解决
通过ROWID找回坏块数据
一.准备环境
C:\Users\XIFENFEI>sqlplus chf/xifenfei
SQL*Plus: Release 11.2.0.1.0 Production on 星期五 12月 23 10:49:52 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
SQL> create tablespace t_xff datafile 'E:\ORACLE\ORADATA\XFF\t_xff01.dbf'
2 size 10m autoextend on next 10m maxsize 1g;
表空间已创建。
SQL> create table t_xifenfei tablespace t_xff
2 as
3 select * from dba_objects;
表已创建。
SQL> select count(*) from t_xifenfei;
COUNT(*)
----------
73286
二.发现坏块
使用ULtraEdit破坏数据(关闭数据库执行)
SQL> select count(*) from t_xifenfei;
select count(*) from t_xifenfei
*
第 1 行出现错误:
ORA-01578: ORACLE 数据块损坏 (文件号 13, 块号 373)
ORA-01110: 数据文件 13: 'E:\ORACLE\ORADATA\XFF\T_XFF01.DBF'
三.查询坏块相关信息
The "LOW_RID" is the lowest rowid INSIDE the corrupt block:
SELECT dbms_rowid.rowid_create(1,<DATA_OBJECT_ID>,<RFN>,<BL>,0) LOW_RID
from DUAL;
The "HI_RID" is the first rowid AFTER the corrupt block:
SELECT dbms_rowid.rowid_create(1,<DATA_OBJECT_ID>,<RFN>,<BL>+1,0) HI_RID
from DUAL;
SQL> col tablespace_name for a30
SQL> col segment_type for a5
SQL> col owner for a10
SQL> col segment_name for a20
SQL> SELECT tablespace_name, segment_type, owner, segment_name
2 FROM dba_extents
3 WHERE file_id =13
4 AND 373 between block_id AND block_id + blocks - 1 ;
TABLESPACE_NAME SEGME OWNER SEGMENT_NAME
------------------------------ ----- ---------- --------------------
T_XFF TABLE CHF T_XIFENFEI
SQL> SELECT data_object_id
2 FROM dba_objects
3 WHERE object_name = 'T_XIFENFEI' and owner='CHF';
DATA_OBJECT_ID
--------------
77759
--坏块的最小rowid
SQL> select dbms_rowid.rowid_create(1, 77759,13,373,0) from dual;
DBMS_ROWID.ROWID_C
------------------
AAAS+/AANAAAAF1AAA
坏块的最大rowid(block+1得到)
SQL> select dbms_rowid.rowid_create(1, 77759,13,374,0) from dual;
DBMS_ROWID.ROWID_C
------------------
AAAS+/AANAAAAF2AAA
四.根据rowid找回数据
SQL> SELECT /*+ ROWID(A) */ COUNT(*) FROM T_XIFENFEI A
2 WHERE ROWID>='AAAS+/AANAAAAF2AAA';
COUNT(*)
----------
55858
SQL> SELECT /*+ ROWID(A) */ COUNT(*) FROM T_XIFENFEI A
2 WHERE ROWID<'AAAS+/AANAAAAF1AAA';
COUNT(*)
----------
17358
SQL> SELECT 77759-55858-17358 from dual;
77759-55858-17358
-----------------
4543
SQL> CREATE TABLE T_XIFENFEI_BAK TABLESPACE T_XFF
2 AS
3 SELECT /*+ ROWID(A) */ * FROM T_XIFENFEI A
4 WHERE ROWID>='AAAS+/AANAAAAF2AAA';
表已创建。
SQL> INSERT INTO T_XIFENFEI_BAK
2 SELECT /*+ ROWID(A) */ * FROM T_XIFENFEI A
3 WHERE ROWID<'AAAS+/AANAAAAF1AAA';
已创建17358行。
SQL> COMMIT;
提交完成。
SQL> SELECT COUNT(*) FROM T_XIFENFEI_BAK;
COUNT(*)
----------
73216
五.和dbms_repair解决坏块对比
SQL> CONN / AS SYSDBA
已连接。
SQL> exec dbms_repair.skip_corrupt_blocks('CHF','T_XIFENFEI');
PL/SQL 过程已成功完成。
SQL> select skip_corrupt from dba_tables where table_name='T_XIFENFEI';
SKIP_COR
--------
ENABLED
SQL> select count(*) from chf.t_xifenfei;
COUNT(*)
----------
73216
通过跳过坏块和rowid功能对比可以看出,两者丢失的数据是相同的,如果有index,同样利用rowid结合index,可能会找回部分数据。当然dbms_repair也提供了类此的功能。两种方法的使用看个人的爱好与习惯。
