今天发生了一件很低级的操作引起的系统瘫痪。

         开发人员做了这么一个动作：

       update global_name set global_name=”;

 结果是，oracle数据库瞬时就crash了。重新启动数据库无法open：

*** SESSION ID:(152.2387) 2010-09-02 20:37:52.973

*** 2010-09-02 20:37:52.973

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [18061], [1403], [], [], [], [], [], []

—– Call Stack Trace —–

calling             call    entry               argument values in hex     

location            type    point               (? means dubious value)    

——————– ——– ——————– —————————-

ksedst()+27         call    ksedst1()            0 ? 1 ?

ksedmp()+557        call     ksedst()            0 ? 118 ? 0 ? BF8359B4 ?

                                                  253B09CB ? 93CCCE1F ?

ksfdmp()+19         call    ksedmp()            3 ? BF8359A0 ? AC152A0 ?

                                                  CBD2D20 ? 3 ? CB84398 ?

 

起因是一个db link 无法使用了。

这个命令会修改数据字典props$,而在数据库启动时会检查该字典表，并校验global_name字段，如果为空，则无法启动。

这个时候，最好的办法是从之前的备份中，按照基于时间点的方式恢复数据库了。

因为客户的数据量不大，所以我们确实建议客户从历史备份恢复了先前的数据。

同时，数据库内核研究专家同事双全给出了更优的解决办法（但请勿在任何生产或开发环境模拟）

但是，我需要提醒我们的客户们和潜在客户们：
1.不要过于放开系统权限。如果你不知道怎么定制安全守则，可以联系我，我们一起来制订和完善；
2.如果没有做系统备份，请尽快做起来，而且要定期做恢复测试
3.不知道后果的命令，最好打我们的技术咨询热线确认下