Thursday 16 October 2014

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


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

 [oracle@NVMBD1BZY150D00 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 16 11:01:28 2014

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

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 2.0176E+10 bytes
Fixed Size                  2237048 bytes
Variable Size            2550140296 bytes
Database Buffers         1.7583E+10 bytes
Redo Buffers               41488384 bytes
ORA-00205: error in identifying control file, check alert log for more info


In alert log file following information about error in detail.

Thu Oct 16 11:22:54 2014
MMNL started with pid=20, OS id=14441
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL                                                                                        =TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /data/oracle/app/oracle
Thu Oct 16 11:22:54 2014
ALTER DATABASE   MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/data/oracle/app/oracle/oradata/TEST/control02.ctl'
ORA-27086: unable to lock file - already in use
Linux-x86_64 Error: 11: Resource temporarily unavailable


After researching lot found articles about ORA-01102. This article elaborate on this issue more clearly. Below is the Metalink on the ORA-01102 and the solution.

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


[oracle@NVMBD1BZY150D00 dbs]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 16 13:33:05 2014

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

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 2.0176E+10 bytes
Fixed Size             2237048 bytes
Variable Size       2550140296 bytes
Database Buffers    1.7583E+10 bytes
Redo Buffers          41488384 bytes
Database mounted.
Database opened.

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.




I hope this article helped you. Your suggestions/feedback are most welcome.

Keep learning... Have a great day!!!

1 comment:

  1. This is clear copy paste from this link 'http://www.dba-oracle.com/t_ora_01102_cannot_mount_database_in_exclusive_mode.htm'.

    ReplyDelete