安裝完ORACEL 10g數據庫后,啟動數據庫時遇到ORA-01102: cannot mount database in EXCLUSIVE mode
[oracle@DB-Server ~]$ 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等錯誤
[oracle@DB-Server 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:
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.
參考資料：
http://blog.itpub.net/12272958/viewspace-716020
http://blog.itpub.net/20674423/viewspace-711545