关于奇怪的并行进程分析(三)(r6笔记第47天)

在前两篇的基础上,对于一个环境中存在的奇怪并行进程问题进行了初步的分析。 初步排除了是通过scheduler的job运行导致的,一方面因为运行的时间会有延迟,甚至有很大的差别。所以分析和排查按照scheduler的时间点没有办法抓到任何规律。 排除了scheduler的影响之后,在分析ash之后无果,最后无奈使用了自定义脚本来排查问题。当然这个也确实需要点时间。 通过脚本跟踪的方式还是针对性要强一些,有些明细信息在ash报告中也体现不到,比如启用了多少的并行进程,那些语句走了大量的并行等等。 查看今天早晨的日志,发现竟然还有SYS的用户在做并行查询,先来说说这个问题。 抓取到的日志信息如下: 17 19257 SYS statdb96.cyou.com oracle@statdb96.test.com (P013) oracle INACTIVE 2015-09-02 02:03:01 5vf4b6p4v79rm ENABLED DISABLED ENABLED 29 64027 SYS statdb96.cyou.com oracle@statdb96.test.com (P056) oracle INACTIVE 2015-09-02 02:03:01 5vf4b6p4v79rm ENABLED DISABLED ENABLED 可以读取到SYS在运行sql_id 为5vf4b6p4v79rm 的sql语句,而且走了并行,我们来看看这个语句到底是怎么样的。 因为之前通过v$sql,dba_sql_hist的方式去查找parallel相关的语句,也没有找到让人信服的sql语句,这种守株待兔的方式得到的语句还是值得信任的。 语句内容如下: SELECT SERV_GROUP, CN_GUID, MAX(USER_CLASS) MCLASS, MAX(END_TIME) LASTTIME, MIN(END_TIME) FIRSTTIME FROM TESTUSER.TEST_BILLDETAIL WHERE END_TIME >= :B2 AND END_TIME < :B1 AND CN_GUID > 0 GROUP BY SERV_GROUP,CN_GUID

这个语句中没有任何的并行hint,但是确确实实走了并行,而且并行度还很高。 查看一下执行计划,发现一个很明显的全表扫描。这个表的数据量过亿,这个全表扫描的代价还是很高的。 ------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1186K| 30M| |* 1 | PX COORDINATOR | | | | | 2 | PX SEND QC (RANDOM) | :TQ10001 | 1186K| 30M| | 3 | HASH GROUP BY | | 1186K| 30M| | 4 | PX RECEIVE | | 1186K| 30M| | 5 | PX SEND HASH | :TQ10000 | 1186K| 30M| |* 6 | FILTER | | | | | 7 | PX BLOCK ITERATOR | | 1186K| 30M| |* 8 | TABLE ACCESS FULL| TEST_BILLDETAIL | 1186K| 30M| -------------------------------------------------------------------

但是查看语句,也不是一个很复杂的语句,我们来看看为什么走了全表扫描,而怎么没有考虑到索引扫描。 INDEX_NAME TABLESPACE INDEX_TYPE UNIQUENES PAR COLUMN_LIST ------------------------------ ---------- ---------- --------- --- -------------- IND_TEST_BILLDETAIL_CN NORMAL NONUNIQUE YES CN IND_TEST_BILLDETAIL_END_TIME NORMAL NONUNIQUE YES END_TIME

这个时候可以很i明显看到有一个索引是在字段END_TIME上的,所以说索引确确实实在哪儿,但是查询却压根没有走索引,而走了一个基于并行的圈全表扫描。 我们来看看索引的情况,这个索引是个分区索引,所以可以查看选择性的查看一部分索引信息。 INDEX_NAME PAR_NAME PAR_POS STATUS -------------------- --------------- ---------- ------- -------- IND_TEST_BILLDETAIL_CN TEST_BILLDETAIL_ 20091201 1 UNUSABLE

IND_TEST_BILLDETAIL_CN TEST_BILLDETAIL_ 20091202 1 UNUSABLE 随便抓取了几条,仔细一看,发现有很多索引都是unusable状态了,这个时候问题似乎有了很大的转机,索引失效导致的索引扫描没有启用,而走了全表扫描。 而对于这个问题的修复相对来说就简单多了,重新做rebuild即可,为了不影响在线业务,可以做一个小的尝试,拿一个数据比较早的分区来做一个测试,看看rebuild index partition之后,是否索引会正常启用。 SQL> alter index ldj.IND_TEST_BILLDETAIL_END_TIME rebuild partition TEST_BILLDETAIL_20091201; Index altered. 这个时候验证语句就类似下面的形式,同时把并行的影响也取消了。 SELECT /*+no_parallel*/ SERV_GROUP, CN_GUID, MAX(USER_CLASS) MCLASS, MAX(END_TIME) LASTTIME, MIN(END_TIME) FIRSTTIME FROM LDJ.SWD_BILLDETAIL partition(TEST_BILLDETAIL_20091201) WHERE END_TIME >= :B2 AND END_TIME < :B1 AND CN_GUID > 0 GROUP BY SERV_GROUP,CN_GUID rebuild index partition之前的执行计划如下: ------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 57 | 1197 | | 1 | HASH GROUP BY | | 57 | 1197 | |* 2 | FILTER | | | | | 3 | PARTITION RANGE SINGLE| | 57 | 1197 | |* 4 | TABLE ACCESS FULL | TEST_BILLDETAIL | 57 | 1197 | -------------------------------------------------------------------

rebuild index partition之后的执行计划如下: -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 57 | 1197 | | 1 | HASH GROUP BY | | 57 | 1197 | |* 2 | FILTER | | | | | 3 | PARTITION RANGE SINGLE | | 57 | 1197 | |* 4 | TABLE ACCESS BY LOCAL INDEX ROWID| TEST_BILLDETAIL | 57 | 1197 | |* 5 | INDEX RANGE SCAN | IND_TEST_BILLDETAIL_END_TIME | 103 | | --------------------------------------------------------------------------------------------

可以看到索引是能够正常启用的,这个时候并行的影响就可以基本排除了。 最后我们来简单说一说这个并行。 SQL>select degree,table_name,owner from dba_tables where table_name='SWD_BILLDETAIL' DEGREE TABLE_NAME OWNER -------------------- ------------------------------ ------------------------------ DEFAULT TEST_BILLDETAIL TESTDB 这种default的方式其实还有有些奇怪,如果要较真,会发现这个DEFAULT左边还是有一些空格的。 SQL> select degree from dba_tables where degree=' DEFAULT' and rownum<2; DEGREE -------------------- DEFAULT 这个是在对象级开了并行,至于并行度的情况,还是和参数parallel_execution_message_size有一些关系,我们先不细谈。 到此为止,我们发现了奇怪的并行问题其实和一个全表扫描相关,在这个基础上,继续分析发现索引没有启用,再进一步分析,发现对应的分区索引失效了。

这些问题都是一环套一环,缺一不可。 我们之前也分析过ASH报告中没有找到有效的信息,至于这个问题,其实是人为操作误导。

这一点还是需要特别说明一下,可以看看下面的操作结果说明了什么 $ echo $ORACLE_SID testdb1 $ sqlplus testdba/testdba@testdb1 SQL> select count(*)from v$session; COUNT(*) ---------- 39 SQL> conn / as sysdba Connected. SQL> select count(*)from v$session; COUNT(*) ---------- 165 SQL> show parameter uniq NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_unique_name string testdb96 这个奇怪问题的原因就在于我们使用原来的db_name连接到的实际上是备库,所以抓取的ash报告中没有任何的有效信息。 而这个问题的根源还是在于之前做了一次主从切换。结果从库变成了主库,使用的原来的Uniq_name也还是保留了原来的样子。tns这边也还是保留了原来的格式,结果在通过tns连接的时候就连接到了备库 当然事后也做了验证,发现ash在问题的时间点内抓取的报告还是很有效的,相关的问题sql都会抓取到。所以ASH报告还是很靠谱的。 通过这个案例我们可以看到对于一个很细小的问题进行深究会发现其实还是存在着一些潜在问题,问题的发生都是有原因的,性能的抖动也是有一些需要我们去关注的细节。 细节决定成败,说的也就是这个意思吧。

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

原文发表时间:2015-09-02

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏沃趣科技

统计信息查询视图|全方位认识 sys 系统库

在上一篇《会话和锁信息查询视图|全方位认识 sys 系统库》中,我们介绍了如何使用 sys 系统库总的视图来查询会话状态信息以及锁等待信息,本期的内容先给大家介...

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

通过shell脚本来统计段大小(r5笔记第14天)

今天到公司之后,就收到客户的邮件,他们提供了一个列表,希望我们能够们配合提供一份比较详细的报告,得到某些表在生产环境中所占的空间大小,他们需要根据这些信息来分析...

42370
来自专栏数据和云

书接上文:薛定谔的猫是如何诞生的?

编辑手记:注重细节,是DBA必要的基本素质要求。 书接上文(参考:空与非空 - 数据库中也有薛定谔的猫?),其实CBO的判断本身是没有问题的,问题在于,为什...

320100
来自专栏PHP在线

MYSQL 优化常用方法

1、选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在创建表的时候,为了获得...

35740
来自专栏晓晨的专栏

Sql Server利用游标批量清空数据表

10830
来自专栏Java帮帮-微信公众号-技术文章全总结

Java企业面试——数据库

数据库部分 数据表连接问题,左外连接、右外连接、内连接等 一、交叉连接(CROSS JOIN) 交叉连接(CROSS JOIN):有两种,显式的和隐式的,不...

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

生产环境sql语句调优实战第八篇(r3笔记第24天)

生产环境中的sql语句执行时间是很关键的性能指标,如果某个sql语句执行几个小时,优化以后几分钟,几十秒的话。会有很大的成就感,同时如果某个sql语句执行10秒...

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

基于DB time的调优分析 (r6笔记第79天)

继昨天使用DB time能够快速灵活的定位sql语句之后,发现分析问题更快捷,高效了。今天就牛刀小试,把一个数据库从500%的负载调到不到100%的负载。前提是...

31440
来自专栏Jerry的SAP技术分享

使用ABAP代码返回S/4HANA Material上维护的Attachment明细

17230
来自专栏idba

order by 结果不准确的问题

一 介绍 相信大部分DBA在和开发打交道的过程中,经常会遇到分页查询 order by 排序这样的需求。本文源于生产过程中的案例,5.6,5.7.16版本的...

9730

扫码关注云+社区

领取腾讯云代金券