天天看点

ORA-01102: cannot mount database in EXCLUSIVE mode

安装完oracel 10g数据库后,启动数据库时遇到ora-01102: cannot mount database in exclusive mode

ORA-01102: cannot mount database in EXCLUSIVE mode

查看告警日志文件,发现有ora-09968: unable to lock file 和linux-x86_64 error: 11: resource temporarily unavailable等错误

ORA-01102: cannot mount database in EXCLUSIVE mode

      a、 oracle的共享内存段或信号量没有被释放;

      b、 oracle的后台进程(如smon、pmon、dbwn等)没有被关闭;

      c、 用于锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除。

看了文章前面一部分。便武断的觉得应该是第三者情况(由于告警日志中出现

了相关信息):“用于锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除”。于是动手操作(太心急,这

毛病老是难以改变),关闭数据库实例,删除/u01/app/oracle/product/10.2.0/db_1/dbs/lkepps文件后,重新

启动数据库。结果作者的经历又在我身上重演了一次。

启动时候报ora-00205错误

ORA-01102: cannot mount database in EXCLUSIVE mode

查看告警日志,有如下错误信息:

ORA-01102: cannot mount database in EXCLUSIVE mode

problem description:

====================

you are trying to startup the database and you receive the following error:

ora-01102: 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.

problem explanation:

a database is started in exclusive mode by default. therefore, the ora-01102 error is misleading and may have occurred due to one of the following reasons:

- there is still an "sgadef<sid>.dbf" file in the "oracle_home/dbs"  directory

- the processes for oracle (pmon, smon, lgwr and dbwr) still exist

- shared memory segments and semaphores still exist even though the

database has been shutdown

- there is a "oracle_home/dbs/lk<sid>" file

search words:

=============

ora-1102, crash, immediate, abort, fail, fails, migration

solution description:

=====================

verify that the database was shutdown cleanly by doing the following:

1. verify that there is not a "sgadef<sid>.dbf" file in the directory "oracle_home/dbs".

        % ls $oracle_home/dbs/sgadef<sid>.dbf  if this file does exist, remove it.

        % rm $oracle_home/dbs/sgadef<sid>.dbf

2. verify that there are no background processes owned by "oracle"

       % ps -ef | grep ora_ | grep $oracle_sid

if background processes exist, remove them by using the unix

command "kill". for example:

     % kill -9 <rocess_id_number>

3. verify that no shared memory segments and semaphores that are owned by "oracle" still exist

% ipcs -b

if there are shared memory segments and semaphores owned by "oracle", remove the shared memory segments

        % ipcrm -m <shared_memory_id_number>

and remove the semaphores

       % ipcrm -s <semaphore_id_number>

note: the example shown above assumes that you only have one

database on this machine. if you have more than one

database, you will need to shutdown all other databases

before proceeding with step 4.

4. verify that the "$oracle_home/dbs/lk<sid>" file does not exist

5. startup the instance

solution explanation:

the "lk<sid>" and

"sgadef<sid>.dbf" files are used for locking shared memory. it

seems that even though no memory is allocated, oracle thinks memory is

still locked. by removing the "sgadef" and "lk" files you remove any

knowledge oracle has of shared memory that is in use. now the database

can start.