通过top命令抓取cpu高消耗的sql (44天)

top命令在linux环境维护中很实用,虽然功能缺失不够sar那么全面。今天和大家分享一个通过top命令来抓取性能sql的案例。 通过top命令抓取了如下的信息。

pid是3585的进程对应的sql 之前已经确定是性能问题导致的了,所以先放过,可以看看pid是8879的这个进程,出现的不是很“稳定”。 可能通过ash,awr不一定能够及时的抓住这些信息,但是通过及时的分析,可能有时候会得到一想不到的收获。 可以通过v$session,v$process,v$sql来结合查找process对应的sql. 可以看到这个进程是属于一个远程的session(LOCAL=NO),是通过一个batch的服务器上发起的请求。 执行的sql很简单。就是一个简单的查询。初步怀疑就是因为查询走了全表扫描而且那个字段可能没有索引。

为了确认,查看表的结构来看看。可以结合user_tab_cols,user_ind_columns来查看表的属性和索引的信息。这些都是用准备好的脚本来生成的,过滤了一些不必要的信息。 可以看到,索引是存在的,在ext_account_number上,而且是唯一性索引。如果那样的话走全表扫描就有些不合常理了。

如果观察的再仔细些,可以看到ext_account_number那个字段是varchar2(12)的。 为了验证表肯定走了全表扫描,我抓了一个awrsqrpt的报告。内容如下,可以看到的确走了全表扫描。而且buffer gets还挺大,cpu消耗比较高。

到此为止,如果还不没明白的话,我做个简单的测试。 我从表里随机抓取10条记录。

SQL> SELECT balance ,EXT_ACCOUNT_NUMBER from ACCOUNT WHERE rownum<=10;   
 
BALANCE EXT_ACCOUNT_NUMBER
---------- ------------                                                  
         0 10257832                                                      
    772.81 10260829                                                      
    584.22 10259790                                                      
    329.03 10258781                                                      
      -.39 10263317                                                      
      -.14 10260830                                                      
    496.79 10258782                                                      
         0 10258783                                                      
      -.83 10258785                                                      
      -.91 10259791                                                      
 
10 rows selected.                                                        

然后来trace一把。看看执行的情况。 可以看到,确实走了全表扫描,没有走索引。可以看到filter部分,对于ext_account_number它是在解析的时候做了类型转换的,从varchar2转为number。 一致性读有12704.

这样问题的根源就很清晰了。再换一个,试试走索引的情况。可以看到,效率有了极大的提升。剩下的问题就是协调来解决了。

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

原文发表时间:2014-04-16

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

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

数据库收缩数据文件的尝试(三)(r11笔记第22天)

不知道大家在数据库运维中是否会有这样的困扰,一个数据文件里没有多少数据,但是数据文件的大小却调不下来,尝试使用resize来调整屡屡失败。如果一个数据文件里...

33612

所有您需要了解的关于Elasticsearch 5.0:索引管理

我们看到两种主要的Elasticsearch索引使用模式 - 全局索引和滚动索引。多年来,Elasticsearch增加了一些功能,可以极大地改善这些模式的工作...

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

复杂SQL性能优化的剖析(二)(r11笔记第37天)

昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是1...

3539
来自专栏.net core新时代

删除数据库日志文件的方法

       你曾经有在执行SQL的时候,数据库报事务日志已满,然后执行报错。然后纠结于怎么删除数据库日志,捣鼓半天吗,现在就提供两种删除日志文件的方法,希望能...

2275
来自专栏企鹅号快讯

Django数据从sqlite迁移数据到MySQL

昨天快速搭建了一套自己的知识库 感觉一下子有了很多的事情要做,至少得让自己用得舒服些。 没想到有了这个小工具之后,我发现我之前过得真是刀耕火种的信息收集。为什么...

3996
来自专栏Keegan小钢

App项目实战之路(六):数据库篇

上一篇文章[服务端篇]提到本项目的数据库采用了关系型的 MySQL,那么,本文将基于 MySQL 聊聊本项目的数据库设计。

843
来自专栏沃趣科技

Oracle数据库12cR2版本的SQL计划管理

文章翻译自ORACLE WHITE PAPER SQL Plan Management with Oracle Database 12c Release 2 概...

34110
来自专栏java架构技术

从大神的角度深入理解MySQL,值得收藏~

在此我向大家推荐一个架构学习交流群。程序员面试社区:236283328 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分...

981
来自专栏Java工程师日常干货

从程序员的角度深入理解MySQL前言数据库基本原理探索MySQL索引背后的原理SQL优化神器:explain

作为一名工作了4年的程序猿,今天我将站在程序员的角度以MySQL为例探索数据库的奥秘!

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

Django数据从sqlite迁移数据到MySQL

昨天快速搭建了一套自己的知识库:使用Django基础模板搭建自己的知识库 感觉一下子有了很多的事情要做,至少得让自己用得舒服些。 没想到有了这个小工具之后,我发...

3403

扫码关注云+社区