【ORA】ORA-01033，ORA-09968，ORA-01102

[oracle@oracle ~]$ imp xxxx/user file=/usr/local/src/666.dmp full=y buffer=40960000

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 29890

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