shutdown abort 的影响

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来关闭数据库。