oracle中怎么确定性能差的SQL语句

  次阅读 作者:智能小宝 来源:互联网 2016-01-28 13:20 我要评论(0)

前者很容易定位。所有的操作系统都可以让我们查看 CPU 密集型任务。这些任务可以追溯到一个特定用户,一个特定应用程序模块。 CPU 密集型模块一般都是由较差的代码和/或结构造成,而不是性能差的 SQL。一旦确定模块,你必须试图使之更有效率。一个可能的解决方案是将把某些处理移除程序,让数据库处理(高明点的 SQL,存储对象,内联函数,数组处理等)。

第二个是 I/O 密集型的 SQL 语句。这些语句会导致大量的数据库 I/O(全表扫描,排序,更新等),并以很高代价运行几个小时。从 Oracle 7 开始,解决了 SQL 识别问题。通过查询数据库共享池区域,我们可以很容易确定大多数 I/O 密集型 SQL 语句。

下面 SQL 语句演示了如何确定 I/O 命中率低于 80%的 SQL 语句。这个命中率是,自从 SQL 语句第一次被解析到共享池,通过所有执行的语句反应整体 I/O。下面可能是最近几分钟或几天的结果:

代码如下

sql> SELECT executions,

2disk_reads,

3buffer_gets,

4ROUND((buffer_gets - disk_reads) / buffer_gets, 2) hit_ratio,

5sql_text

6FROMv$sqlarea

7WHEREexecutions> 0

8ANDbuffer_gets > 0

9AND(buffer_gets - disk_reads) / buffer_gets < 0.80

10order by 4 desc ;

EXECUTIONS DISK_READS BUFFER_GETSHIT_RATIO SQL_TEXT

---------- ---------- ----------- ---------- -----------------------------------------------------------------------

16180369.51 SELECT SKU,PREPACK_IND,CASE_ID,TRANSFER_QTY,UNIT_COST,UNIT_RETAIL,ROWID

FROM TSF_DETAIL WHERE transfer = :1order by sku

163063.52 SELECT TRANSFER,TO_STORE,TO_WH FROM TSFHEADWHERE TRANSFER = :b1AND

TRANSFER_STATUS = 'A'

237.57 SELECT SKUFROM UPC_EANWHERE UPC = :b1

121435.60 SELECT SUBSTR(DESC_UP,1,30),DEPT,SYSTEM_INDFROM DESC_LOOKWHERE

SKU = :b1

141335.63 SELECT UNIT_COST,UNIT_RETAIL,SUBCLASS FROM WIN_SKUS WHERE SKU = :b1

事实上,我们发现对特定的 SQL,上面的数据有些误导,其实语句没有问题。考虑下面 v$sqlarea 输出:

Executions Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

---------- ---------- ----------- --------- --------------------

26190.68SELECT A.EMP_NO, ...

该语句的命中率很低,但事实上它很有效。因为,SQL 是通过 UNIQUE 索引操作的,物理磁盘读取的数量几乎与逻辑读取一样。UNIQUE 索引显著减少了整体的物理和逻辑磁盘 I/O 数量,导致了一个令人误解的低命中率。

下面例子,命中率很好。但是真的很好吗?

代码如下

Executions Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

---------- ---------- ----------- --------- --------------------

236251787770.98SELECT A.EMP_NO, ...

这个 SQL 语句看上去很有效。但是, 当我们仔细看时,事情就不是那么回事了。命中率并没有透露出,该语句存在五个表连接,并且每次执行进行了超过 3600 个物理磁盘读龋这是否太多了?是否有效?若不进一步研究,无法回答这两个问题。事实上,这个实例中,五个表的中其一个错误地执行了全表扫描。通过重新构造 SQL,我们可以减少物理磁盘 I/O 到小于 50,同时,也显著减少逻辑磁盘 I/O。巧合的是,命中率也下降到不到 70%。

我们首选 V$SQLAREA 查询是每个语句执行的物理磁盘 I/O 的真实报告。命中率是信息性的,但有时会产生误导。逻辑 I/O 相关的很少。如果语句执行 1,000,000 个逻辑 I/O,但只用了不到十分之一秒,这就没人在乎了。这是总的物理 I/O,几乎消耗了所有的时间,和确定潜在不正确的 SQL。例如:

代码如下

sql> SELECT sql_text, executions,

本站文章信息来源于网络以及网友投稿,本站只负责对文章进行整理、排版、编辑,是出于传递更多信息之目的,并不意味着赞同其观点或证实其内容的真实性。如果您有什么意见或建议,请联系QQ28-1688-302!

人工智能实验室
相关文章相关文章
  • 无人驾驶汽车如何改变城市生活?听听他们怎么说

    无人驾驶汽车如何改变城市生活?听听他们怎么说

  • 英国研发“杀生”机器人 通过生命体获取能量

    英国研发“杀生”机器人 通过生命体获取能量

  • 未来两年人工智能要怎么走?看这篇就够了

    未来两年人工智能要怎么走?看这篇就够了

  • 韩春雨称已能重复实验结果 近期将有消息公布

    韩春雨称已能重复实验结果 近期将有消息公布

网友点评网友点评
阅读推荐阅读推荐

据国外媒体报道,在过去两年内,聊天机器人(chatbot)、人工智能以及机器学习的研发和采用取得了巨大进展。许多初创公司正利用人工智能和...

霍金 视觉中国 图 英国著名物理学家霍金(Stephen Hawking)再次就人工智能(AI)发声,他认为:对于人类来说,强大AI的出现可能是最美妙的...

文|郑娟娟 今年,人工智能(AI) 60岁了。在AI60岁的时候,笔者想要介绍一下AI100,一个刚刚2岁的研究项目,但它的预设寿命是100年,甚至更长...

AlphaGo与李世石的人机大战,为大众迅速普及了人工智能的概念。 但对谷歌而言,除了下围棋,现在的人工智能进展到哪一步了?未来,人工智能...