断网一个多星期，宽带还没有接通，今天到公司，把我之前遇到一个恢复的小例子总结一下。 3月初碰到的一个奇怪问题今天终于有了答案。一客户数据库，突然当机，重启时报01555，在告警日志中可以看到是一查询seq$的SQL，导致OPEN失败。客户有备份，催着解决问题，就没在深入研究，直接恢复了事。 这个问题再次重现，解决步骤如下： 前些天，又遇到一台小机的磁盘突然崩溃，磁盘有损坏，主库再也打不开。有几张表比较紧急，等不急恢复。客户希望快速打开数据库，导出数据到另一个中。在去掉校验和，并且设置了_db_always_check_system_ts去掉系统表空间的块校验后。再次OPEN数据库，告警日志中报如下错误： OPEN过程中，告警日志中报如下错误： Tue Jul 10 14:47:03 2012 alter database open Tue Jul 10 14:47:03 2012 SMON: enabling cache recovery Tue Jul 10 14:47:03 2012 ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, Query Duration=1341902820 sec, SCN: 0x0000.00230351): Tue Jul 10 14:47:03 2012 select ctime, mtime, stime from obj$ where obj# = :1 怀疑是SYSTEM表空间中某个块的SCN比较新，OPEN时Oracle要做回滚，这种问题解决方法也简单，打SCN调大，大于块的SCN，Oracle就不会再去回滚。alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1'命令可以增大SCN，这种方法很多网站上都有，我曾经也使用过，但，这次使用的时候，报如下错误： *** 2012-07-10 14:56:10.276 ksedmp: internal or fatal error ORA-01031: insufficient privileges Current SQL statement for this session: alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1' 没有权限。我已经是SYS用户了，还报没有权限。三月份的时候，就是报这个错，所以用户只能等着从备份恢复数据。 其实解决方法很简单，既然使用Event没法改，我们可以直接修改SGA中的SCN，步骤如下： sqlplus / as sysdba startup mount; oradebug setmypid oradebug DUMPvar SGA kcsgscn_ 上面这条语句，可以显示出SCN的地置，比如，显示结果如下： kcslf kcsgscn_ [7000000100120C0, 7000000100120F0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 07000000 从7000000100120C0开始的8个地节，就是SCN，只不过库还处于Mount状态，显示结果还是0.接下来，可以按如下步骤，将此处的SCN改大点： 1、查询当前的SCN： SQL> col CURRENT_SCN for 999999999999999 SQL> select current_scn from v$database; CURRENT_SCN ---------------- 12622610288579 2、以查询结果为基础，将SCN改大些： oradebug poke 0x7000000100120C 8 0xC7AEE33CFC3 原来的SCN是B7AEE33CFC3（十进制是12622610288579），我改成C7AEE33CFC3。把高位从B改成C。 修改之后，以alter database open read only，可以成功打开数据库，供用户导出表数据。