早上刚到公司，查看系统的负载，就马上看到一个进程的执行时间已经有3天了。 而且cpu的消耗极高。 Tasks: 2374 total,  19 running, 2354 sleeping,   0 stopped,   1 zombie Cpu(s): 21.7%us,  2.7%sy,  0.0%ni, 74.5%id,  0.0%wa,  0.1%hi,  0.9%si,  0.0%st Mem:  371307496k total, 97308748k used, 273998748k free,  1750680k buffers Swap: 377487328k total,     9440k used, 377477888k free, 20010856k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                         31330 xxxx   25   0 18.2g  30m  24m R 100.0  0.0   5557:32 oraclePRODB1 (LOCAL=NO)             马上通过process定位对应的session，看看这个session正在做什么操作。 查看锁的情况，没发现异常的锁，看来不会是大的dml操作。 以下是定位到的信息，最后发现是有人使用sqldevelopper做了一个"简单"的查询。

xxxxx  23328 20824  0 11:53 pts/4    00:00:00 ksh showpid.sh 31330

xxxxx  31330     1 99 Aug28 ?        3-20:45:06 oraclePRODB1 (LOCAL=NO)

##############################################

 

       SID    SERIAL# USERNAME        OSUSER          MACHINE              PROCESS         TERMINAL        TYPE       LOGIN_TIME

---------- ---------- --------------- --------------- -------------------- --------------- --------------- ---------- -------------------

      3482      42183 xxxxxx             xxxxxxx           xxxxxxxxx      692             unknown         USER       2014-08-28 14:59:29

 

àquery is running now.

SQL_ID                         SQL_TEXT

------------------------------ ------------------------------------------------------------

210ndtcx5fwgs                  SELECT COUNT(*)  FROM SUBSCRIBER S , SERVICE_ACTIVITY SA

 

你没看错，sql语句就一行，而且是一个select count的语句。但是很显然在做表连接的时候就埋下了炸弹，68T行的数据，百亿的数据结果。

来看看对应的执行计划吧。 Plan hash value: 1483588918                                                                                                                                           ---------------------------------------------------------------------------------- | Id  | Operation         | Name                 | Rows  | Cost (%CPU)| Time     | ---------------------------------------------------------------------------------- |   0 | SELECT STATEMENT  |                      |       |     24G(100)|          | |   1 |  SORT AGGREGATE   |                      |     1 |            |          | |   2 |   NESTED LOOPS    |                      |     68T|    24G  (1)|999:59:59 | |   3 |    INDEX FULL SCAN| SERVICE_ACTIVITY_PK |    51M| 31553   (1)| 00:06:19 | |   4 |    INDEX FULL SCAN| SUBSCRIBER_PK        |  1320K|   481   (1)| 00:00:06 | ---------------------------------------------------------------------------------- 所以在开发，测试，生产环境都需要注意，这种问题如果发生的话还是很郁闷的。                                                                                  

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1261467/，如需转载，请注明出处，否则将追究法律责任。