数据库立即关闭,这个时候文件状态可能不一致
因为正常关闭数据库会同步校验各文件,使得重新启动的时候文件时间点一致并且不用进行崩溃恢复
若检查点信息一致,则做崩溃恢复
若检查点信息不一致(正好在更新文件头)则需要做介质恢复
这些问题都好处理,最怕的问题是这个时候系统有大量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来关闭数据库。