一條執行了3天的"簡單"的sql
而且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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一條簡單的sql語句執行15天的原因分析SQL
- 對一條基於分割槽的簡單SQL的優化SQL優化
- 每秒執行6000的簡單SQL優化(一)SQL優化
- MySQL 記錄所有執行了的 sql 語句MySql
- 一條Sql的執行過程SQL
- 一條更新sql的執行之路SQL
- 一條簡單的sql語句導致的系統問題SQL
- 34條簡單的SQL優化準則SQL優化
- 一條簡單SQL語句的構成及語句解析SQL
- 一條查詢sql的執行之路SQL
- 34條簡單的SQL最佳化準則SQL
- 一條簡單的SQL語句優化-新年新氣象SQL優化
- 一條"簡單"的sql語句和小兔子買麵包的故事SQL
- 一條簡單的sql在11g和12c中的不同SQL
- 一條sql語句的執行過程SQL
- 一條 sql 的執行過程詳解SQL
- 面試官:請分析一條SQL的執行面試SQL
- MySQL 中一條 sql 的執行過程MySql
- 一個簡單的sql稽核案例SQL
- 一條更新的SQL語句是如何執行的?SQL
- 估算SQL已經執行了多少時間SQL
- 一條update SQL語句是如何執行的SQL
- 一條SQL更新語句是如何執行的SQL
- 一條SQL更新語句是如何執行的?SQL
- AutoTRACE是分析SQL的執行計劃,執行效率的一個非常簡單方便的工具SQL
- 每秒執行6000的簡單SQL優化(二)SQL優化
- 超級簡單的sql入門(一)SQL
- 一條 SQL 查詢語句是如何執行的?SQL
- 一條SQL語句在MySQL中如何執行的MySql
- 你瞭解一條sql的執行順序嗎SQL
- mybatis條件判斷及動態sql的簡單擴充MyBatisSQL
- 簡單的SVG線條動畫SVG動畫
- 一條簡單的報警資訊發現的oracle bugOracle
- sql簡單入門的一些操作SQL
- SQL*Plus的簡單使用之一(轉)SQL
- 一條SQL的改寫SQL
- 一條sql語句在mysql中是如何執行的MySql
- 一條SQL語句的執行計劃變化探究SQL