一条运行了3天的"简单"的sql(r2笔记82天)

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


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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-09-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

一个oracle蠕虫病毒 (r4笔记第60天)

关于计算机病毒,说起来内容就很丰富了,但是第一次听到关于oracle中的病毒时,却感觉很新鲜。这是一个蠕虫病毒,距离现在已经有10年了,但是现在看起来还是能够借...

26030
来自专栏Hadoop数据仓库

Oracle通过HSODBC访问mysql

一、环境 OS:Linux myhostname 2.6.9-42.ELsmp #1 SMP Sat Aug 12 09:39:11 CDT 2006 i686...

20390
来自专栏杨建荣的学习笔记

awr性能问题排查第一篇(r3笔记第42天)

对于awr,里面涵盖的内容比较杂,有时候看报告的时候总是不知道该怎么下手。时间长了,可能会有一些阅读习惯或者心得。今天在看大师chris lawson的一篇博文...

30140
来自专栏杨建荣的学习笔记

CPU 100%负载的性能优化分析(r7笔记第40天)

今天收到报警邮件,提示在短时间内DB time有了很大的抖动。报警邮件如下: ZABBIX-监控系统: ------------------------...

36540
来自专栏杨建荣的学习笔记

ORA-00439的解决(笔记93天)

今天用gc配置了stream后,重启数据库后发现有以下的问题 SQL> startup ORA-00439: feature not enabled: Real...

359100
来自专栏技术翻译

构建自定义Apache NiFi操作仪表板(第1部分)

这是一个正在进行的工作; 请参与进来,一切都是开源的。Milind和我正在开发一个项目来构建一些对团队有用的东西来分析他们的流程,当前的集群状态,启动和停止流程...

32850
来自专栏杨建荣的学习笔记

通过shell脚本抓取awr报告中的问题sql(r6笔记第78天)

awr报告中的sql明细部分基本必看的部分,尤其是SQL Order by Elapsed time这个部分,能够很清晰的看到哪些sql语句占用了较多的DB t...

29730
来自专栏杨建荣的学习笔记

一个MySQL死锁问题的复现

很久之前有一个同事问我一个关于死锁的问题,一直在拖这个事情,总算找了空来看看。 这个环境的事务隔离级别是RR,仔细看了下问题描述和背景,发现还真不是一...

45590
来自专栏数据和云

追本溯源:Oracle 只读表空间的探索实践

作者简介 ? 胡中豪 云和恩墨西区交付工程师,多年一线 DBA 经验,曾服务于运营商、电网、政府行业、银行等行业客户;擅长数据库故障处理、性能优化、实施升级 本...

29530
来自专栏数据和云

极限优化:从75到2000,由技能到性能提升岂止80倍

崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 编辑手记:感谢崔华授权我们独家转载其精品文章,也欢迎大家向“Oracl...

28950

扫码关注云+社区

领取腾讯云代金券