公众号：杨建荣的学习笔记 · 作者：r2笔记82天 · 发布：2014-09-01 20:58:40 · 原文链接

早上刚到公司，查看系统的负载，就马上看到一个进程的执行时间已经有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 |
———————————————————————————-

所以在开发，测试，生产环境都需要注意，这种问题如果发生的话还是很郁闷的。