報錯現象：
數據庫報出 ORA-01102 錯誤，無法 mount
[oracle@edbjr2p2 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Wed Jan 25 02:38:03 2017
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SYS @ PROD4 >startup
ORACLE instance started.
Total System Global Area 941600768 bytes
Fixed Size 1348860 bytes
Variable Size 549456644 bytes
Database Buffers 385875968 bytes
Redo Buffers 4919296 bytes
ORA-01102: cannot mount database in EXCLUSIVE mode
SYS @ PROD4 >alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01102: cannot mount database in EXCLUSIVE mode
查看日誌：
大概意思爲文件被佔用，無法鎖定（最後發現報錯關係到一個文件和一個進程，就是日誌裏標出的兩行）
[oracle@edbjr2p2 ~]$ tail -10 /u01/app/oracle/diag/rdbms/prod4/PROD4/trace/alert_PROD4.log
Wed Jan 25 03:07:39 2017
MMNL started with pid=16, OS id=20451
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
Wed Jan 25 03:07:39 2017
ALTER DATABASE MOUNT
sculkget: failed to lock /u01/app/oracle/product/11.2.0/db_1/dbs/lkPROD4 exclusive
sculkget: lock held by PID: 17127
ORA-09968: unable to lock file
Linux Error: 11: Resource temporarily unavailable
Additional information: 17127
ORA-1102 signalled during: ALTER DATABASE MOUNT...
查報錯原因：
通過訪問多個技術大牛的博客找到問題原因和解決方法，以下Metalink的內容就摘自他們博客，裏邊描述了的問題原因和解決方法。其中下文第3條我覺得如果主機有多個實例並且都屬於Oracle用戶的話可能不可以直接這麼操做（適合單實例環境），不排除我的理解有偏差，如果主機有多個實例請先驗證！：
Metalink 原文如下：
analysis：
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.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" 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.dbf" file in the directory
"ORACLE_HOME/dbs".
% ls $ORACLE_HOME/dbs/sgadef.dbf
If this file does exist, remove it.
% rm $ORACLE_HOME/dbs/sgadef.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
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
and remove the semaphores
% ipcrm -s
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" file does not exist
5. Startup the instance
Solution Explanation:
=====================
The "lk" and "sgadef.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.
解決步驟：
先查看dbs目錄下文件情況：
發現有lkPROD4 文件（其中PROD4爲我的實例名，上文內容所描述爲要刪除 lk{$ORACLE_SID} ，也就是lk+實例名的文件）
[oracle@edbjr2p2 ~]$ cd $ORACLE_HOME/dbs
[oracle@edbjr2p2 dbs]$ ll
-rw-r----- 1 oracle oinstall 24 Oct 14 2014 lkEMREP
-rw-r----- 1 oracle oinstall 24 Oct 14 2014 lkPROD4
[oracle@edbjr2p2 dbs]$ rm lkPROD4 #刪除lkPROD4 文件
SYS @ PROD4 >startup mount #嘗試打開數據庫
ORACLE instance started.
Total System Global Area 941600768 bytes
Fixed Size 1348860 bytes
Variable Size 549456644 bytes
Database Buffers 385875968 bytes
Redo Buffers 4919296 bytes
ORA-00205: error in identifying control file, check alert log for more info #此時報出了另一個錯誤，先彆着急，咱照上文內容
一步步排查 ，先關閉
SYS @ PROD4 >shu immediate
ORA-01507: database not mounted
ORACLE instance shut down.
[oracle@edbjr2p2 ~]$
ps -ef |grep ora_ |grep PROD4
oracle 17109 1 0 Jan24 ? 00:00:00 ora_pmon_PROD4
oracle 17111 1 0 Jan24 ? 00:00:00 ora_psp0_PROD4
oracle 17113 1 0 Jan24 ? 00:00:18 ora_vktm_PROD4
oracle 17117 1 0 Jan24 ? 00:00:00 ora_gen0_PROD4
oracle 17119 1 0 Jan24 ? 00:00:00 ora_diag_PROD4
oracle 17121 1 0 Jan24 ? 00:00:00 ora_dbrm_PROD4
oracle 17123 1 0 Jan24 ? 00:00:04 ora_dia0_PROD4
oracle 17125 1 0 Jan24 ? 00:00:10 ora_mman_PROD4
oracle 17127 1 0 Jan24 ? 00:00:01 ora_dbw0_PROD4
oracle 17129 1 0 Jan24 ? 00:00:00 ora_lgwr_PROD4
oracle 17131 1 0 Jan24 ? 00:00:04 ora_ckpt_PROD4
oracle 17133 1 0 Jan24 ? 00:00:01 ora_smon_PROD4
oracle 17135 1 0 Jan24 ? 00:00:00 ora_reco_PROD4
oracle 17137 1 0 Jan24 ? 00:00:02 ora_mmon_PROD4
oracle 17139 1 0 Jan24 ? 00:00:04 ora_mmnl_PROD4
oracle 17141 1 0 Jan24 ? 00:00:00 ora_d000_PROD4
oracle 17143 1 0 Jan24 ? 00:00:00 ora_s000_PROD4
oracle 17244 1 0 Jan24 ? 00:00:00 ora_qmnc_PROD4
oracle 17298 1 0 Jan24 ? 00:00:00 ora_q001_PROD4
oracle 17330 1 0 Jan24 ? 00:00:01 ora_cjq0_PROD4
oracle 17383 1 0 Jan24 ? 00:00:00 ora_smco_PROD4
oracle 17743 1 0 Jan24 ? 00:00:00 ora_q002_PROD4
oracle 20934 1 0 03:43 ? 00:00:00 ora_w000_PROD4
這一步看見裏一個進程，其進程號和數據庫日誌中記錄的PID是相同的，因此判斷此進程有佔用。殺掉該進程：
[oracle@edbjr2p2 ~]$ kill -9 17127
再次嘗試啓動數據庫：
SYS @ PROD4 >startup mount
ORACLE instance started.
Total System Global Area 941600768 bytes
Fixed Size 1348860 bytes
Variable Size 549456644 bytes
Database Buffers 385875968 bytes
Redo Buffers 4919296 bytes
Database mounted.
SYS @ PROD4 >alter database open ;
Database altered.
SYS @ PROD4 >
至此數據庫已正常打開。問題的關鍵如文中Metalink內容描述，一下爲主要參考的兩個博文，較詳細解釋的報錯原因和解決方法，供大家擴展學習。
參考博客鏈接 ：http://www.cnblogs.com/kerrycode/p/3656655.html
參考博客鏈接2：http://blog.csdn.net/lzwgood/article/details/26368323