ora-01102/ora-01507

Ora-01102:cannot mount Database in EXCLUSIVE mode

Ora-01507:database not mounted

Source Documents

The following error occurred while you were in the startup database today:

Sql> Conn/as SYSDBA

Connected to a idle instance.

Sql> Startup

ORACLE instance started.

Total System Global area 276824064 bytes

Fixed Size 778736 bytes

Variable Size 137371152 bytes

Database buffers 138412032 bytes

Redo buffers 262144 bytes

Ora-01102:cannot mount Database in EXCLUSIVE mode

sql> shutdown Immediate

Ora-01507:database not mounted

ORACLE instance shut down.

Google, the discovery is caused by the lk<sid> file, the file is located under Oralce_home under the DBS directory, immediately check the file:

[Root@qa-oracle dbs]# fuser-u LKNDMSQA

lkndmsqa:6666 (Oracle) 6668 (Oracle) 6670 (Oracle) 6672 (Oracle) 6674 (Oracle) 6676 (Oracle) 6678 (Oracle) 6680 (ORAC Le) 6690 (Oracle) 6692 (Oracle) 6694 (Oracle) 6696 (Oracle) 6737 (Oracle) 6830 (Oracle)

Sure enough, the file was not released and killed with the Fuser command:

[Root@qa-oracle dbs]# fuser-k LKNDMSQA

lkndmsqa:6666 6668 6670 6672 6674 6676 6678 6680 6690 6692 6694 6696 6737 6830

[Root@qa-oracle dbs]# fuser-u LKNDMSQA

And then:

Sql> Startup

ORACLE instance started.

Total System Global area 276824064 bytes

Fixed Size 778736 bytes

Variable Size 137371152 bytes

Database buffers 138412032 bytes

Redo buffers 262144 bytes

Database mounted.

Database opened.

Sql>

The database was successfully open.

More detailed information about this error is as follows: Original link: http://www.hellodba.com/cases/case-unexception_down.htm

An example of failure to start a problem after the database is shut down abnormally

Author: fuyuncat

Source: www.HelloDBA.com

A system suddenly drops power and the system starts to discover that Oracle cannot start. Start times the following error:

ORA-01102 cannot mount database in EXCLUSIVE mode

A 1102 error can occur in the following ways:

First, in the HA system, there are already other nodes to start the instance, the resources shared by the two machines (such as the bare devices on the disk array) occupied;

Second, that the Oracle was abnormally closed, there are resources are not released, generally have the following several possible,

1. Oracle's shared memory segment or signal volume is not released;

2, Oracle background process (such as Smon, Pmon, DBWN, etc.) has not been closed;

3. Lk<sid> and SGADEF<SID>.DBF files for lock memory are not deleted.

First of all, although our system is an HA system, the instance of the standby node is always in the shutdown state, which can be verified by checking the database state on the standby node.

Secondly, because the system lost electricity caused database downtime, the system was restarted after the power, so we ruled out the second possible species of 1, 2 points. The most suspicious is the 3rd.

Check $oracle_home/dbs directory:

$ cd $ORACLE _home/dbs

$ ls sgadef*

sgadef* not found

$ ls lk*

lkORA92

Sure enough,,lk<sid> file has not been deleted. Remove it

$ RM lk*

Then start the database successfully.

If you suspect that shared memory has not been freed, you can view it with the following command:

$ipcs-mop

IPC status From/dev/kmem as Thu June 6 14:41:43 2006

T ID KEY MODE OWNER GROUP nattch cpid lpid

Shared Memory:

M 0 0x411c29d6--rw-rw-rw-root Root 0 899 899

M 1 0x4e0c0002--rw-rw-rw-root root 2 899 901

M 2 0x4120007a--rw-rw-rw-root root 2 899 901

M 458755 0x0c6629c9--rw-r-----root sys 2 9113 17065

M 4 0x06347849--rw-rw-rw-root root 1 1661 9150

M 65541 0xFFFFFFFF--rw-r--r--Root 0 1659 1659

M 524294 0x5e100011--rw-------root root 1 1811 1811

M 851975 0x5fe48aa4--rw-r-----Oracle Oinstall 66 2017 25076

It then clears the shared memory segment by its ID number:

$ipcrm –m 851975

For semaphores, you can use the following command to view:

$ ipcs-sop

IPC status From/dev/kmem as Thu June 6 14:44:16 2006

T ID KEY MODE OWNER GROUP

Semaphores:

S 0 0x4f1c0139--ra-------root root

... ...

S-0x6c200ad8--ra-ra-ra-root root

S-0x6d200ad8--ra-ra-ra-root root

s 0x6f200ad8--ra-ra-ra-root Root

s 0xFFFFFFFF--ra-r--r--root root

S-0x410c05c7--ra-ra-ra-root root

s 0x00446f6e--ra-r--r--root root

s 0x00446f6d--ra-r--r--root root

s 0x00000001--ra-ra-ra-root Root

s 45078 0x67e72b58--ra-r-----Oracle Oinstall

The semaphore ID is used to clear the semaphore with the command:

$IPCRM-S 45078

If the Oracle process is not closed, use the command to locate the Oracle process that exists:

$ ps-ef|grep ora

Oracle 29976 1 0 June 22? 0:52 Ora_dbw0_ora92

Oracle 29978 1 0 June 22? 0:51 Ora_dbw1_ora92

Oracle 5128 1 0 June 5? 0:00 Oracleora92 (Local=no)

... ...

And then use the kill-9 command to kill the process.

$kill-9 <PID>

Summarize:

When a 1102 error occurs, the following process can be used to check, debug:

1. If the HA system, check whether the other node has started the instance;

2. Check whether the Oracle process exists and kill the process if it exists;

3. Check whether the semaphore exists, if it exists, then clear the semaphore;

4. Check whether the shared memory segment exists, and if so, clear the shared memory segment;

5. Check the lock memory file lk<sid> and SGADEF<SID>.DBF exists, if it exists, delete.

The database was successfully open.

Two. When Oracle is abnormally closed, resources are not released, and there are several possibilities,

1. Oracle's shared memory segment or signal volume is not released;

2, Oracle background process (such as Smon, Pmon, DBWN, etc.) has not been closed;

3. Lk<sid> and SGADEF<SID>.DBF files for lock memory are not deleted.

First of all, although our system is an HA system, the instance of the standby node is always in the shutdown state, which can be verified by checking the database state on the standby node.

Secondly, because the system lost electricity caused database downtime, the system was restarted after the power, so we ruled out the second possible species of 1, 2 points. The most suspicious is the 3rd.

Check $oracle_home/dbs directory:

$ cd $ORACLE _home/dbs

$ ls sgadef*

sgadef* not found

$ ls lk*

lkORA92

Sure enough,,lk<sid> file has not been deleted. Remove it

$ RM lk*

Then start the database successfully.

Three. The following error may also occur

Ora-00205:error in identifying control file, check alert log for more info

There is a case of this error is not added in the environment variable Nls_lang, you must add this sentence.

Export Nls_lang=american_china. Zhs16gbk