接到过几次由于Drop误操作引起的恢复请求, 在那种情况下, 最主要的问题是没有办法定位被Drop的表的Data Object ID的值. 由于Oracle在执行Drop操作时并不真正地对数据文件清行清理(这是我们能恢复的前提), 从儿当你的应用中有很多的临时表, 并经常Drop来Drop去的话, 在恢复时进行整个数据文件扫描, 会发现很多的Data Object ID, 而你不知道那个是包括了有用的数据.
事实上这种情况下, 恢复的主要式作是去验证这些Data Object ID是不是包含了真正的数据. 现在我们有了MyLOG, 到可以用来做这件事, 当前要求你能提供执行Drop误操作时所用的联机日志或归档日志文件.
在LOGTAB.TXT文件中加入下面一行:
9999,18,OBJ$,
在LOGCOL.TXT文件中加入下面几行:
9999,1,OBJ#,NUMBER
9999,2,DATAOBJ#,NUMBER
9999,3,OWNER#,NUMBER
9999,4,NAME,VARCHAR2
9999,5,NAMESPACE,NUMBER
9999,6,SUBNAME,VARCHAR2
9999,7,TYPE#,NUMBER
9999,8,CTIME,DATE
9999,9,MTIME,DATE
9999,10,STIME,DATE
9999,11,STATUS,NUMBER
9999,12,REMOTEOWNER,VARCHAR2
9999,13,LINKNAME,VARCHAR2
9999,14,FLAGS,NUMBER
9999,15,OID$,RAW
9999,16,SPARE1,NUMBER
9999,17,SPARE2,NUMBER
9999,18,SPARE3,NUMBER
9999,19,SPARE4,VARCHAR2
9999,20,SPARE5,VARCHAR2
9999,21,SPARE6,DATE
用MyLOG打开联机或归档日志文件, 执行"EXTRACT START 2 TABLE OBJ$"命令, 你很容易从解出来的Redo SQL中找到有用的信息:
RBA=0x000069.000010b4.00b0, XID=0x0009.016.00000093, RID=AAAAASAABAAAGsmAAI
DELETE OBJ$ WHERE OBJ# = 10566 AND DATAOBJ# = 10566 AND OWNER# = 25 AND NAME = 'MYLOG10G' AND NAMESPACE = 1 AND SUBNAME = NULL AND TYPE# = 2 AND CTIME = '2007-05-29 10:50:12' AND MTIME = '2007-05-29 10:50:12' AND STIME = '2007-05-29 10:50:12' AND STATUS = 1 AND REMOTEOWNER = NULL AND LINKNAME = NULL AND FLAGS = 0 AND OID$ = NULL AND SPARE1 = 6 AND SPARE2 = 1;
不知道Oracle的Log Miner是不是能解出这些对数据字典的操作?