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

前几天的并行问题自己分析了下,也算有了一些进展,但是目前还没有找到让人信服的理由,有些读者也比较关心这个问题,所以第二篇中会把自己的分析过程写出来,第三篇中应该会对这个问题做一个了结。 之前发现剧烈的性能抖动似乎和数据库中存在的scheduler有一定的关系。自己就顺着这个思路进行了排查。 首先得到了离问题时间点比较接近的一个scheduler,然后抓取了对应的ddl语句。 OWNER JOB_NAME LAST_START_DATE ------- -------------- --------------------------------------------- APP_TEST SYN_D 27-AUG-15 07.11.00.002185 AM ASIA/SHANGHAI 发现这个scheduler job的过程其实很简单,是一个刷新物化视图的操作。 CREATE REFRESH_UB_REG BEGIN dbms_scheduler.create_job('"SYN_D"', job_type=>'PLSQL_BLOCK', job_action=> 'begin dbms_mview.REFRESH(''XXX.USER_BASIC_TEST''); end;' , number_of_arguments=>0, start_date=>TO_TIMESTAMP_TZ('24-JUL-2011 12.00.00.000000000 AM ASIA/SHANGHAI','DD-MON-RRRR HH.MI.SSXFF AM TZR','NLS_DATE_LANGUAGE=english'), repeat_interval=> 'FREQ=DAILY;BYHOUR=7;BYMINUTE=11;BYSECOND=0' , end_date=>NULL, job_class=>'"DEFAULT_JOB_CLASS"', enabled=>FALSE, auto_drop=>FALSE,comments=> NULL dbms_scheduler.set_attribute('"REFRESH_UB_REG"','logging_level',DBMS_SCHEDULER.LOGGING_RUNS); dbms_scheduler.enable('"SYN_D"'); COMMIT; END; 可以看到这个scheduler已经运行很长时间了。每天在早晨的固定时间点进行刷新。然后尝试查看这个物化视图的ddl语句。 SQL> select object_name,object_type from dba_objects where object_name='USER_BASIC_TEST'; OBJECT_NAME OBJECT_TYPE -------------------- ------------------- USER_BASIC_TEST TABLE USER_BASIC_TEST MATERIALIZED VIEW 对应的ddl类似下面的形式。 select dbms_metadata.get_ddl('MATERIALIZED_VIEW','USER_BASIC_TEST','XXX') FROM DUAL; CREATE MATERIALIZED VIEW "XXX"."USER_BASIC_TEST" ...... AS SELECT xxxxx FROM "TEST2"."USER_BASIC_TEST"@DB84 "USER_BASIC_TEST" 可以看到内部还是尝试使用了db link,这个时候感觉已经抓到了一些规律。 先看看这个物化视图中的数据,结果已查看让自己大吃一惊,里面已经有好几亿条记录了。 SQL> select count(*)from "XXX"."USER_BASIC_TEST"; COUNT(*) ---------- 245362686 而刷新物化视图的时候,使用dbms_mview.REFRESH(''XXX.USER_BASIC_TEST'') 也没有指定快速刷新,很可能走了全量刷新,那么就会产生大量的redo,这个似乎和问题的特征有些类似。 感觉这个时候问题已经离自己很近了。 连接到源头数据库中,带着一丝自信开始尝试创建物化视图日志,结果发现已经创建了。 SQL> create materialized view log on test2.USER_BASIC_TEST; create materialized view log on test2.USER_BASIC_TEST * ERROR at line 1: ORA-12000: a materialized view log already exists on table 'USER_BASIC_TEST' 带着疑问在目标端进行刷新,发现快速刷新确实很快,但是不指定fast选项也是默认走快速刷新。 --指定快速刷新选项 SQL> EXEC dbms_mview.REFRESH('xxx.USER_BASIC_TEST',method=>'FAST'); PL/SQL procedure successfully completed. Elapsed: 00:00:00.09 --不指定刷新选项 SQL> EXEC dbms_mview.REFRESH('xxx.USER_BASIC_TEST'); PL/SQL procedure successfully completed. Elapsed: 00:00:00.01 所以这个时候问题的分析无功而返, 看来还需要另辟蹊径。 抓取了ash报告,但是从很精确的时间范围内,也没有得到相关的sql.可以看到一个相同点就是有一个等待事件。

Event

Event Class

% Event

Avg Active Sessions

SQL*Net vector data from client

Network

15.71

0.73

在mos上面也没有抓到相关的信息,只有一篇1311281.1描述是个bug.但是我当前的条件还是有一些差距。 没有了思路,决定重头再来,既然有大量的并行,但是又从报告中看不到,邮件报警里提示确实有大量的并行进程,我们可以化被动为主动。 既然并行进程持续时间很短,ash中还抓取不到,那么我们可以使用来抓取。 于是我写了下面的脚本。这个脚本会去查询session中含有并行字样的session,然后同时查询v$px_session中的并行session. 每5秒轮询一次,一晚上下来日志差不多在几十M,还是能够接受的。 function check_sess { sqlplus -s / as sysdba <<EOF set time on set linesize 200 col machine format a20 col program format a32 col username format a10 col osuser format a10 col logon_time format a20 set feedback off set pages 0 spool check_session.log append select systimestamp from dual; select sid,serial#,username,machine,program,osuser,status,LOGON_TIME,sql_id from v\$session where upper(program) like '%(P%' and (program not like '%PMON%' and program not like '%PSP%' ); select sid,serial#,username,machine,program,osuser,status,LOGON_TIME,sql_id from v\$session where sid in (select qcsid from v\$px_session group by qcsid) ; select sid,serial#,qcsid,qcserial#,QCINST_ID,degree,server_set,server_group,req_degree from v\$px_session; EOF } for i in {1..36500} do check_sess; sleep 5 done 期待这种守株待兔的方式能够得到一些有用的信息。

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

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

备库报警邮件的分析案例(二) (r7笔记第15天)

备库报警邮件的分析案例(一) (r7笔记第14天) 在第一篇中分享了关于备库报警邮件的分析,发现很多问题都是一环扣一环. 起初是通过监控主库中的v$datagu...

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

分区表的一个持续改进方案(r9笔记第53天)

今天看到一个同事发了一封邮件,是关于分区的,他说目前某个表的分区需要添加,为了保险起见,让我先添加三年的。这里折射出几个问题。 1.如果没有这位开发同学提醒,我...

3024
来自专栏架构师之路

58到家MySQL军规升级版

一、基础规范 表存储引擎必须使用InnoDB 表字符集默认使用utf8,必要时候使用utf8mb4 解读: (1)通用,无乱码风险,汉字3字节,英文1字节 (...

43315
来自专栏Golang语言社区

二十种实战调优MySQL性能优化的经验

今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显。关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事...

692
来自专栏java一日一条

MySQL 性能优化的最佳 20+ 条经验

今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显。关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我 们程序员需要去关注的...

452
来自专栏数据和云

一个不懂业务的DBA不是好的DBA

编辑手记:懂业务,懂系统逻辑,你才能做一个更好的DBA。 在数据库巡检中发现一个MES生产信息数据库中一个存储过程中一条SQL单次逻辑读为2100,且执行很频繁...

2936
来自专栏java一日一条

MySQL 性能优化的最佳 20+ 条经验

今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显。关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我 们程序员需要去关注的...

933
来自专栏进击的程序猿

The Clean Architecture in PHP 读书笔记(十)

这是clean architecture的第十篇,也是具体案例的第二篇,本篇会通过使用laravel框架,来开发我们的应用。

1043
来自专栏好好学java的技术栈

微信支付和支付宝支付到springmvc+spring+mybatis环境全过程(支付宝和微信支付)

2152
来自专栏性能与架构

这个sql为什么没有用到索引

用户users 表中对 create_time 字段建有索引 现在查询某个时间段的用户,通过explain发现下面这个sql 没有用到索引 explain ...

3285

扫码关注云+社区