Oracle提供了DBMS_REPAIR包用来发现、标识并修改数据文件中的坏块。
任何工具都不是万能的,使用这个包的同时会带来数据丢失、表和索引返回数据不一致,完整性约束破坏等其他问题。因此当出现错误时,应当首先从物理备份或逻辑备份恢复,使用dbms_repair只是在没有备份的情况下使用的一种手段,这种方式一般都会造成数据的丢失。
dbms_repair包的工作原理比较简单,是将检查到的坏块标注出来,使随后的dml操作跳过该块,同时,dbms_repair包还提供了用于保存索引中包含的标注为坏块中的键值,以及修复freelist和segment bitmap的过程。
有一点需要注意,dbms_repair包没有进行授权,只有sys用户可以执行。
下面通过一个例子来简要介绍一下dbms_repair包的使用。
一、构造测试环境
首先建立一个测试用表空间,由于需要用UtralEdit打开数据文件修改部分内容来模拟错误,因此数据文件要建的小一些。
SQL> CREATE TABLESPACE TEST DATAFILE 'E:ORACLEORADATATESTTEST.DBF' SIZE 1M
2 EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT MANUAL;
表空间已创建。
SQL> CREATE TABLE TEST (ID NUMBER, NAME VARCHAR2(30)) TABLESPACE TEST;
表已创建。
SQL> INSERT INTO TEST SELECT ROWNUM, OBJECT_NAME FROM DBA_OBJECTS;
已创建6232行。
SQL> COMMIT;
提交完成。
SQL> CREATE INDEX IND_TEST_ID ON TEST (ID);
索引已创建。
SQL> CREATE INDEX IND_TEST_NAME ON TEST (NAME);
索引已创建。
为了确保oracle已经把刚才插入的数据写到数据文件中,现在重起数据库。
SQL> CONN /@TEST AS SYSDBA
已连接。
SQL> SHUTDOWN
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> STARTUP
ORACLE 例程已经启动。
Total System Global Area 89201304 bytes
Fixed Size 453272 bytes
Variable Size 62914560 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
二、模拟错误的产生
用UtralEdit打开数据文件,只要修改了数据文件中任意的一个位置,都会造成数据文件错误。但我们测试需要将错误发生位置定位在TEST表中。
SQL> CONN YANGTK/YANGTK@TEST
已连接。
SQL> SELECT SUBSTR(ROWID, 10, 6), ID, NAME FROM TEST WHERE ID = 123;
SUBSTR(ROWID ID NAME
------------ ---------- ------------------------------
AAAAAG 123 ALL_REPCONFLICT
如何在数据文件中找到TEST表的数据呢?可以通过ROWID来定位的记录在数据文件中的位置。任意选择一条记录(如上面ID = 123),取得它的ROWID,我们知道,ROWID中10~15位表示这条记录所在的BLOCK是数据文件的第几个BLOCK。
A表示0,B为1,G表示6。这说明这条记录在数据文件的第六个block中。
SQL> SHOW PARAMETER DB_BLOCK_SIZE
NAME TYPE VALUE
------------------------------------ ----------- ---------------
db_block_size integer 16384
BLOCK的大小是16k。
SQL> SELECT TO_CHAR(6*16384, 'XXXXXX') FROM DUAL;
TO_CHAR
-------
18000
SQL> SELECT TO_CHAR(7*16384, 'XXXXXX') FROM DUAL;
TO_CHAR
-------
1C000
用UtralEdit打开数据文件,将文件定位18000h处(以二进制方式打开,如果没有用二进制打开,可以使用CTRL+H快捷键切换)。根据上面的计算,可以得出,我们要找到记录在18000h和1C000h之间。
Number类型123在数据库存放方式为03C20218,03表示占有三位,C2表示最高位是百位,02表示最高位上是1,18表示低位上是23。
具体的数值可以通过下面的查询得到:
SQL> SELECT DUMP(123) FROM DUAL;
DUMP(123)
---------------------
Typ=2 Len=3: 194,2,24
SQL> SELECT TO_CHAR(194, 'XX'), TO_CHAR(2, 'XX'), TO_CHAR(24, 'XX') FROM DUAL;
TO_ TO_ TO_
--- --- ---
C2 2 18
关于具体的NUMBER类型在数据库中是如何存储的,有兴趣的可以参阅另一篇文章。
下面使用UtralEdit的搜索功能,查找到03C20218,将其修改为03C20216,并保存。
上面是通过oracle的ROWID在文件中定位,这相对来说要复杂一些。下面可以使用UtralEdit的功能达到相同的目的。
根据上面的查询可以得到,ID = 123时,NAME的值是ALL_REPCONFLICT。
下面用UtralEdit打开文件,使用CTRL+H方式切换到文本格式,直接查找ALL_REPCONFLICT字符串。找到后,CTRL+H切换回二进制格式。向前跳过一个长度字节(本例中为0F),就可以看到123的值03C20218,进行修改后,保存并退出。
SQL> SELECT * FROM TEST WHERE ID = 123;
ID NAME
---------- ------------------------------
123 ALL_REPCONFLICT
这时候查询仍然可以得到正确结果,因为oracle使用了db_cache中的结果。为了让oracle“看”到修改,必须重起数据库。
SQL> CONN /@TEST AS SYSDBA
已连接。
SQL> SHUTDOWN
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> STARTUP
ORACLE 例程已经启动。
Total System Global Area 89201304 bytes
Fixed Size 453272 bytes
Variable Size 62914560 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL> CONN YANGTK/YANGTK@TEST
已连接。
SQL> SELECT * FROM TEST WHERE ID = 123;
SELECT * FROM TEST WHERE ID = 123
*
ERROR 位于第 1 行:
ORA-01578: ORACLE 数据块损坏(文件号7,块号6)
ORA-01110: 数据文件 7: 'E:ORACLEORADATATESTTEST.DBF'
已经模拟成功了坏块,开始进入正题部分,使用DBMS_REPAIR表来处理坏块。
三、使用DBMS_REPAIR包处理坏块。
1.建立REPAIR_TABLE和ORPHAN_KEY_TABLE表
SQL> BEGIN
2 DBMS_REPAIR.ADMIN_TABLES (
3 TABLE_NAME => 'REPAIR_TABLE',
4 TABLE_TYPE => dbms_repair.repair_table,
5 ACTION => dbms_repair.create_action,
6 TABLESPACE => 'YANGTK');
7 END;
8 /
PL/SQL 过程已成功完成。
SQL> BEGIN
2 DBMS_REPAIR.ADMIN_TABLES (
3 TABLE_NAME => 'ORPHAN_KEY_TABLE',
4 TABLE_TYPE => dbms_repair.orphan_table,
5 ACTION => dbms_repair.create_action,
6 TABLESPACE => 'YANGTK');
7 END;
8 /
PL/SQL 过程已成功完成。
REPAIR_TABLE用来记录错误检查结果,ORPHAN_KEY_TABLE用来记录表坏块中记录在索引中对应键值。
这两个表的删除可以通过下列存储过程完成
BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'REPAIR_TABLE',
TABLE_TYPE => dbms_repair.repair_table,
ACTION => dbms_repair.drop_action);
END;
/
BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'ORPHAN_KEY_TABLE',
TABLE_TYPE => dbms_repair.orphan_table,
ACTION => dbms_repair.drop_action);
END;
/
2.使用CHECK_OBJECT过程检测坏块。
SQL> SET SERVEROUTPUT ON
SQL> DECLARE
2 num_corrupt INT;
3 BEGIN
4 num_corrupt := 0;
5 DBMS_REPAIR.CHECK_OBJECT (
6 SCHEMA_NAME => 'YANGTK',
7 OBJECT_NAME => 'TEST',
8 REPAIR_TABLE_NAME => 'REPAIR_TABLE',
9 CORRUPT_COUNT => num_corrupt);
10 DBMS_OUTPUT.PUT_LINE('number corrupt: ' TO_CHAR (num_corrupt));
11 END;
12 /
number corrupt: 1
PL/SQL 过程已成功完成。
SQL> SELECT OBJECT_NAME, BLOCK_ID, CORRUPT_TYPE, MARKED_CORRUPT,
2 CORRUPT_DESCRIPTION, REPAIR_DESCRIPTION
3 FROM REPAIR_TABLE;
OBJECT_NAM BLOCK_ID CORRUPT_TYPE MARKED_COR CORRUPT_DE REPAIR_DESCRIPTION
---------- ---------- ------------ ---------- ---------- ----------------------
TEST 6 6148 TRUE mark block software corrupt
这里和oracle文档上面有点出入,根据oracle文档上面介绍MARKED_CORRUPT列的值是FALSE,只有执行了FIX_CORRUPT_BLOCKS过程才会使MARKED_CORRUPT列的值变为TRUE。怀疑oracle在CHECK的同时,自动进行FIX_CORRUPT_BLOCKS的操作。
SQL> DECLARE
2 num_fix INT;
3 BEGIN
4 num_fix := 0;
5 DBMS_REPAIR.FIX_CORRUPT_BLOCKS (
6 SCHEMA_NAME => 'YANGTK',
7 OBJECT_NAME=> 'TEST',
8 OBJECT_TYPE => dbms_repair.table_object,
9 REPAIR_TABLE_NAME => 'REPAIR_TABLE',
10 FIX_COUNT=> num_fix);
11 DBMS_OUTPUT.PUT_LINE('num fix: ' TO_CHAR(num_fix));
12 END;
13 /
num fix: 0
PL/SQL 过程已成功完成。
果然,执行FIX_CORRUPT_BLOCKS过程发现FIX了0个坏块,这一步操作可以省略不用执行。
3.使用DUMP_ORPHAN_KEYS过程来保存坏块中的索引键值。
这时还存在着一个潜在的问题。表出现了坏块,但是索引没有损坏,通过表扫描回出现错误,但是通过索引扫描,仍然可以返回结果,这会造成数据的不一致性。
SQL> SELECT * FROM YANGTK.TEST WHERE ID = 123;
SELECT * FROM YANGTK.TEST WHERE ID = 123
*
ERROR 位于第 1 行:
ORA-01578: ORACLE 数据块损坏(文件号7,块号6)
ORA-01110: 数据文件 7: 'E:ORACLEORADATATESTTEST.DBF'
SQL> SELECT ID FROM YANGTK.TEST WHERE ID = 123;
ID
----------
123
通过使用DUMP_ORPHAN_KEYS过程来保存坏块中的索引键值,这样当执行完SKIP_CORRUPT_BLOCKS操作后,就可以重新建立索引了。
SQL> DECLARE
2 num_orphans INT;
3 BEGIN
4 num_orphans := 0;
5 DBMS_REPAIR.DUMP_ORPHAN_KEYS (
6 SCHEMA_NAME => 'YANGTK',
7 OBJECT_NAME => 'IND_TEST_ID',
8 OBJECT_TYPE => dbms_repair.index_object,
9 REPAIR_TABLE_NAME => 'REPAIR_TABLE',
10 ORPHAN_TABLE_NAME=> 'ORPHAN_KEY_TABLE',
11 KEY_COUNT => num_orphans);
12 DBMS_OUTPUT.PUT_LINE('orphan key count: ' TO_CHAR(num_orphans));
13 END;
14 /
orphan key count: 549
PL/SQL 过程已成功完成。
SQL> DECLARE
2 num_orphans INT;
3 BEGIN
4 num_orphans := 0;
5 DBMS_REPAIR.DUMP_ORPHAN_KEYS (
6 SCHEMA_NAME => 'YANGTK',
7 OBJECT_NAME => 'IND_TEST_NAME',
8 OBJECT_TYPE => dbms_repair.index_object,
9 REPAIR_TABLE_NAME => 'REPAIR_TABLE',
10 ORPHAN_TABLE_NAME=> 'ORPHAN_KEY_TABLE',
11 KEY_COUNT => num_orphans);
12 DBMS_OUTPUT.PUT_LINE('orphan key count: ' TO_CHAR(num_orphans));
13 END;
14 /
orphan key count: 549
PL/SQL 过程已成功完成。
注意对每个索引都要执行DUMP_ORPHAN_KEYS过程。
4.使用REBUILD_FREELISTS过程来修改FREELISTS。
如果坏块发生在FREELIST列表中的中部,则FREELIST列表后面的块都无法访问,在这个例子中,由于是人为产生的错误,清楚错误的位置不在FREELIST中,因此可以跳过此步骤,一般情况下,无法定位坏块位置,则需要执行改过程。
SQL> BEGIN
2 DBMS_REPAIR.REBUILD_FREELISTS (
3 SCHEMA_NAME => 'YANGTK',
4 OBJECT_NAME => 'TEST',
5 OBJECT_TYPE => dbms_repair.table_object);
6 END;
7 /
PL/SQL 过程已成功完成。
5.执行SKIP_CORRUPT_BLOCKS过程,是后续DML操作跳过坏块
SQL> BEGIN
2 DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
3 SCHEMA_NAME => 'YANGTK',
4 OBJECT_NAME => 'TEST',
5 OBJECT_TYPE => dbms_repair.table_object,
6 FLAGS => dbms_repair.skip_flag);
7 END;
8 /
PL/SQL 过程已成功完成。
SQL> SELECT OWNER, TABLE_NAME, SKIP_CORRUPT FROM DBA_TABLES
2 WHERE OWNER = 'YANGTK';
OWNER TABLE_NAME SKIP_COR
---------------------------- ---------------------------- --------
YANGTK TEST ENABLED
YANGTK TEST1 DISABLED
YANGTK TEST_AAA DISABLED
YANGTK TEST_PART DISABLED
已选择4行。
6.重建索引
由于数据和索引仍然存在不一致的问题,因此必须重建索引。
SQL> SELECT * FROM YANGTK.TEST WHERE ID = 123;
未选定行
SQL> SELECT ID FROM YANGTK.TEST WHERE ID = 123;
ID
----------
123
SQL> ALTER INDEX YANGTK.IND_TEST_ID REBUILD;
索引已更改。
SQL> SELECT ID FROM YANGTK.TEST WHERE ID = 123;
ID
----------
123
注意一点,重建索引一点要先DROP,然后再CREATE,使用REBUILD的方式,重建的数据源来自索引,仍然会导致问题的产生。
SQL> DROP INDEX YANGTK.IND_TEST_ID;
索引已丢弃。
SQL> DROP INDEX YANGTK.IND_TEST_NAME;
索引已丢弃。
SQL> CREATE INDEX YANGTK.IND_TEST_ID ON YANGTK.TEST(ID);
索引已创建。
SQL> CREATE INDEX YANGTK.IND_TEST_NAME ON YANGTK.TEST(NAME);
索引已创建。
SQL> SELECT ID FROM YANGTK.TEST WHERE ID = 123;
未选定行
SQL> SELECT MIN(ID) FROM YANGTK.TEST;
MIN(ID)
----------
550
包含ID = 123的块已经别标识为坏块。现在可以看到,最小的ID是550,也就是说,这个坏块中包含了549条记录。
SQL> SELECT COUNT(*) FROM ORPHAN_KEY_TABLE;
COUNT(*)
----------
1098
继续查询ORPHAN_KEY_TABLE表,可以发现,这些记录的索引(2个)已经被保存到了ORPHAN_KEY_TABLE表中。
四、恢复数据
使用DBMS_REPAIR包的目的不仅是为了使表重新可以访问,而且,使用这个包还能在一定程度上恢复被因坏块而无法读取的数据。
由于坏块产生在表上,因此索引是可以访问,所有被索引的列的数据都可以恢复。遗憾的是,Oracle的文档并没有给出恢复的方法,我查询了METALINK和ASKTOM也没有找到相应的答案,所以,恢复的工作只能靠自己摸索进行。因此,我并不能保证我的方法一定是正确的,如果想将这种方法应用的正式环境中,请慎重考虑,本人不承担任何责任。:)
言归正传,在上面的步骤中,使用DUMP_ORPHAN_KEYS过程保存了坏块中的索引键值,下面就通过这些保存的键值来进行数据的恢复。
先看一下ORPHAN_KEY_TABLE的表结构:
SQL> DESC ORPHAN_KEY_TABLE
名称 是否为空? 类型
-------------------------------------- -------- --------------
SCHEMA_NAME NOT NULL VARCHAR2(30)
INDEX_NAME NOT NULL VARCHAR2(30)
IPART_NAME VARCHAR2(30)
INDEX_ID NOT NULL NUMBER
TABLE_NAME NOT NULL VARCHAR2(30)
PART_NAME VARCHAR2(30)
TABLE_ID NOT NULL NUMBER
KEYROWID NOT NULL ROWID
KEY NOT NULL ROWID
DUMP_TIMESTAMP NOT NULL DATE
由于字段名基本上都是自解释的,这里就不在过多描述了,需要说明的是KEYROWID和KEY两个字段。
KEYROWID存放的是该索引键值对应的表中的rowid,而KEY保存的就是索引的键值。
但是查询KEY的值发现,并非像想象中一样,存放的是1、2、3……或ALL_TABLES、ACCESS$……等值,而是以ROWID方式存放的。
SQL> SELECT KEY FROM ORPHAN_KEY_TABLE WHERE INDEX_NAME = 'IND_TEST_ID' AND ROWNUM = 1;
KEY
---------------------------------------------------------------
*BAAAAAACwQL+
SQL> SELECT KEY FROM ORPHAN_KEY_TABLE WHERE INDEX_NAME = 'IND_TEST_NAME' AND ROWNUM = 1;
KEY
---------------------------------------------------------------
*BAAAAAAHQUNDRVNTJP4
这种ROWID格式如何转化为NUMBER或VARCHAR2类型呢?查询文档并没有找到相应的解决方法。
于是抱着尝试的想法,觉得DUMP一下,看看数据的结构是怎样的。
SQL> SELECT DUMP(KEY) FROM ORPHAN_KEY_TABLE WHERE INDEX_NAME = 'IND_TEST_ID' AND ROWNUM < 6;
DUMP(KEY)
----------------------------------------------------------------
Typ=208 Len=10: 2,4,0,0,0,0,2,193,2,254
Typ=208 Len=10: 2,4,0,0,0,0,2,193,3,254
Typ=208 Len=10: 2,4,0,0,0,0,2,193,4,254
Typ=208 Len=10: 2,4,0,0,0,0,2,193,5,254
Typ=208 Len=10: 2,4,0,0,0,0,2,193,6,254
这回看到希望了。还记得上面修改数据文件时123的编码吗?是不是和第一个查询中的结果很相似?
2,4,0,0,0,0前几位是不变的,最后一位254也是不变的。中间的部分就是有意义的数字了。其中第一个2表示长度是2,193表示最高位是个位,2表示最高位上的值是1,也就是说,第一个键值是数字1。
SQL> SELECT DUMP(1) FROM DUAL;
DUMP(1)
------------------
Typ=2 Len=2: 193,2
Oracle把数据在文件中的存储格式保存在ROWID字段中了。根据这个假设,我们看看字符串是不是以同样方式存储的。
SQL> SELECT DUMP(KEY) FROM ORPHAN_KEY_TABLE WHERE INDEX_NAME = 'IND_TEST_NAME' AND ROWNUM < 6;
DUMP(KEY)
----------------------------------------------------------------
Typ=208 Len=15: 2,4,0,0,0,0,7,65,67,67,69,83,83,36,254
Typ=208 Len=17: 2,4,0,0,0,0,9,65,71,71,88,77,76,73,77,80,254
Typ=208 Len=23: 2,4,0,0,0,0,15,65,71,71,88,77,76,73,78,80,85,84,84,89,80,69,254
Typ=208 Len=22: 2,4,0,0,0,0,14,65,76,76,95,65,76,76,95,84,65,66,76,69,83,254
Typ=208 Len=17: 2,4,0,0,0,0,9,65,76,76,95,65,80,80,76,89,254
显然7代表长度,后面跟着的明显就是ASCII编码。
SQL> SELECT CHR(65) CHR(67) CHR(67) CHR(69) CHR(83) CHR(83) CHR(36) FROM DUAL;
CHR(65)
-------
ACCESS$
知道这个规律,就可以着手进行恢复了,首先先了一个小程序用来把ROWID类型转换为NUMBER类型或VARCHAR2类型。
SQL> CREATE OR REPLACE FUNCTION F_DUMP_FROM_ROWID
2 (
3 P_TYPE IN VARCHAR2,
4 P_DUMP_ROWID IN UROWID
5 )
6 RETURN VARCHAR2 AS
7 V_DUMP_ROWID VARCHAR2(1000);
8 V_NUMBER_STR VARCHAR2(1000);
9 V_POSITION NUMBER;
10 V_NUMBER VARCHAR2(2);
11 BEGIN
12 SELECT DUMP(P_DUMP_ROWID, 16, 7) INTO V_DUMP_ROWID FROM DUAL;
13 V_DUMP_ROWID := SUBSTR(V_DUMP_ROWID, INSTR(V_DUMP_ROWID, ',') + 1);
14 V_DUMP_ROWID := SUBSTR(V_DUMP_ROWID, 1, LENGTH(V_DUMP_ROWID) - 3);
15
16 IF P_TYPE = 'VARCHAR2' THEN
17 V_DUMP_ROWID := REPLACE(V_DUMP_ROWID , ',');
18 RETURN(UTL_RAW.CAST_TO_VARCHAR2(V_DUMP_ROWID));
19 ELSIF P_TYPE = 'NUMBER' THEN
20 V_DUMP_ROWID := V_DUMP_ROWID ',';
21 V_POSITION := INSTR(V_DUMP_ROWID, ',');
22
23 WHILE (V_POSITION != 0) LOOP
24 V_NUMBER := SUBSTR(V_DUMP_ROWID, 1, V_POSITION - 1);
25 V_DUMP_ROWID := SUBSTR(V_DUMP_ROWID, V_POSITION + 1);
26
27 IF V_POSITION = 2 THEN
28 V_NUMBER_STR := V_NUMBER_STR '0' V_NUMBER;
29 ELSIF V_POSITION = 3 THEN
30 V_NUMBER_STR := V_NUMBER_STR V_NUMBER;
31 ELSE
32 RAISE_APPLICATION_ERROR(-20002, 'DUMP ERROR CHECK THE INPUT ROWID');
33 END IF;
34
35 V_POSITION := INSTR(V_DUMP_ROWID, ',');
36 END LOOP;
37
38 V_NUMBER_STR := REPLACE(V_NUMBER_STR , ',');
39
40 RETURN(UTL_RAW.CAST_TO_NUMBER(V_NUMBER_STR));
41 ELSE
42 RAISE_APPLICATION_ERROR(-20001, 'TYPE NOT VALID OR CAN''T TRANSALTE ' P_TYPE ' TYPE');
43 END IF;
44 END;
45 /
函数已创建。
测试一下函数的功能。
SQL> SELECT F_DUMP_FROM_ROWID('NUMBER', KEY) FROM ORPHAN_KEY_TABLE
2 WHERE INDEX_NAME = 'IND_TEST_ID' AND ROWNUM < 6;
F_DUMP_FROM_ROWID('NUMBER',KEY)
-------------------------------------------------------------
1
2
3
4
5
SQL> SELECT F_DUMP_FROM_ROWID('VARCHAR2', KEY) FROM ORPHAN_KEY_TABLE
2 WHERE INDEX_NAME = 'IND_TEST_NAME' AND ROWNUM < 6;
F_DUMP_FROM_ROWID('VARCHAR2',KEY)
-------------------------------------------------------------
ACCESS$
AGGXMLIMP
AGGXMLINPUTTYPE
ALL_ALL_TABLES
ALL_APPLY
好了,剩下的事情就简单了。我们将ORPHAN_KEY_TABLE表中的记录转变后,重新插入到TEST表中即可。
SQL> INSERT INTO YANGTK.TEST (ID, NAME)
2 SELECT
3 F_DUMP_FROM_ROWID('NUMBER', A.KEY),
4 F_DUMP_FROM_ROWID('VARCHAR2', B.KEY)
5 FROM ORPHAN_KEY_TABLE A, ORPHAN_KEY_TABLE B
6 WHERE A.KEYROWID = B.KEYROWID
7 AND A.INDEX_NAME = 'IND_TEST_ID'
8 AND B.INDEX_NAME = 'IND_TEST_NAME';
已创建549行。
SQL> SELECT * FROM YANGTK.TEST WHERE ID = 1;
ID NAME
---------- ------------------------------
1 ACCESS$
SQL> SELECT * FROM YANGTK.TEST WHERE ID = 123;
ID NAME
---------- ------------------------------
123 ALL_REPCONFLICT
SQL> COMMIT;
至此,数据恢复已经完成。
最后,需要说明几点。
我只做了NUMBER类型和VARCHAR2类型的恢复测试,其他类型的恢复还没有测试,目前我做的函数也只包含了恢复NUMBER和VARCHAR2类型的功能。而且,目前只进行了单列B数索引的恢复,组合索引、BITMAP索引等其它类型索引没有测试。另外,如果VARCHAR2(CHAR)类型中包含中文,在ZHS16GBK字符集下我测试通过,其他字符集没有测试,但估计对于一般中文字符集都不会有问题,但是单字节字符集可能会有问题。