一條執行了3天的"簡單"的sql

dbhelper發表於2014-11-26
早上剛到公司,檢視系統的負載,就馬上看到一個程式的執行時間已經有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/8494287/viewspace-1347041/,如需轉載,請註明出處,否則將追究法律責任。

相關文章