 |
|
ORA-01102: cannot mount database in exclusive mode tips
Oracle Error Tips by Donald Burleson(S. Karam)
|
The Oracle docs note this on the
ora-01102 error:
- ORA-01102
cannot mount database in EXCLUSIVE mode
- Cause:
Some other instance has the database mounted exclusive or shared.
- Action:
Shut down the other instance or mount in a compatible mode.
ORA-01102 occurs when you are
mounting (opening) a database, typically because another instance is already
opened in parallel (exclusive) mode.
To resolve ORA-01102, you should
try opening the base, which causing the error, in parallel mode after shutting
down other instances. If these steps leave ORA-01102 unresolved, you may
need to try restarting OracleService<SID>
Oracle DBA
Forums contains a good explanation of how ORA-01102 may also be thrown
under false pretenses:
Question:
Chris Pena asked what the
following error regards
SQL> startup force pfile='/apps/oracle/product/10.2.0/db_1/dbs/inittest01.ora'
ORACLE instance started.
Answer (by Donald Burleson):
The docs note:
ORA-01102: cannot mount database in exclusive mode
Cause: An instance tried to mount the database in
exclusive mode, but some other instance has already
mounted the database in exclusive or parallel mode.
Action: Either mount the database in parallel mode or
shut down all other instances before mounting the
database in exclusive mode.
The ORA-01102 is a "false" error in this regard
(assuming that you are not using data guard), and this
note may be helpful:
********************************
http://www.orafaq.com/forum/t/40030/0/
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
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.
POSSIBLE SOLUTION:
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 <Process_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
|