快速定位隐蔽的sql性能问题及调优(r5笔记第38天)

在前几天,有个开发同事问我一个问题,其实也算是技术救援,他说在有个job数据处理的频率比较高,在测试环境中很难定位出在哪有问题,而且速度也还能接受,但是在生产环境中总是会慢一些,希望我能在测试环境中协助他们,看看是不是sql语句出什么问题了还是其它相关的问题。 这种类似实时监控的语句,从第一印象来说,很可能通过awr捕获不到,如果通过ash来捕获,因为测试环境中有几十套测试环境在运行,就算得到某个时间点的一些sql语句,直接在报告中映射到语句对应的schema信息还是有一些困难的。因为测试时间确实很短,有很多的语句执行了,可能不一定被ash收集到。 我和他首先做了沟通,因为我压根不知道这是哪个应用的环境,所以先需要几分钟的时间来熟悉一下环境,提前准备一下。 数据库中存在大概50套测试环境,占用的session数大概在4000个左右。整体来看测试环境中的数据量都不大。每个环境都大概在10G-30G以内。 定位到制定的测试环境中,发现session占用情况也不高。都是一些常规的job使用,没有看到其它明显的session消耗,查看相关的锁信息,也没有发现什么问题。 简单确认之后,发现awr在这个时候是用不了了,最多使用下ash来看,除此之外,还可以使用脚本实时监控。 类似下面这样的操作。 > getash.sh I SID SER# USERNAME OSUSER STA RPID SPID MACHINE PROGRAM ELAP_SEC TEMP_MB UNDO_MB SQL_ID TSPS SQL -- ------ ------ ------------ ---------- --- ------- ------ ---------- -------------------- ----------- ------- ------- ------------- ------ ------------------------------------------------- 1 19 16945 xxxx blwrk01 ACT 9442 9442 ccbdbprx oracle@xxxxxx 00 05:35:02 b9xg175fbzuk5 INSERT INTO xxxx (CYCLE_SEQ_NO, PAY 上面的语句也可以通过watch来指定频率看到每个用户下的信息实时变化情况。监控的过程中确实也能看到不少的信息变化,但是执行的时间确实很短,只能够抓取到一部分sql语句。简单分析了下,那些语句都没有发现有什么问题。 这个时候还是得靠开发协助,希望他们提示一些更细节的信息,这个业务场景要做的事情和一些指定的数据,他们提供说使用了某个表中资源号为 x271051128的数据,这个时候通过v$sql从缓存中就能够快速定位到语句,这个时候再和ash配合起来就能够确认是否是相关的用户在调用了。 最后抓取到了几条语句,和开发确认之后定位到一条语句,语句类似下面这样的形式。

select owner_id,

l3_balance_amount,

expiration_date,

customer_id,

c64_1,

l3_balance_Status,

sys_update_date,

sys_creation_Date

from accumulators

where customer_id in

(select customer_id

from subscriber

where prim_Resource_Val in ('x271051128'))

and owner_type = 'P' 通过抓取执行计划,发现subscriber表走了全表扫描。这个对应生产环境中的性能影响还是比较大的。

对于这个问题的调优,其实可以完全通过业务层面来优化,可以参考http://blog.itpub.net/23718752/viewspace-1312163/ 问题是类似的,略有不同。我们可以引入一个更大的资源表,资源表agreement_resource和用户表subscriber,使用索引字段来关联,就避免了subscriber表的全表扫描。 调整后的语句如下:

select owner_id,

l3_balance_amount,

expiration_date,

customer_id,

c64_1,

l3_balance_Status,

sys_update_date,

sys_creation_Date

from ape1_accumulators

where customer_id in

(

select customer_id

from subscriber s

where (subscriber_no, PRIM_RESOURCE_TP) in

(select agreement_no, RESOURCE_TYPE

from agreement_resource r

where r.resource_value in ('x271051128'))

)

and owner_type = 'P' 通过调整后的执行计划可以看出,性能的提升还是很大的。这个是测试环境的数据,如果在数据量大的时候,优势就更加明显了。

所以对于这个问题,起因是有个job数据处理的频率比较高,在测试环境中很难定位出在哪有问题,而且速度也还能接受,但是在生产环境中总是会慢一些,其实深究起来还是有原因的,只能通过各种细节去诊断发现了。

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

原文发表时间:2015-05-16

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

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

数据迁移中需要考虑的问题(r2第15天)

在生产环境中,做数据迁移需要考虑很多的可能性和场景,尽量排除可能发生的问题。我自己总结了下,大体有如下需要注意的地方。 1)充分的测试,评估时间,总结经验,提升...

3059
来自专栏数据和云

实战课堂:一则CPU 100%的故障分析处理知识和警示

编辑手记:在现实的生产环境中,DBA可能遭遇到各种各样的异常,或简单、或复杂,但是无一不考验DBA的经验和能力,在『实战课堂』栏目中,我们将整理和分享来自云和恩...

1243
来自专栏数据库

MongoDB距“干掉”MySQL登上王位还有多远

【IT168 资讯】几十年来,关系型数据库已经成为企业应用程序的基础,自从MySQL在1995年发布以来,深受企业的偏爱。然而随着近年来数据量和数据的不断激增,...

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

DBA和开发同事的一些代沟(一)(r7笔记第17天)

DBA同学在工作中不可避免和开发同学打交道,和开发的同学在交流中还是有不少的小插曲,有些想想也蛮有意思,但是有些是痛点。 我举几个例子来说明,可能比较片面,但是...

3545
来自专栏13blog.site

Spring+SpringMVC+MyBatis+easyUI整合进阶篇(八)线上Mysql数据库崩溃事故的原因和处理

前文提要 承接前文《一次线上Mysql数据库崩溃事故的记录》,在文章中讲到了一次线上数据库崩溃的事件记录,建议两篇文章结合在一起看,不至于摸不着头脑。 由于时间...

3498
来自专栏数据和云

在线重定义“巧改”分区表

作者介绍: 曾令军,云和恩墨技术专家,2009年开始接触ORACLE数据库,8年数据库运维经验。思维敏捷,擅长于数据库开发、解决棘手的数据库故障和性能问题。服务...

3716
来自专栏逸鹏说道

SQL Server安全(1/11):SQL Server安全概述

在保密你的服务器和数据,防备当前复杂的攻击,SQL Server有你需要的一切。但在你能有效使用这些安全功能前,你需要理解你面对的威胁和一些基本的安全概念。这篇...

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

和开发同学讨论的一个技术问题(r8笔记第73天)

今天下午的时候,有一位开发同事找我,说有一个技术问题想请教一下。 当然正如他所说,这个问题比较奇怪,而且已经影响了他的测试流程,他说有一个表查看对应的表空...

2955
来自专栏数据和云

表分区“拖出”的性能Error

作者介绍: 曾令军,云和恩墨技术专家,2009年开始接触ORACLE数据库,8年数据库运维经验。思维敏捷,擅长于数据库开发、解决棘手的数据库故障和性能问题。服务...

3347
来自专栏SAP最佳业务实践

SAP最佳业务实践:FI–现金管理(160)-4 F110创建演示数据-清算供应商发票

2.3.4 通过 F110 付款运行清算供应商发票 要执行该活动,使用此文档中的主数据运行应付帐款:自动付款 (158) 业务情景。 字段名称用户操作和值注释...

3725

扫码关注云+社区

领取腾讯云代金券