Nomount案例两则
在创建数据库时，如果在这一步骤就出现问题,那么通常可能是系统配置（如内核参数等）存在问题，你需要检查是否分配了足够的系统资源等。
案例一
以下是一个启动到nomount状态可能会遇到的常见错误：
$ export ORACLE_SID=julia
$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Wed Feb 28 09:55:24 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to an idle instance.
SQL> startup nomount;
ORA-00600: internal error code, arguments: [OSDEP_INTERNAL], [], [], [], [], [], [], []
ORA-27302: failure occurred at: skgpwreset1
ORA-27303: additional information: invalid shared ctx
ORA-27146: post/wait initialization failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpsemsper
（注意：ORA-00600是Oracle内部错误的一个集合，其具体含义要看后面的参数提示，数据库出现ORA-00600错误应当引起DBA的充分重视，很多600错误可能会导致数据损失。）
在Nomount状态就出现问题，通常是系统问题，OS类错误一般说明是系统资源不足，这在Linux/Unix下和信号量等参数设置有关，多出现在同一主机运行多个数据库实例的情况（在Solaris上需要修改/etc/system文件中的内核参数，重起系统后修改生效）。
在这个错误提示中，600错误的第一个参数是OSDEP_INTERNAL，我们大致可以猜测到这是一个OS Dependent/Internal Error。很多Oracle的提示可以根据缩写猜到大致的含义，但是如果是错误号那就要依赖Oracle的文档来寻找答案。
此外错误提示OS相关的操作是：semget 。这是一个标准的操作系统调用，通过手册可以获得其含义信息，可以看到这是和信号量相关的系统调用：
bogon:Eygle eygle$ man semget
SEMGET(2) BSD System Calls Manual SEMGET(2)
NAME
semget -- obtain a semaphore id
SYNOPSIS
#include <sys/sem.h>
int
semget(key_t key, int nsems, int semflg);
具体就可以判断，问题和操作系统的内核参数设定有关，可能是信号量设置不足导致的，根据不同的操作系统找到相应的参数，调整之后即可解决问题。
这个案例给我们的提示是：应该认真细致的阅读每一行错误提示信息，往往从直接的提示就可以找到真实的错误原因。
案例二
在另外一个客户现场，遭遇过另外一个案例，当时客户的服务器异常断电，当系统重新启动后，数据库无法启动（提示：重启主机对于DBA来说应当极其慎重，很多隐藏的故障可能在重启时爆发出来，在没有做好充分准备之前，不要贸然从事）。
数据库的症状是，启动主机到Nomount状态后，后台进程会立即将实例中止，也就是说数据库实例都无法稳定创建，告警日志文件信息如下：
Mon Dec 3 14:24:30 2007
Errors in file /oraclehx/app/admin/sxlss/bdump/sxlss_pmon_360454.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
PSP0 started with pid=3, OS id=422106
MMAN started with pid=4, OS id=303332
DBW0 started with pid=5, OS id=299324
.........
SMON started with pid=11, OS id=278882
RECO started with pid=12, OS id=319898
CJQ0 started with pid=13, OS id=295404
MMON started with pid=14, OS id=303428
MMNL started with pid=15, OS id=438776
Mon Dec 3 14:24:33 2007
PSP0: terminating instance due to error 472
Instance terminated by PSP0, pid = 422106
综合前面介绍的知识，如果实例都无法创建，那通常是在OS方面存在问题，这些问题在系统重新启动后才体现出来，经过检查，发现客户系统是AIX操作系统补丁应用不完全，最后导致了数据库无法启动，应用完整的系统补丁后，数据库恢复正常：
instfix -i|grep ML
All filesets for 5.3.0.0_AIX_ML were found.
All filesets for 5300-01_AIX_ML were found.
All filesets for 5300-02_AIX_ML were found.
All filesets for 5300-03_AIX_ML were found.
All filesets for 5300-04_AIX_ML were found.
All filesets for 5300-05_AIX_ML were found.
Not all filesets for 5300-06_AIX_ML were found.
这个案例给我们的经验是：当进行OS补丁应用时一定要认真确认，对关键补丁应当进行服务器重启验证，不能掉以轻心。
