今天关闭一台问题数据库时，出现了这个问题。

用SYS执行SHUTDOWN IMMEDIATE命令后，数据库没有反应。

SQL> SHUTDOWN IMMEDIATE

由于解决下班时间，没有再进行处理，就让Oracle自己去关闭了。没想到第二天早上发现，SHUTDOWN IMMEDIATE方式仍然没有关闭数据库，这个命令执行时间已经超过了12个小时，检查alert文件发现信息如下：

Tue Jun 10 17:02:41 2008
Starting background process EMN0
EMN0 started with pid=16, OS id=15734
Tue Jun 10 17:02:41 2008
Shutting down instance: further logons disabled
Tue Jun 10 17:02:41 2008
Stopping background process CJQ0
Tue Jun 10 17:02:41 2008
Stopping background process MMNL
Tue Jun 10 17:02:42 2008
Stopping background process MMON
Tue Jun 10 17:02:43 2008
Shutting down instance (immediate)
License high water mark = 44
Tue Jun 10 17:02:43 2008
Stopping Job queue slave processes
Tue Jun 10 17:02:43 2008
Job queue slave processes stopped
All dispatchers and shared servers shutdown
Tue Jun 10 17:02:50 2008
Process OS id : 15693 alive after kill
Errors in file /opt/ora10g/admin/test08/udump/test08_ora_15629.trc

对应的trace文件中也没有发现什么特别之处：

[oracle@yans1 bdump]$ more /opt/ora10g/admin/test08/udump/test08_ora_15629.trc
/opt/ora10g/admin/test08/udump/test08_ora_15629.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /opt/ora10g/product/10.2.0/db_1
System name: Linux
Node name: yans1
Release: 2.6.9-42.0.0.0.1.ELsmp
Version: #1 SMP Sun Oct 15 15:13:57 PDT 2006
Machine: x86_64
Instance name: test08
Redo thread mounted by this instance: 1
Oracle process number: 20
Unix process pid: 15629, image: oracle@yans1 (TNS V1-V3)

*** 2008-06-10 17:01:03.275
*** SERVICE NAME:(SYS$USERS) 2008-06-10 17:01:03.265
*** SESSION ID:(117.7376) 2008-06-10 17:01:03.265
KGX cleanup...
KGX Atomic Operation Log 0xdb72c4f8
Mutex 0xd1c1ce40(117, 0) idn 0 oper EXAM
Cursor Parent uid 117 efd 5 whr 26 slp 0
oper=DEFAULT pt1=0xcf970858 pt2=0xcf970a40 pt3=0xcf970f60
pt4=(nil) u41=0 stt=0
*** 2008-06-10 17:02:50.783
----------------------------------------
SO: 0xf31f7090, type: 2, owner: (nil), flag: INIT/-/-/0x00
(process) Oracle pid=21, calls cur/top: (nil)/0xe80f92c0, flag: (0) -
int error: 1089, call error: 0, sess error: 0, txn error 0
(post info) last post received: 1089 8 12
last post received-location: ksusig
last process to post me: f01cf770 70 0
last post sent: 0 0 0
last post sent-location: No post
last process posted by me: none
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 0xf3217738
O/S info: user: oracle, term: pts/2, ospid: 15693
OSD pid info: Unix process pid: 15693, image: oracle@yans1 (TNS V1-V3)
*** 2008-06-10 17:03:20.787
Short stack dump: ... timed out; stack dump taking longer than 30000 ms
Dump of memory from 0x00000000F31E9D78 to 0x00000000F31E9F80
0F31E9D70 00000004 00000000 [........]
0F31E9D80 E90D60C0 00000000 00000010 0003139D [.`..............]
0F31E9D90 E80F92C0 00000000 00000003 0003139D [................]
0F31E9DA0 F033F1C0 00000000 0000000B 0003139D [..3.............]
0F31E9DB0 F3271290 00000000 00000004 00031291 [..'.............]
0F31E9DC0 00000000 00000000 00000000 00000000 [................]
Repeat 27 times

在另外的会话以SYSDBA登陆，利用SHUTDOWN ABORT可以关闭数据库，重启数据库也没有问题。

查询metalink发现是Oracle10g的一个bug，bug描述为：Doc ID: Note:5057695.8。Oracle在10.2.0.4和11中解决了这个bug。

如果metalink上的描述比较短，能贴上来么？如果比较长就弄个附件上来，至少也可以让我这种无法访问metalink的人能更深入了解下。

晕，不知道是itpub的问题，还是我自己机器的问题，经常出现页面重定向报错。其他网站没问题。错误信息如下：

The requested URL could not be retrieved

刷新页面导致了重复提交，sigh...

我碰到过和楼主一样的情况， 原因不同。 我的是9I, 做SAP的DB
当DB上很多session是激活状态时， 用shutdown immediate都不会成功。 我一般找到该oracle session对应的PID， kill掉后再shutdown 就没问题

老杨又发现一个bug……嘿嘿。在老杨的blog上，几乎三天两头能发现bug

re bbobb：9i下的，在alertlog中能发现报错 active process prevent shutdown operation……之类的报错，一般都是job还在运行。

我们一般的做法是：停侦听->kill LOCAL=NO的进程->停job、停aq->switch logfile 若干次->检查是否有v$transaction-再shutdown->若shutdown失败，重新startup，再次shutdown->若三次后还是失败，联系oracle厂家……-_-!

其实oracle的bug不比windows少

一般我们先干掉监听
然后干掉所有的local=no的连接
然后shutdown immediate
如果5分钟没任何相应
直接重开session,shutdown abort
没啥,呵呵
遇到无数次了.

to kylin:metalink的东西是付费的，不好随便贴

to bbobb、小荷、David.Guo
其实一般shutdown immediate的时候，我会检查一下dba_jobs_running视图，并通过操作系统检查有没有僵死进程，如果没有的话，一般关闭不会有什么问题，不过对于系统比较繁忙的情况可能会慢一点。

不过这次这个比较特殊，系统没有用户访问，所有的非Oracle进程也都kill掉了，但是12个小时还是没有关闭。
当然这个数据库本身的状态也不是很正常，这估计也是问题的原因之一。

to niubro

只要软件规模一上去，都会有无数的bug。

无论是Oracle、windows还是unix也无可避免。

如何通过操作系统检查僵死的进程？ps命令？

操作系统命令TOP或PS等

前几天培训的时候遇到过一次,也是再开一个session直接shutdown abort关闭了,没有问题

shutdown abort把很多工作放到了STARTUP时候去完成