一则数据库无法启动的奇怪案例分析

关于数据库的启停，以前一直认为是最简单，最没有技术含量的任务，但是接手的环境越多，越来越证明我最初的想法是错误的。数据库的启停是一个敏感操作，重启一定是有着特定的原因和需求。而且这个过程中存在这太多的可能性，很可能在同一会话窗口中，停掉数据库再次启动就会报错；很可能硬件扩容，也会导致数据库实例无法启动；这个时候重启前的准备和分析就尤为重要。

在此大体把启停中的问题归为三类，数据库无法启动，数据库无法登录，数据库宕机。我们在此主要讨论数据库无法启动的场景。

看起来很简单的一件事情，重启的过程中总是可能节外生枝，总是感觉数据库实例有时候不是那么配合，总是在启动过程中会发牢骚。从我的经历来看，我碰到的绝大多数问题都发生在open阶段。

对于数据库无法启动的原因大体有以下几个方面需要考虑。

1)      系统内核参数设置不当，比如当前的内核参数设置在需要增加数据库级的配置的情况下是否能够满足，或者在硬件扩容的情况下，现有的内核参数是否需要做相应的调整。举个例子，之前看到一个数据库环境中的内存为16G，但是实际上process只设置了150，很明显可以充分利用这部分资源， 在申请维护窗口重启的过程中，发现调整了process大小之后，数据库实例无法启动，根本原因就是内核参数shmmax设置过低导致。

2)      数据库参数变量设置不当，数据库参数或者变量的一些设置可能会和现有的资源使用情况冲突，在这种情况下，数据库参数的设置很可能过高或者过低，导致硬件资源的使用无法满足。比如数据库层面的process大小还是需要和系统内核参数有一个映射，设置不能太高。

我们以一个真实的案例来说明，这是我接手的一套测试环境。这是一套11gR2的环境。

当我准备连接到环境的时候，首先查看数据库的进程情况。

可以看到目前的环境存在两个数据库实例newtest和test04，在此我们需要连接newtest.

$ ps -ef|grep smon

oracle    1451     1  0 Feb02 ?        00:00:30 ora_smon_newtest

oracle    9133     1  0 Feb03 ?        00:00:58 ora_smon_test04

oracle   24734 24596  0 17:36 pts/0    00:00:00 grep smon

但是使用sqlplus登录的时候却碰到了一个非常奇怪的问题。

$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Wed Feb 17 17:36:08 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL>

按理说应该直接使用sys用户连接到了数据库实例，但是在此却显示是一个空实例。这到底是哪里出了问题呢。首先排除了ORACLE_SID大小写，乱码的问题。

查看数据库日志也没有发现任何异常信息，实例还是active的。

在此我们先卖个关子，继续往下看。

因为是测试环境，所以也可以做一些简单的尝试，于是我就尝试启动数据库实例。

Nomount阶段竟然没有报出任何的错误。

SQL> startup nomount

ORACLE instance started.

Total System Global Area 4993982464 bytes

Fixed Size                  2261808 bytes

Variable Size            1006636240 bytes

Database Buffers         3976200192 bytes

Redo Buffers                8884224 bytes

这个时候都有些怀疑是否之前的分析是正确的。

继续把实例置为mount阶段，这个时候就抛出了下面的问题。

SQL> alter database mount;

alter database mount

*

ERROR at line 1:

ORA-00205: error in identifying control file, check alert log for more info

这个时候，查看日志就是一个很好的办法，在11g中可以使用adr的方式来查看，或者使用下面的方式来直接找到日志所在目录。

SQL> show parameter background_dump_dest

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

background_dump_dest                 string      /U01/app/oracle/diag/rdbms/new

                                                 test/newtest/trace

得到的日志如下：                                                 

MMNL started with pid=16, OS id=24683

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

starting up 1 shared server(s) ...

ORACLE_BASE from environment = /DATA/app/oracle

Wed Feb 17 17:36:21 2016

alter database mount

ORA-00210: cannot open the specified control file

ORA-00202: control file: '/U01/app/oracle/fast_recovery_area/newtest/control02.ctl'

ORA-27086: unable to lock file - already in use

Linux-x86_64 Error: 11: Resource temporarily unavailable

Additional information: 8

Additional information: 1449

ORA-00210: cannot open the specified control file

ORA-00202: control file: '/U01/app/oracle/oradata/newtest/control01.ctl'

ORA-27086: unable to lock file - already in use

Linux-x86_64 Error: 11: Resource temporarily unavailable

Additional information: 8

Additional information: 1449

ORA-205 signalled during: alter database mount...

通过上面的错误信息可以很清晰看到控制文件已经被占用了。

这个时候查看数据库实例的情况，发现结果让人大跌眼镜，竟然有两个实例为newtest.

[oracle@BX_133_45 trace]$ ps -ef|grep smon

oracle    1451     1  0 Feb02 ?        00:00:30 ora_smon_newtest

oracle    9133     1  0 Feb03 ?        00:00:58 ora_smon_test04

oracle   24677     1  0 17:36 ?        00:00:00 ora_smon_newtest

oracle   24734 24596  0 17:36 pts/0    00:00:00 grep smon

那么这个问题该怎么解释呢，在Unix,Linux系统中，SID和ORACLE_HOME在一起哈希后会得到一个唯一的值作为SGA的key。

当oracle实例启动时，在操作系统上的fork进程会根据Oracle_SID来创建相关后台进程。

Oracle 11g 支持Oracle_SID的长度为12位，db_name的长度为8位。而在很早的版本中ORACLE_SID只支持4位，这也就是我们经常看到ORCL,PROD这样的数据库的一个原因吧。

在这个场景中，ORACLE_SID没有任何问题，那么仔细来品味上面的话，另外一个可能就是ORACLE_HOME了。 

我们首先把刚刚没有启动的实例先停掉，避免有更多的干扰。

查看共享内存段的情况如下，可见数据库实例还是没有受到影响。                                           

$ ipcs -m

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

key        shmid      owner      perms      bytes      nattch     status     

0x00000000 1114113    oracle     640        33554432   23                     

0x00000000 1146882    oracle     640        4982833152 23                     

0x849f1498 1179651    oracle     640        2097152    23                     

0x00000000 3211268    oracle     640        33554432   23                     

0x00000000 3244037    oracle     640        4982833152 23                     

0x9d2300b0 3276806    oracle     640        2097152    23                     

这个时候再次观察实例的smon进程，发现原来的进程依然存在。

$ ps -ef|grep smon

oracle    1451     1  0 Feb02 ?        00:00:30 ora_smon_newtest

oracle    9133     1  0 Feb03 ?        00:00:58 ora_smon_test04

oracle   24779 24596  0 17:37 pts/0    00:00:00 grep smon

再次确认ORACLE_SID

$ echo $ORACLE_SID

newtest

确认ORACLE_HOME

$ echo $ORACLE_HOME

/DATA/app/oracle/11.2.0.4

好了，我们来开始分析，

找到系统级所在的句柄，根据smon进程对应的进程号1451在/proc/1451下面，查看environ的设置情况，可以使用下面的方式来查看这个进程对应的环境变量ORACLE_HOME

$ cat /proc/1451/environ|xargs -0 -n1 |grep ORACLE_HOME

ORACLE_HOME=/U01/app/oracle/product/11.2.0.2/db_1

这个时候真相浮出水面，原来是ORACLE_HOME设置不同。

手工指定ORACLE_HOME，然后再次尝试

$ export ORACLE_HOME=/U01/app/oracle/product/11.2.0.2/db_1

$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Wed Feb 17 17:49:00 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

这个时候就达到了预期的效果

SQL> select database_role from v$database;

DATABASE_ROLE

----------------

PRIMARY

通过这个案例可以发现，在环境维护中需要遵循一定的规范，如果不严谨不规范，就会出现一些看似奇怪的问题；对于数据库实例的启动过程需要有深刻的理解，需要不断的反问自己为什么，怎么求证，能够说服自己才能让别人信服。