AnySQL.net

    这几天网上恶耗不断, 昨天有人问我这个问题, 我认为这样的情况有很大的运气成份在里面, 不一定能open resetlogs的. 已有工程师在那他那儿试了以下步骤了.

1, 直接open resetlogs报, ora-600 [2662]

2, 用(Event 10015)ADJUST_SCN (在eygle.com上查一下)调整数据库的SCN.

3, 第二步的open resetlogs产生了以下错误信息

*** 2006-01-22 02:58:54.086
ksedmp: internal or fatal error
ORA-00600: internal ..., arguments: [4194], [39], [59], ...
Current SQL statement for this session:
update lob$ set retention = :1 where retention >= 0
----- Call Stack Trace -----

4, 我所知道的最后一步能试的是加上_offline_rollback_segments试试

    上面的步骤在current log损坏时一般是有用的, 不过现在是人为删除了, 这样activate log部份丢失的很多, 这时就不知道有没有问题, 下午shutdown abort后删除所有的log试试.

    我将我笔记本上的一个库(Oracle 10.2)先shutdown abort, 然后移走所有的online log, 发完不完全恢复命讼后, 在参数中加了"_allow_resetlogs_corruption=true"之后, 就能起来了, 的确报了很多的ORA-600 [2662]错误, 生成了很多的Trc文件, 不过在所有的文件中找不到"update lob$"语句, 要重现这种错看来是很难, 有点运气的成份在内. 打开之后还不能正常关闭, 关闭时出ora-3113错误, 总之停个删除log的人真的是太历害了.

    估计那个库只有用DUL/AUL去恢复了, 可惜AUL还不太支持LOB类型.

    我曾遇到过数据文件名字中有空格的情况, 结果呢我用SQL来生成的拷贝所有文件的角本怎么都不对, 那事当时整了我15分钟, 用SQL语句或用图形工具时都要注意这一点. 下面是我建的一个表空间, 看起来是有同样的文件名的, 看了长度后才知道的.

SQL> create tablespace test datafile
  2    '/oracle/ora9i/data01/alex/testdata01.dbf' size 10m
  3  extent management local autoallocate;

Tablespace created.

SQL> alter tablespace test add datafile
  2  '/oracle/ora9i/data01/alex/testdata01.dbf ' size 10m;

Tablespace altered.

SQL> select max(ts#) from v$datafile;

  MAX(TS#)
----------
        12

SQL> col name format a40
SQL> select name,length(name) from v$datafile where ts#=12;

NAME                                    LENGTH(NAME)
---------------------------------------- ------------
/oracle/ora9i/data01/alex/testdata01.dbf          40
/oracle/ora9i/data01/alex/testdata01.dbf          41

    以下连接仅为提供查询方便, 更详细的信息请访问Oracle Metalink.

• 9.2.0.4 9.2.0.5 9.2.0.6 9.2.0.7 9.2.0.8 9i升级指南
• 10.1.0.3 10.1.0.4 10.1.0.5 10g R1升级指南
• 10.2.0.2 10.2.0.3 10g R2升级指南

    对于一个DBA, 这些也是要经常看看的. 下面列出了Oracle各版本的升级补丁号

9.2.0.4  = 3095277
9.2.0.5  = 3501955
9.2.0.6  = 3948480
9.2.0.7  = 4163445
9.2.0.8  = 4547809
10.1.0.3 = 3761843
10.1.0.4 = 4163362
10.1.0.5 = 4505133
10.2.0.2 = 4547817
10.2.0.3 = 5337014

    仅供参考.

    今天用SQLLDR装载数据, 没有足够的注意, 管应用程序的人说, 我们装载的数据不对, 后面多了一个空格. 过了好一会儿我们才查到原因, 居 然是因为Windows和Linux/Unix的文本编辑器中对换行的不同处理, 在Windows中是用0x0d(13),0x0a(10)两个字符来表示的, 而Linux/Unix中只用一个字符0x0a (10)来表示. 将Windows上编辑好的文本文件以Binary方式FTP上去(或以SCP拷上去)后, 用Linux/Unix下的SQLLDR装载, 因此装载进去的数据中就多了一个字符, 如下所示:

SQL> SELECT DUMP(COL1) FROM T_TEST WHERE ROWNUM < 10;

DUMP(COL1)
----------------------------------------------------
Typ=1 Len=4: 35,32,50,13
Typ=1 Len=3: 35,49,13
Typ=1 Len=9: 45,68,69,76,69,84,69,45,13
......

    在实际的应用中, 就装载数据本身的技术而言是很简单的, 不过如果由于数据装载引起了应用服务器逻辑上的错误, 后果也是很严重的. 还好 这次发现的及时, 没有造成什么重要问题.

    又一次证明DBA细心, 考虑周到是很重要的习惯.

    Oracle的SQLLDR是用来将文本文件中的记录装载到数据库中的工具, 其并行(Parallel),直接(Direct)的装载模式是目前所知最快的方式. 不过用于指定文本格式的控制文件有点难于写, 我在写时也经常需要查阅文档. 为了方便我还是在这儿写一个例子吧, 下面是样表的结构:

SQL> create table test(
  2    num_col number(10),
  3    char_col char(10),
  4    var_col  varchar2(10),
  5    date_col date,
  6    blob_col blob,
  7    clob_col clob,
  8    raw_col  raw(20)
  9  );

Table Created.

    在这个例子中有CLOB/BLOB列, 因此直接模式不能用, 还需要将ROWS参数设为1, 下面是SQLLDR用的控制文件: