oracle系统异常终止,oracle进程异常中止时登录挂起问题的解决

今天一个朋友找我处理帮忙处理一个oracle问题，原因是用户不能登录了。

起因是这样的：

因为业务推广，访问量大增，造成oracle压力大增，系统IDLE几乎为0。我那朋友情急之下，把用户的连接都用kill -9的方式干掉了。

然后，就发现，怎么都登录不进去了，就挂在登录界面上，没有任何提示。

我登录上去看了一下，乖乖，ps -ef|grep ora_一个进程都没有了，也就是说，他把所有的连接包括oracle自身的关键进程都干掉了。

这个问题后来得到解决。下面在我本机简单模拟当时的场景，说说解决步骤和方法。

1、首先杀掉所有oracle进程：

[oracle@rep ~]$ ps -ef|grep ora|awk '{print $2}'|xargs kill -9

2、用户登录

[oracle@rep ~]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on D??úáù 7?? 28 13:50:36 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

With the Partitioning option

JServer Release 9.2.0.4.0 - Production

sys@REP>

sys@REP> exit

Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

With the Partitioning option

JServer Release 9.2.0.4.0 - Production

可见，用sys登录没有问题。

[oracle@rep ~]$ sqlplus suk/suk

SQL*Plus: Release 9.2.0.4.0 - Production on D??úáù 7?? 28 13:52:44 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

用普通用户suk登录就一直挂在这个界面了，后台alert也没有任何信息。

用sys登录时是用操作系统认证，所以能顺利登录。而用普通用户登录需要通过数据库验证，而数据库的相关进程是不存在的，所以不能完成验证过程。

但是，一般情况下，如果数据库是关闭的，用普通用户登录是会报错的，但在这里为什么不会报错呢？

3、接着尝试关闭数据库

[oracle@rep ~]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on D??úáù 7?? 28 14:02:22 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

With the Partitioning option

JServer Release 9.2.0.4.0 - Production

sys@REP> shutdown immediate

界面也一直停留在这里，无法关闭。

通过sqlplus "/as sysdba"登录信息我们可以知道，sqlplus认为oracle数据库并没有关闭。

oracle的进程都不存在了，但sqlplus为什么认为oracle没有关闭呢？它是根据什么来判断的？

4、查看此时的共享内存段情况

[oracle@rep ~]$ ipcs -as

------ Shared Memory Segments --------

key shmid owner perms bytes nattch status

0x91c11414 491531 oracle 640 142606336 10

------ Semaphore Arrays --------

key semid owner perms nsems

0xeddca300 360448 oracle 640 154

------ Message Queues --------

key msqid owner perms used-bytes messages

从上面的信息可以看出，oracle之前占用的共享内存段和信号段都还在，而sqlplus是根据这些信息来判断数据库是否关闭的。

我们虽然kill了oracle的进程，但是并没有清除其对应的共享内存段和信号段。

原因找到的，下面就是清除共享内存段和信号段了。

清除共享内存段：

要清除oracle共享内存段，必须保证没有任何连接连接到oracle数据库上，否则清除共享内存段会失败。

我们用暴力方法强制杀死连接到oracle的进程：

[root@rep ~]# ps -ef|grep ora|awk '{print $2}'|xargs kill -9

[root@rep ~]# su - oracle

[oracle@rep ~]$ ipcrm -m 491531

清除信号段：

[oracle@rep ~]$ ipcrm -s 360448

查看此时共享内存等信息：

[oracle@rep ~]$ ipcs -as

------ Shared Memory Segments --------

key shmid owner perms bytes nattch status

------ Semaphore Arrays --------

key semid owner perms nsems

------ Message Queues --------

key msqid owner perms used-bytes messages

从上面信息看到，共享内存段和信号段已经被清除。

5、启动oracle

清除完信号段后，我们再用sys登录数据库，就会发现，sqlplus已经认为数据库是关闭的了。

此时我们可以正常启动数据库：

[oracle@rep ~]$ sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on D??úáù 7?? 28 14:17:46 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

idle> startup

ORACLE instance started.

Total System Global Area 135337420 bytes

Fixed Size 452044 bytes

Variable Size 109051904 bytes

Database Buffers 25165824 bytes

Redo Buffers 667648 bytes

Database mounted.

Database opened.

其实这种情况下，我们只需要清除信号段就可以正常启动数据库，但为了更彻底一点，我们选择了把共享内存也一并清除。

一般遇到这种情况有两种解决方法：

1、直接重启OS

2、清除共享内存和信号量

最后简单总结一下：

1、oracle进程终止不代表数据库关闭

2、oracle进程异常中止时要及时清除对应的共享内存段和信号段

3、sqlplus是根据信号段来判断oracle数据库是否是关闭的