www.eygle.com

---

February 3, 2007

终极恢复孰弱孰强-DUL vs AUL

作者:eygle

出处:http://blog.eygle.com

这几天在帮朋友作数据恢复，由于已经到了无可救药的地步，只能使用终极手段进行恢复，直接从文件中读取数据进行恢复。

在恢复过程中反复对比了DUL和dcba的AUL，感觉到了两者的不同。

DUL在处理文件损坏的情况下，如文件部分缺失、数据块损坏的恢复明显要弱于AUL，AUL经过几次修正之后已经能够很好的处理这些情况。

DUL可以通过如下设置跳过文件的损坏部分:

0 1 D:\DUL\DATAFILE\SYS1ORCL.DBF
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1 endblock 1000000
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1000001 endblock 2000000
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 2000001 endblock 2550000

但是在扫描存在大量坏块的文件时，大量的错误信息让人崩溃；而AUL可以很容易的安静地处理这些损坏。

在处理LOB对象时，我做过测试AUL在存在SYSTEM的情况下，能够非常完美的恢复图片对象：

D:\oradata\EYGLE\DATAFILE>aul4b.exe
Register Code: 25FV-NFCH-B53H-RO9V-SZHV
AUL : AnySQL UnLoader(MyDUL) for Oracle 8/8i/9i/10g, release 4.0.1

(C) Copyright Lou Fangxin 2005-2006 (AnySQL.net), all rights reserved.

AUL> open crl.txt

* ts# fno rfn ver bsize blocks filename
- ---- ---- ---- --- ----- ---------- -----------------------------------
Y 4 4 4 a2 8192 640 O1_MF_USERS_2G8OJYYS_.DBF
AUL> scan extents
2007-02-02 10:52:09
2007-02-02 10:52:09
AUL> scan table to table.txt
2007-02-02 10:52:29
2007-02-02 10:52:29

AUL> list table eygle;
UNLOAD TABLE eygle.EYGLE TO EYGLE.txt;
UNLOAD TABLE eygle.EYGLE_BLOB TO EYGLE_BLOB.txt;
AUL> UNLOAD TABLE eygle.EYGLE_BLOB TO EYGLE_BLOB.txt;
2007-02-02 10:58:16
Unload OBJD=14367 FILE=4 BLOCK=19 CLUSTER=0 ...
2007-02-02 10:58:16
AUL>

这个数据卸载或加载之后，与原数据完全相符：

E:\rec\blobtest>sqlldr eygle/eygle control=EYGLE_BLOB_sqlldr.ctl

SQL*Loader: Release 10.2.0.1.0 - Production on 星期五 2月 2 11:43:32 2007

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

SQL*Loader-292: 加载 XML, LOB 或 VARRAY 列时忽略 ROWS 参数

加载完成 - 逻辑记录计数 2。

E:\rec\blobtest>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on 星期五 2月 2 11:43:41 2007

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

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

SQL> connect eygle/eygle
已连接。
SQL> desc eygle_blob;
名称 是否为空? 类型
----------------------------------------- -------- ----------------------------
FID NUMBER
FNAME VARCHAR2(50)
FDESC VARCHAR2(200)
FPIC BLOB

SQL> select fid,fname,length(fpic) from eygle_blob;

FID FNAME LENGTH(FPIC)
---------- -------------------------------------------------- ------------
1 1.jpg 333769
2 2.jpg 300332
1 1.jpg 333769
2 2.jpg 300332

SQL>

当然，DUL也有很强大的地方，比如转储文件格式等方面要优于AUL。

不过AUL最大的好处在于可以很快地得到技术支持，DCBA最近正在编写完备AUL的手册用于指导用户恢复，而且DCBA修复Bug的速度也是超快的，在这次恢复中他就为我修复了一个Bug，感谢DCBA对我的大力支持。

其实很多时候，到达用户现场后，你就只剩下一个想法，尽快帮用户最大程度的恢复数据，因为到了最后的阶段，数据已经影响到了很多人的生活，我们能做的就是尽最大可能以最快速度进行恢复。

-The End-

Posted by eygle at 8:22 PM | Comments (21)

---

DBA警世录:有些习惯DBA需要养成

作者:eygle

出处:http://blog.eygle.com

这几天，在帮助一个朋友进行数据恢复。

造成故障的原因很简单，因为维护升级时错误的连接到生产主机，结果导致生产库故障，数据文件被删除并部分覆盖。

因为这个案例，我想说一下作为一个DBA应该养成的一些基本习惯。
以前曾经写过一篇What Kind Of DBA we need-我们需要什么样的DBA?。

今天想说的是一些在工作中应该养成的习惯或者说基本守则：
1.经常使用hostname命令
在Linux/Unix上，我们使用ssh或telnet等通过多次跳转，很容易变更了连接主机，如果不经过确认就可能在不正确的主机上执行了错误的操作。
通过hostname命令可以确认我们连接到的主机，避免发生不应该的误操作。在执行中要操作之前一定要通过hostname命令确认连接主机,这是DBA或者系统管理员应该养成的习惯:

[oracle@jumper oracle]$ hostname
jumper.hurray.com.cn

2.使用pwd确认路径
经常有朋友在错误的路径下错误的执行了"rm -rf *"等命令，这类错误的发生率居然也是很高的。
所以作为一个DBA，经常性的执行pwd命令来确认自己的工作路径:

[oracle@jumper oracle]$ pwd
/opt/oracle

3.确认instance_name等数据库中要信息
在执行truncate/drop等操作之前，应该确认连接到了哪个数据库，从v$database或v$instance等视图中可以获得这些信息(可能需要授权)

SQL> select instance_name,host_name from v$instance;

INSTANCE_NAME HOST_NAME
---------------- ----------------------------------------------------------------
eygle jumper.hurray.com.cn

4.通过id命令确认用户信息
要经常通过id命令确认用户信息，以免切换用户而导致不自觉的异常操作。

[gqgai@jumper gqgai]$ id
uid=2003(gqgai) gid=101(dba) groups=101(dba)

我见到过的案例，用户切换为root，误操作删除过整个操作系统，导致了严重的故障。

通过一些良好习惯的养成，可以使得我们少犯错误。
所以，有一些习惯是需要养成的。

以前的DBA四大守则也应该引起诸位初学DBA的朋友注意:
http://www.eygle.com/archives/2006/03/the_four_rule_for_dba.html

-The End-

Posted by eygle at 2:44 PM | Comments (14)

---