Oracle ORA-01102 failure: Cannot mount database in EXCLUSIVE mode__oracle

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

This problem may be due to a power outage, the solution is

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 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 present, delete