Import: Release 10.2.0.5.0 - Production on Thu Apr 19 14:01:24 2018
Copyright (c) 1982, 2007, Oracle. All rights reserved.
IMP-00058: ORACLE error 1033 encountered
ORA-01033: ORACLE initialization or shutdown in progressUsername:
Password:
用sqlplus进入到数据库中，查看数据库的状态，发现是nomount模式
SQL> select instance_name ,status from v$instance;
SQL> INSTANCE_NAME STATUS ---------------- ------------ orcl STARTD
尝试启动数据库
SQL>ALTER DATABASE MOUNT;
结果报错：
ORA-01102: cannot mount database in EXCLUSIVE mode
结果上alert日志里看到了相关的报错：
ALTER DATABASE MOUNT Thu Apr 19 14:05:59 CST 2018 sculkget: failed to lock /opt/app/oracle/product/10.2//dbs/lkORCL exclusive sculkget: lock held by PID: 1745 Thu Apr 19 14:05:59 CST 2018 ORA-09968: unable to lock file Linux-x86_64 Error: 11: Resource temporarily unavailable Additional information: 1745 Thu Apr 19 14:05:59 CST 2018 ORA-1102 signalled during: ALTER DATABASE MOUNT... ORA-09968: unable to lock file Linux-x86_64 Error: 11: Resource temporarily unavailable
网上找到了相关的解释：
http://blog.itpub.net/12272958/viewspace-716020
metadata这样解释的：
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.
于是我尝试关闭数据库，
SQL> SHUTDOWN IMMEDIATE;数据库关闭正常
但是查看后台进程：
发现所有的后台进程还在
ps -ef | grep ora_ oracle 29890 1 0 14:13 ? 00:00:00 ora_pmon_orcl oracle 29892 1 0 14:13 ? 00:00:00 ora_psp0_orcl oracle 29894 1 0 14:13 ? 00:00:00 ora_mman_orcl oracle 29896 1 0 14:13 ? 00:00:07 ora_dbw0_orcl oracle 29898 1 0 14:13 ? 00:00:05 ora_lgwr_orcl oracle 29900 1 0 14:13 ? 00:00:00 ora_ckpt_orcl oracle 29902 1 0 14:13 ? 00:00:00 ora_smon_orcl oracle 29904 1 0 14:13 ? 00:00:00 ora_reco_orcl oracle 29906 1 0 14:13 ? 00:00:00 ora_cjq0_orcl oracle 29908 1 0 14:13 ? 00:00:02 ora_mmon_orcl oracle 29910 1 0 14:13 ? 00:00:00 ora_mmnl_orcl oracle 29912 1 0 14:13 ? 00:00:00 ora_d000_orcl oracle 29914 1 0 14:13 ? 00:00:00 ora_s000_orcl oracle 29934 1 0 14:13 ? 00:00:00 ora_qmnc_orcl oracle 29955 1 0 14:13 ? 00:00:00 ora_q000_orcl oracle 29957 1 0 14:13 ? 00:00:00 ora_q001_orcl oracle 30268 1 0 14:51 ? 00:00:00 ora_j000_orcl oracle 30275 30184 0 14:53 pts/1 00:00:00 /bin/bash -c ps -ef | grep ora_ oracle 30277 30275 0 14:53 pts/1 00:00:00 grep ora_
根据上面的博客内容，断定是第二种问题，于是强制kill掉pmon进程
[oracle@oracle ~]$ ps -ef | grep pmon oracle 29890 1 0 14:13 ? 00:00:00 ora_pmon_orcl oracle 30282 29844 0 14:55 pts/1 00:00:00 grep pmon
[oracle@oracle ~]$ kill -9 29890kill掉pmon进程后，所有的进程会慢慢结束关闭，再次查看发现已经全部关闭了
这次再重启数据库
sqlplus / as sysdba SQL> startup最后启动成功了，数据库彻底开启
SQL> select instance_name ,status from v$instance; INSTANCE_NAME STATUS ---------------- ------------ orcl OPEN
参考：
https://www.cnblogs.com/kerrycode/p/3656655.html
http://blog.itpub.net/12272958/viewspace-716020