【ORA】ORA01033，ORA09968，ORA01102

[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

网上找到了相关的解释：

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