一台测试数据库出现故障,检查发现数据库处于STARTED状态
ALTER DATABASE MOUNT;
ORA-01102: cannot mount database in EXCLUSIVE mode
检查报警日志,发现如下错误
ALTER DATABASE MOUNT
..
sculkget: failed to lock .. lkEPPS exclusive
sculkget: lock held by PID: ..
..
ORA-09968: unable to lock file
Linux-x86_64 Error: 11: Resource temporarily unavailable
Metalink上面的解决方法如下:
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.dbf" file in the directory
"ORACLE_HOME/dbs".
% ls $ORACLE_HOME/dbs/sgadef.dbf
If this file does exist, remove it.
% rm $ORACLE_HOME/dbs/sgadef.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
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
and remove the semaphores
% ipcrm -s
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" file does not exist
5. Startup the instance
Solution Explanation:
=====================
The "lk" and "sgadef.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.
参考上面的步骤
关掉数据库
shutdown immediate
ps -ef | grep ora_ | grep $ORACLE_SID
kill -9
删除dbs下面的共享内存
rm lk<$ORACLE_SID >
再次启动数据库,恢复正常
ALTER DATABASE MOUNT;
ORA-01102: cannot mount database in EXCLUSIVE mode
检查报警日志,发现如下错误
ALTER DATABASE MOUNT
..
sculkget: failed to lock .. lkEPPS exclusive
sculkget: lock held by PID: ..
..
ORA-09968: unable to lock file
Linux-x86_64 Error: 11: Resource temporarily unavailable
Metalink上面的解决方法如下:
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.dbf" file in the directory
"ORACLE_HOME/dbs".
% ls $ORACLE_HOME/dbs/sgadef.dbf
If this file does exist, remove it.
% rm $ORACLE_HOME/dbs/sgadef.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
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
and remove the semaphores
% ipcrm -s
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" file does not exist
5. Startup the instance
Solution Explanation:
=====================
The "lk" and "sgadef.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.
参考上面的步骤
关掉数据库
shutdown immediate
ps -ef | grep ora_ | grep $ORACLE_SID
kill -9
删除dbs下面的共享内存
rm lk<$ORACLE_SID >
再次启动数据库,恢复正常
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26506993/viewspace-2127223/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26506993/viewspace-2127223/