Oracle shutdown immediate关不掉——一次排坑实录Oracle执行shutdown immediate半天关不掉。监控IO发现只有控制文件在读写其他数据文件全部静默。最终强制关库重启后一切正常。这个案例值得记录因为关不掉比打不开更让人慌。文章目录Oracle shutdown immediate关不掉——一次排坑实录背景一、shutdown immediate卡住了二、监控IO发现异常三、判断继续等还是强杀四、强制关库五、验证业务六、复盘为什么卡住了七、几点经验背景某天运维通知配合云厂商做服务器降配——内存从64G降到32GCPU也相应减少。需要先把数据库停掉再操作。数据库是Oracle 11g跑了几年数据量不大几百GB平时运行正常。计划很简单停应用 → shutdown immediate → 等云厂商降配 → 启动数据库 → 启动应用。前三步出了问题。一、shutdown immediate卡住了SQLshutdownimmediate;敲完回车等了5分钟没反应。正常情况下这个库shutdown最多两三分钟。又等了10分钟还是没有返回。光标就停在那儿什么都不输出。shutdown immediate的行为是不让新会话登录等活跃事务提交或回滚把buffer cache里的脏块写盘checkpoint关闭所有文件退出如果卡住通常是第2步或第3步。要么有大事务在回滚要么脏块太多写不完。二、监控IO发现异常开另一个终端用iostat看磁盘IOiostat-x25发现只有控制文件所在的磁盘有IO活动数据文件、redo日志、归档日志全部静默。又查了Oracle的等待事件selectevent,wait_class,count(*)fromv$sessiongroupbyevent,wait_classorderbycount(*)desc;等待事件显示的是control file sequential read和control file parallel write反复出现。这个现象说明checkpoint已经做完了——数据文件没有IO就是证据脏块已经写完了shutdown在等其他东西——不是IO瓶颈是某个内部流程卡住了控制文件在shutdown immediate期间被反复读写这是Oracle在做检查点推进和SCN更新。正常情况下这个过程很快但如果实例状态有点脏比如有大事务还没清理完或者SMON在后台做事务恢复这个过程就会反复刷控制文件。三、判断继续等还是强杀两个选择继续等——不确定要等多久可能是几分钟也可能是几小时。而且降配窗口有时间限制不能无限等下去。shutdown abort——强制关库不等了。风险是实例恢复instance recovery需要时间但Oracle的崩溃恢复机制是成熟的。想了想决定强杀。理由checkpoint已经完成了数据文件没有IOredo日志也是静默的说明没有活跃事务在产生redo唯一的风险是SMON可能还在回滚某些东西但重启后SMON会继续做不丢数据四、强制关库SQLshutdownabort;ORACLE instance shut down.秒关。然后启动SQLstartup;ORACLE instance started.Total SystemGlobalArea xxx bytesFixedSize xxx bytes Variable Size xxx bytesDatabaseBuffers xxx bytes Redo Buffers xxx bytesDatabasemounted.Databaseopened.启动过程中alert日志里可以看到SMON在做实例恢复instance recoverySMON: enabling cache recovery SMON: enabling tx recovery Completed crash recovery at ... (scn ...)整个过程十几秒没有报错。五、验证业务数据库打开后检查了一下selectstatusfromv$instance;STATUS------------OPENselectcount(*)fromv$recover_file;COUNT(*)----------0实例状态OPEN没有需要恢复的文件。通知应用启动业务验证正常。六、复盘为什么卡住了事后分析最可能的原因降配前服务器资源已经开始被限制了。云厂商在窗口期之前可能已经做了部分资源限制比如IOPS上限降低导致Oracle在做最后的清理工作时控制文件的IO变慢。shutdown immediate要反复更新控制文件中的检查点SCN在IO受限的情况下就卡在那里了。加上shutdown immediate本身是一个同步阻塞操作——它不告诉你进度你也不知道它卡在哪一步只能干等。七、几点经验1.shutdown immediate卡住不要慌先看IO。用iostat或v$session_wait看等待在哪里。如果数据文件有IO说明checkpoint还在做可以等。如果只有控制文件有IO大概率是内部清理工作可以考虑shutdown abort。2.shutdown abort没有想象中那么可怕。很多人一听abort就怕数据丢失。实际上Oracle的WALWrite Ahead Logging机制保证了只要redo日志没坏shutdown abort后重启SMON会自动做前滚roll forward和回滚rollback数据不会丢。3. 维护前提前做一次checkpoint。altersystemcheckpoint;altersystem switch logfile;手动触发一次checkpoint和日志切换把脏块提前刷盘。这样shutdown immediate时需要做的工作量会小很多。4. 给shutdown加个超时意识。如果5分钟还没关掉不要再傻等了。去看等待事件判断是在做有用的事还是在空转。相关阅读《Oracle数据库无备份强制恢复SCN不一致、oradebug与ORA-600[2662]》《Oracle Undo回滚段损坏修复用系统表空间绕过损坏的undo》《Oracle Redo日志损坏恢复_allow_resetlogs_corruption与open resetlogs》