AnySQL.net

    下面是用AUL 4.0.0 Beta版本恢复Windows上10g R2数据库CLOB数据的一个演示, 首先是创建测试表:

SQL> CREATE TABLE T_CLOBDEMO
  2  (
  3    ID NUMBER,
  4    CLOB1 CLOB,
  5    CLOB2 CLOB,
  6    CLOB3 CLOB
  7  )
  8  LOB(CLOB3) STORE AS (DISABLE STORAGE IN ROW)
  9  /

Table created.

SQL> INSERT INTO T_CLOBDEMO VALUES (1,'INLINE CLOB', NULL,NULL);

1 row created.

    然后到SYS用户下, 运行ALTER SYSTEM CHECKPOINT以将数据写到数据文件中, 现在CLOB2和CLOB3列中是空值, CLOB1中的值够小, 应当是INLINE CLOB, 我们将CLOB的数据和其他列的数据恢复到一个文件中.

AUL> set lob_convert 1
  Current LOB_CONVERT is : 1-GBK
AUL> set lob_storage 0
  Current LOB_STORAGE is : 0-INLINE
AUL> set clob_edian big
  Current CLOB_EDIAN is : BIG
AUL> unload table anysql.t_clobdemo;
2006-12-17 19:38:08
Unload OBJD=9956 FILE=4 BLOCK=4611 CLUSTER=0 ...
1|INLINE CLOB
2006-12-17 19:38:08

    可以看到数据被成功恢复, 接下来我们用AnySQL来将CLOB2和CLOB3列中插入内容(一个64KB大小的文本文件), 如下所示:

    下面是用AUL 4.0.0 Beta版本恢复Windows上10g R2数据库BLOB数据的一个演示, 首先是创建测试表:

SQL> CREATE TABLE T_BLOBDEMO
  2  (
  3    ID NUMBER,
  4    BLOB1 BLOB,
  5    BLOB2 BLOB,
  6    BLOB3 BLOB
  7  )
  8  LOB(BLOB3) STORE AS (DISABLE STORAGE IN ROW)
  9  /

Table created.

SQL> INSERT INTO T_BLOBDEMO VALUES (1, '3031323334', NULL, NULL);

1 row created.

    提交后, 到SYS用户执行ALTER SYSTEM CHECKPOINT命令, 将数据写入数据文件中, 然后就可以用AUL 4来恢复了. 在上面的例子中, 我们将BLOB1字段更新为"01234"这几个字母, 来看一下恢复出来的对不对?

AUL> UNLOAD TABLE anysql.t_blobdemo;
2006-12-17 21:43:27
Unload OBJD=9966 FILE=4 BLOCK=4859 CLUSTER=0 ...
1|01234
2006-12-17 21:43:27

    接下来用AnySQL来将一个图片文件(test.jpg)更新到BLOB2和BLOB3字段中:

    现在我们将两张LOB的演示表, 用AUL 4.0.0 Beta恢复成DMP格式, 然后看看能不能成功导入到数据库中:

AUL> set clob_edian big
  Current CLOB_EDIAN is : BIG
AUL> set lob_convert 1
  Current LOB_CONVERT is : 1-GBK
AUL> set charset 852
  Current CHARSET is : 0x0354
AUL> set output_style dmp
  Current OUTPUT_STYLE is : DMP
AUL> unload table anysql.t_clobdemo to t_clobdemo.dmp;
2006-12-17 22:27:40
Unload OBJD=9956 FILE=4 BLOCK=4611 CLUSTER=0 ...
2006-12-17 22:27:40
AUL> unload table anysql.t_blobdemo to t_blobdemo.dmp;
2006-12-17 22:27:46
Unload OBJD=9966 FILE=4 BLOCK=4859 CLUSTER=0 ...
2006-12-17 22:27:46

    现在导入T_CLOBDEMO表:

C:\MYDUL>imp system/oracle file=t_clobdemo.dmp fromuser=mydul touser=anysql ignore=y

Import: Release 10.2.0.1.0 - Production on Sun Dec 17 22:28:33 2006

Copyright (c) 1982, 2005, Oracle.  All rights reserved.


Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

Export file created by EXPORT:V08.01.07 via conventional path

Warning: the objects were exported by MYDUL, not by you

import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
. importing MYDUL's objects into ANYSQL
. . importing table                   "T_CLOBDEMO"          2 rows imported
Import terminated successfully without warnings.

    从SQL*Plus中查一下CLOB字段的长度, 和以前的两条记录是否一致:

SQL> select dbms_lob.getlength(Clob2) len2,
  2    dbms_lob.getlength(Clob3) len3 from t_Clobdemo;

      LEN2       LEN3
---------- ----------
     63681      63681
     63681      63681
     63681      63681
     63681      63681

    现在导入T_BLOBDEMO表:

    不小心Truncate表的事情也是有的, 其中大部份时因为工具连错了库, 从儿跑错了角本. 遇到这种事情而没有备份时怎么办呢? 首先要停止数据库, 将这个表所在的表空间的文件拷贝出来, 因为Oracle在Truncate只时将相应Segment的第一个块格式化掉了, 而后面的都还存在, 到下次用时到才真正地重新格式化. 下面来讲一个Truncate表后进行恢复的例子:

SQL> CREATE TABLE T_TRUNCATE AS SELECT * FROM TAB;

Table created.

SQL> SELECT COUNT(*) FROM T_TRUNCATE;

  COUNT(*)
----------
        14

SQL> ALTER SYSTEM CHECKPOINT;

System altered.

SQL> TRUNCATE TABLE T_TRUNCATE;

Table truncated.

SQL> ALTER SYSTEM CHECKPOINT;

System altered.

    在Truncate时只是Segment Header格式化了, 并将Data Object ID换成一个新的值, 我们可以在AUL中用DESC命令来查看:

AUL> desc anysql.t_truncate

Storage(OBJ#=9976 OBJD=9977 TS=4 FILE=4 BLOCK=5235 CLUSTER=0)
No. SEQ INT Column Name                   Type
--- --- --- ----------------------------- ----------------
  1   1   1 TNAME                         VARCHAR2(30) NOT NULL
  2   2   2 TABTYPE                       VARCHAR2(7)
  3   3   3 CLUSTERID                     NUMBER

    要恢复这个表的数据, 首先要在AUL中运行SCAN EXTENT命令, 因为Segment Header被格式化了, 所以Extent Map也可能丢失, 而Scan Extent则将扫描整个数据文件并将Extent分配信息写入AULEXT.TXT文件:

    通过试验, 发现LOB的一个CHUNK中的所有块必须是在一个Extent中的, 并且是连续的, 不相信的话你可以试试能不能指定CHUNK的大小的值为大于表的Next Extent的值? 基于这个规律, 在AUL 4中增加了对CHUNK的有限支持. 下面上用于测试的两张表, 只有一个字段, 为CLOB类型, 表中只有有一条记录, 内容相同:

SQL> SELECT TABLE_NAME,COLUMN_NAME,CHUNK FROM USER_LOBS;

TABLE_NAME      COLUMN_NAME       CHUNK
--------------- ------------ ----------
T_CHUNK2        COL1              32768
T_CHUNK1        COL1              16384

    接下来用新增的CHUNK选项指定表中所有LOB的CHUNK大小, 单位是数据块, 默认值是1, 从这儿我们可以看出如果一个表中有多个LOB字段, 且CHUNK大小不一样, AUL 4现在还是不支持的. 下面我们将LOB内容导出成独立的文件:

AUL> set clob_edian big
  Current CLOB_EDIAN is : BIG
AUL> set lob_storage 1
  Current LOB_STORAGE is : 1-FILE
AUL> set lob_convert 1
  Current LOB_CONVERT is : 1-GBK
AUL> unload table anysql.t_chunk1 chunk 2;
2006-12-19 12:58:18
Unload OBJD=9986 FILE=4 BLOCK=5243 CLUSTER=0 ...
LOB_0100147C_1FE8.dat
2006-12-19 12:58:18
AUL> unload table anysql.t_chunk2 chunk 4;
2006-12-19 12:58:25
Unload OBJD=9989 FILE=4 BLOCK=5523 CLUSTER=0 ...
LOB_01001594_1FE8.dat
2006-12-19 12:58:25

    上面的命令生成了两个文件: LOB_0100147C_1FE8.dat和LOB_01001594_1FE8.dat, 下面在OS上看一下文件大小, 并和原始数据进行文本比较: