[转帖]DBMS_REPAIR的使用_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4032 | 回复: 0   主题: [转帖]DBMS_REPAIR的使用        下一篇 
kim
注册用户
等级:中校
经验:1729
发帖:222
精华:0
注册:2011-7-21
状态:离线
发送短消息息给kim 加好友    发送短消息息给kim 发消息
发表于: IP:您无权察看 2011-9-21 7:44:48 | [全部帖] [楼主帖] 楼主

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字符集下我测试通过,其他字符集没有测试,但估计对于一般中文字符集都不会有问题,但是单字节字符集可能会有问题。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论