关闭

shutdown abort 的影响

810人阅读 评论(0) 收藏 举报
shutdown abort 的时候,跟kill 进程是一样的效果 
数据库立即关闭,这个时候文件状态可能不一致 
因为正常关闭数据库会同步校验各文件,使得重新启动的时候文件时间点一致并且不用进行崩溃恢复 

若检查点信息一致,则做崩溃恢复 
若检查点信息不一致(正好在更新文件头)则需要做介质恢复 

这些问题都好处理,最怕的问题是这个时候系统有大量IO,结果这样造成写的突然中断,碰巧造成文件块的逻辑坏块,那麻烦比较大一些,尤其是系统表空间的block损坏 


虽然shutdown abort 出错的几率很小,1000个人可能只有一个人碰到,但是我们还是要小心。 

正确的处理流程是,shutdown immediate ,若数据库迟迟不能down下来,在os上观察IO状况,几乎没有io的时候,另开一窗口shutdown  abort ,几乎不会出问题了




alter database archivelog;

在修改数据库为归档模式的时候,出现:ORA-00265: instance recovery required, cannot set ARCHIVELOG mode  实例需要恢复

 

原因:其实问题很简单,就是其在关闭数据库的时候使用了AROBT选项。


重新到open状态(一定要先到open状态),startup immediate关闭数据库,再启到mount状态,这时再修改归档模式:alter database archivelog;




 使用shutdown immediate 关闭数据库时,发生数据库假死的大部分原因都是因为回滚大失误造成的,所以建议你在执行此语句之前使用 alter system checkpoint;

在我们现网的环境中shutdown immediate使用是很谨慎的,需要首先停掉数据库监听器,将JOB队列参数设置成0,然后手工杀掉所有的ORACLE 用户SESSION后,在执行 alter system checkpoint 然后在 shutdown immediate。 

 

如果在执行shutdown immediate时出现假死现象,可以先用ctrl+C先取消,如果取消不了的话,就重新开一个session进去再shutdown abort

或者shutdown immediate来关闭数据库。

 



0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:139821次
    • 积分:2085
    • 等级:
    • 排名:第19024名
    • 原创:75篇
    • 转载:14篇
    • 译文:1篇
    • 评论:10条
    最新评论