ORA-01102: cannot mount database in EXCLUSIVE mode

ORA-01102: cannot mount database in EXCLUSIVE mode

安装完ORACEL 10g数据库后,启动数据库时遇到ORA-01102: cannot mount database in EXCLUSIVE mode

[[email protected] ~]$ sqlplus / as sysdba
 
SQL*Plus: Release 10.2.0.1.0 - Production on Thu Apr 10 13:53:08 2014
 
Copyright (c) 1982, 2005, Oracle. All rights reserved.
 
Connected to an idle instance.
 
SQL> startup
 
ORACLE instance started.
 
Total System Global Area 5033164800 bytes
 
Fixed Size 2027672 bytes
 
Variable Size 905973608 bytes
 
Database Buffers 4110417920 bytes
 
Redo Buffers 14745600 bytes
 
ORA-01102: cannot mount database in EXCLUSIVE mode
 

查看告警日志文件,发现有ORA-09968: unable to lock file 和Linux-x86_64 Error: 11: Resource temporarily unavailable等错误

[[email protected] bdump]$ tail -20f alert_epps.log 
 
SMON started with pid=8, OS id=24482
 
RECO started with pid=9, OS id=24484
 
CJQ0 started with pid=10, OS id=24486
 
MMON started with pid=11, OS id=24488
 
Thu Apr 10 13:53:42 2014
 
starting up 1 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))‘...
 
MMNL started with pid=12, OS id=24490
 
Thu Apr 10 13:53:42 2014
 
starting up 1 shared server(s) ...
 
Thu Apr 10 13:53:42 2014
 
ALTER DATABASE MOUNT
 
Thu Apr 10 13:53:42 2014
 
sculkget: failed to lock /u01/app/oracle//product/10.2.0/db_1/dbs/lkEPPS exclusive
 
sculkget: lock held by PID: 20337
 
Thu Apr 10 13:53:42 2014
 
ORA-09968: unable to lock file
 
Linux-x86_64 Error: 11: Resource temporarily unavailable
 
Additional information: 20337
 
Thu Apr 10 13:53:42 2014
 
ORA-1102 signalled during: ALTER DATABASE MOUNT...
 

第一次遇到这种情况,于是网上搜索了一下资料,找到一篇相关文章http://blog.itpub.net/12272958/viewspace-716020,介绍了出现这种错误的三种情况:

      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错误

SQL> shutdown immediate;
 
ORA-01507: database not mounted
 
ORACLE instance shut down.
 
SQL> startup
 
ORACLE instance started.
 
Total System Global Area 5033164800 bytes
 
Fixed Size 2027672 bytes
 
Variable Size 905973608 bytes
 
Database Buffers 4110417920 bytes
 
Redo Buffers 14745600 bytes
 
ORA-00205: error in identifying control file, check alert log for more info
 

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

RECO started with pid=9, OS id=24887
 
CJQ0 started with pid=10, OS id=24889
 
MMON started with pid=11, OS id=24891
 
Thu Apr 10 14:04:05 2014
 
starting up 1 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))‘...
 
MMNL started with pid=12, OS id=24894
 
Thu Apr 10 14:04:06 2014
 
starting up 1 shared server(s) ...
 
Thu Apr 10 14:04:06 2014
 
ALTER DATABASE MOUNT
 
Thu Apr 10 14:04:06 2014
 
ORA-00202: control file: ‘/u01/app/oracle/oradata/epps/control01.ctl‘
 
ORA-27086: unable to lock file - already in use
 
Linux-x86_64 Error: 11: Resource temporarily unavailable
 
Additional information: 8
 
Additional information: 20341
 
Thu Apr 10 14:04:09 2014
 
ORA-205 signalled during: ALTER DATABASE MOUNT...
 

于是索性静下心来多了解一下这个问题,在网上查看了大量关于ORA-01102的文章。这篇博客http://blog.itpub.net/20674423/viewspace-711545对这个问题阐述得比较清晰。下面是Metalink关于ORA-01102的解释以及解决方法:

Problem Description:

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

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

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.

参考资料:

http://blog.itpub.net/12272958/viewspace-716020

http://blog.itpub.net/20674423/viewspace-711545

时间: 2024-09-30 20:38:01

ORA-01102: cannot mount database in EXCLUSIVE mode的相关文章

错误 ORA-01102: cannot mount database in EXCLUSIVE mode 的处理方法

问题描述: 在RAC环境中,想开启归档日志,其中使用 SQL> alter system set cluster_database=false scope=spfile;-->把集群修改为单实例 修改好后主节点,恢复集群双节点 SQL> alter system set cluster_database=true scope=spfile;-->把集群修改为双实例 当前数据库主节点已经open状态,查询状态是open 备节点已是shutdown状态,启动当前节点时报: ORA-01

oracle 11g rac启动报错ORA-01102: cannot mount database in EXCLUSIVE mode

启动oracle 11g rac数据库时出现以下错误,只能启动其中一个节点,另一个节点启动不了,可能是以前修改cluster_database这个参数引起的.在oralc rac架构这个参数必须设置为TRUE. 错误信息: ORA-01102: cannot mount database in EXCLUSIVE mode 解决方法: rac1节点: SQL> show parameter cluster_database; NAME                              

ORA-01102: cannot mount database in EXCLUSIVE 处理方法

今天启动rac数据库一个节点时报错了! SQL> startup mount ORACLE instance started. Total System Global Area 608174080 bytes Fixed Size 1220844 bytes Variable Size 176164628 bytes Database Buffers 427819008 bytes Redo Buffers 2969600 bytes ORA-01102: cannot mount databa

ORA 01102

因为数据库已经做了一次shutdown,在startup时出现ora-01102依然提示排他模式.那么很容易想到的就是此时数据库的共享内存没有被真正释放. 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 mem

Oracle异机恢复

RMAN异机恢复注意事项:1.RMAN 异机恢复的时候,db_name必须相同. 如果说要想改成其他的实例名,可以在恢复成功后,用nid 命令修改. 实例名的信息会记录到控制文件里,所以如果在恢复的时候,如果实例名不一致,恢复的时候会报错.2.如果恢复的路径和源库不一致,就需要在restore时用set 命令指定新位置. 并且使用switch datafile all将信息更新的到控制文件.在做duplicate的时候,RMAN 会自动根据pfile中的log_file_name_convert

转载:oracle 启动过程--oracle深入研究

Oracle数据库的启动-nomount状态深入解析 通常所说的Oracle Server主要由两个部分组成:Instance和Database.Instance是指一组后台进程(在Windows上是一组线程)和一块共享内存区域:Database是指存储在磁盘上的一组物理文件.通过Instance与Database协同,Oracle数据库才能形成一个动态的可访问关系型数据库系统.本章将由数据库如何启动与关闭入手,开始和大家一起进入Oracle数据库的国度.1.1 数据库的启动从表象来看,数据库的

ORA_ERROR大全

转自:http://blog.csdn.net/haiross/article/details/12839229 常见错误:-60 ORA00060: deadlock detected while waiting for resource 一般错误:  - 1 ORA00001: unique constraint (.) violated  -17 ORA00017: session requested to set trace event  -18 ORA00018: maximum nu

ORACLE_SID、DB_NAME、INSTANCE_NAME、DB_DOMIAN、GLOBAL_NAME区分

ORACLE_SID.DB_NAME.INSTANCE_NAME.DB_DOMIAN.GLOBAL_NAMES是Oracle中几个重要的参数,而且也比较容易混淆,下面给出这些参数的具体描述. 一.SID.ORACLE_SID: SID的全称为site identifier,Oracle_SID则为Oracle site identifier. 下面引用Tom(Thomas Kyte)的一段话来解释Oracle_SID If you're unfamiliar with the term SID

DataGuard总体结构

一.DataGuard总体结构 总体目标 1.   描述计划和非计划停机的不同因数 2.   DataGuard的主要组件 3.   物理以及逻辑DataGuard的异同 4.   建立DataGuard的好处 5.   在高可用环境下HA的用处 数据损失原因 1.   硬件与系统故障 2.   人为错误 3.   计算机病毒 4.   软件故障 5.   自然灾难 具调查表明,目前一般情况下,数据损失的主要原因是硬件故障和人为的原因而不是自然灾害等. 系统当机 计划当机 1.   系统维护:硬