利用ipcrm清除数据库crash后没有释放的内存段

某测试库，开发报告无法连接使用，登陆进该server，首先输入ps –ef | grep ORACLE_SID发现该instance没有启动，

查看alertlog，日志显示11月28号0:00db有过一次日志切换，10分钟后开始出现7445错误，过一会dbw0进程dead，然后PMON进程terminated，此时数据库crash；

紧接着是启动数据库，版本为10.2.0.4，在open阶段报告错误

ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option

如此反复了几次数据库始终没有正常启动

仅从以上错误很容易让人联想到是数据库升级没有成功，需要升级一下数据字典即可；但是alertlog并没有数据库曾经升级过的记录，而且此套数据库有好几个公司维护，也很难求证此前数据库有过什么重大变更。

正在纠结于要不要根据提示升级数据字典时，一条重要线索出现，该数据库原本是10.2.0.5的，自从crash后才有人试图以10.2.0.4的版本将其启动，怪不得会有上述错误。

重新设置LD_LIBRARY_PATH/ORACLE_HOME为10.2.0.5，以sysdba登陆，应该显示connected to a idle instance才对，可此次只提示session connected；

输入startup，报告ORA-03113: end-of-file on communication channel；

输入shutdown immediate，报告ORA-01033: ORACLE initialization or shutdown in progress

再次运行ps –ef | grep ORACLE_SID，后台进程并没有启动，运行ipcs –m | grep oracle返回10条记录，而ps –ef | grep pmon | -V “grep”返回9条，原因终于找到了。

数据库crash的时候，对应的共享内存段并没有被OS及时释放，才导致既无法启动又无法关闭的怪现象。

解决办法：ipcs –m | grep oracle找到对应的nattach为0的记录，然后运行ipcrm –m id即可释放对应的共享内存段；此时再次登陆，敲入startup即可正常启动数据库，版本10.2.0.5

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15480802/viewspace-712517/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15480802/viewspace-712517/