使用Event修改SCN报ORA-01031权限不足的解决方法。

2020-06-27 00:00:00 数据库 专区 源码 告警 研究
断网一个多星期,宽带还没有接通,今天到公司,把我之前遇到一个恢复的小例子总结一下。 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,可以成功打开数据库,供用户导出表数据。

相关文章