这是个常见的错误。下面这个case讲述了如何fix.
一、提出问题
实际过程中有时我们会遇到这样的问题，当你用startup试图启动数据库时会遇到ORA-01102的报错。
我们可以在Unix下切换到Oracle的用户，执行一下oerr ora 1102便会看到有关1102的简短的描述，
如下：
$oerr ora 1102
01102, 00000, "cannot mount database in EXCLUSIVE mode"
// *Cause: Some other instance has the database mounted exclusive or shared.
// *Action: Shutdown other instance or mount in a compatible mode
看了这个1102的简短的解释你一定有些迷惑，因为它有一些的误导性。如下我便来分析一下问题产生的原因，并给出解决的办法。
二、分析原因
当你启动数据库遇到1102报错时，之前的数据库的down操作一般都不是正常完成的，或由于一些异常使Oracle在操作系统中残留一些内存结构，Pmon等一几个进程依然存在等原因使Oracle误认
为Instance依然在运行着，所以库就没有启动，具体说来大体原因有如下几个：
1、pmon、smon、lwgw及dbwr这些后台进程依然存在着
2、Oracle开辟的共享内存没有释放掉
3、"lk<sid>" and "sgadef<sid>.dbf"这两个用于锁内存的文件存在着。
三、解决问题
知道了原因，解决起来就简单多了，办法如下：
1、看一下"lk<sid>" and "sgadef<sid>.dbf"这两个文件是不是存在着，如果存在将其删掉。
oracle$cd $ORACLE_HOME/dbs
oracle$ls -l sgadef<sid>.dbf
如果存在删掉它
oracle$rm sgadef<sid>.dbf
oracle$ls -l lk<sid>
如果存在删掉它
oracle$rm lk<sid>
2、看是不是有后台进程存在了
oracle$ps -ef | grep ora_ | grep $ORACLE_SID
如果有pmon这些后台进程的残留，kill -9掉它
oracle$kill -9 pid
3、看一下oracle的共享内存段及信号集(semaphores)是不是还存在着
1)清共享内存段
oracle$ipcs -m --显示一下,看owner是Oracle用户的
oracle$ipcrm -m <Shared_Memory_ID>
2)清信号集
oracle$ipcs -s --显示一下,看owner是Oracle用户的
oracle$ipcrm -s <Semaphore_ID>
分类： Linux
某系统突然掉电，系统启动后发现Oracle无法启动。启动时报如下错误：
ORA-01102 cannot mount database in EXCLUSIVE mode
出现1102错误可能有以下几种可能：
一、在HA系统中，已经有其他节点启动了实例，将双机共享的资源（如磁盘阵列上的裸设备）占用了；
二、说明Oracle被异常关闭时，有资源没有被释放，一般有以下几种可能，
1、 Oracle的共享内存段或信号量没有被释放；
2、 Oracle的后台进程（如SMON、PMON、DBWn等）没有被关闭；
3、 用于锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除。
首先，虽然我们的系统是HA系统，但是备节点的实例始终处在关闭状态，这点通过在备节点上查数据库状态可以证实。
其次、是因系统掉电引起数据库宕机的，系统在接电后被重启，因此我们排除了第二种可能种的1、2点。最可疑的就是第3点了。
总结：
当发生1102错误时，可以按照以下流程检查、排错：
- 如果是HA系统，检查其他节点是否已经启动实例；
- 检查Oracle进程是否存在，如果存在则杀掉进程；
- 检查信号量是否存在，如果存在，则清除信号量；
- 检查共享内存段是否存在，如果存在，则清除共享内存段；
- 检查锁内存文件lk<sid>和sgadef<sid>.dbf是否存在，如果存在，则删除。
