通过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 条评论
登录 后参与评论

相关文章

来自专栏数据和云

【合理授权,安全第一】聊一聊Oracle数据库的用户权限

编辑手记:年底大家最关注数据安全,之前我们说过,数据库的风险分为外部风险和内部风险。外部风险无法预估但概率较小,平时发生最多的还是内部操作的风险,因此合理控制权...

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

海量数据迁移之传输表空间(一) (r5笔记第71天)

在自己接触的很多的数据迁移工作中,使用外部表在一定程度上达到了系统的预期,对于增量,批量的数据迁移效果还是不错的,但是也不能停步不前,在很多限定的场景中,有很多...

2177
来自专栏数据和云

盘点 Oracle 11g 中新特性带来的10大性能影响

Oracle的任何一个新版本,总是会带来大量引人瞩目的新特性,但是往往在这些新特性引入之初,首先引起的是一些麻烦,因为对于新技术的不了解、因为对于旧环境的不适应...

3734
来自专栏企鹅号快讯

一枚女程序员眼中的mysql,值得收藏

某群聊天内容 什么是数据库? ‍‍数据库(Database)是按照数据结构来组织、存储和管理数据的仓库, 每个数据库都有一个或多个不同的API用于创建,访问,管...

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

使用外部表关联MySQL数据到Oracle(r6笔记第100天)

因为业务需要,有个临时的活动需要DBA来支持一些数据业务,问题来了,需要从MySQL端同步一部分数据到Oracle端,然后从Oracle端匹配查 到相应的数据返...

2474
来自专栏数据库

划重点!必备 SQL 查询优化技巧,提升网站访问速度

在这篇文章中,我将介绍如何识别导致性能出现问题的查询,如何找出它们的问题所在,以及快速修复这些问题和其他加快查询速度的方法。 ? 你一定知道,一个快速访问的网站...

2178
来自专栏ITCloud的专栏

五分钟聊T-SQL:数据压缩

传说中数据压缩能压缩到原始数据的1/10,但是... ... 但是至少目前为止我还没遇到过这样的情形,通常情况下能压缩到原始数据的1/5-2/5的样子。

2932
来自专栏企鹅号快讯

提升网站访问速度的 SQL 查询优化技巧

英文:Delicious Brains,翻译:开源中国 www.oschina.net/translate/sql-query-optimization ? 你...

20710
来自专栏Hadoop数据仓库

Oracle数据库的安全性措施概述

  Oracle的安全措施主要有三个方面,一是用户标识和鉴定;二是授权和检查机制;三是审计技术(是否使用审计技术可由用户灵活选择);除此之外,Oracle还允许...

1679
来自专栏程序员的SOD蜜

还在写SQL的同志,去喝杯咖啡吧!

--标题可能比较“雷人”,但这是我今天早上的第一个感受。我们有一个同事昨天加班写了一大堆有关某些大表(字段很多的表)的增、删、查的SQL语句,看着哪些SQL语句...

2195

扫码关注云+社区