问题出现在已经连接的那些server process上，如果这些连接在运行长时间的查询操作，的确是要等待的。同事在进行关闭数据库操作的时候，似乎没有关闭前台应用，这样的话，原来连入的server process依然可以运行长作业。
那么，我们应该怎么使用shutdown immediate呢？在过去，笔者读过一位前辈的经验：
1) 根据对应用系统的了解，确定“先关应用，后关库”的操作顺序；
2) 通过v$transaction，确定系统中时候有“大会滚”作业存在，如果有，要联系事务的用户，进行系统外沟通；
3) 通过v$session_longops，确定系统中是否有长时间的查询动作；
4) 关闭OEM。10g之后，OEM以Web应用的方式存在，OEM与数据库的连接，也往往是阻断shutdown immediate的一个重要因素；
经过这些确认，才能进行稳妥的shutdown immediate操作。注意：shutdown immedaite虽然可以进行回滚，但是长时间hang住也可能是在进行大事务操作的回滚操作。
4、结论
最后，我们讨论一下如果已经进行shutdown immediate被hang住，从alert log中看到了进程信息怎么处理呢？
解决的方法是通过进程编号，分析进程性质和状态，逐个解决。如果是前台进程，可以考虑是应用连接断开或者加速回滚过程。如果是后台进程，可以考虑是数据库bug或者内部运行问题。