一条报警信息的快速处理和分析

下午的时候收到这么一条报警。

ZABBIX-监控系统:
------------------------------------
报警内容: Too many parallel sessions on xxxxx_xx机房_xxxxx
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: parallel_session_cnt66
------------------------------------
报警时间:2016.08.22-17:27:54
这个报警的意思是并行会话数达到了66个。已经远超出了阈值。

在几分钟后我又收到了恢复的邮件,可见问题自动修复了。那这个问题该怎么解释呢。
如果通过AWR来定位很可能捕捉不到这个抖动,而且把AWR快照的收集频度降低本身也不能完全解决问题,所以这个时候就需要借助ASH了。
对于ASH生成报告而言,我对于里面需要设置的时间格式深恶痛绝,所以在很早之前就做了简单定制,手工输入两个时间戳,还可以灵活调整范围,很快就定位到了一条语句。
可以看到在时间范围内的SQL基本都是从Orabbix端触发的,而这里有一条语句引起了我的注意。

其它的语句都是查询数据字典的信息,而蓝色部分标示的这条语句一看就是应用层面的。查看执行计划,马上就明白了原委。

这条语句做了全表扫描,因为数据量巨大,所以执行效率低下,而且同时启用了并行,所以相对来看执行效率还可以,但是由此可见系统层面的资源消耗会非常大。
所以问题又来了,为什么全表扫描,启用了并行,怎么会有66个并行会话。看这个语句似乎也没有什么Hint的痕迹。
那么这个问题的原因就更加容易定位了。
SQL> select degree,table_name from dba_tables where table_name='TEST_VIP_NEW' and owner='TEST’;
DEGREE               TABLE_NAME
-------------------- ------------------------------
        32           TEST_VIP_NEW
可以通过这个配置看出并行度为32,所以问题的原因就马上可以定位出来了。
现在的问题是这个语句存在性能问题,一方面会导致大量的资源耗费,二来执行时间也相对比较长,为什么这个大的表执行效率会如此差呢,问题的方向应该在于索引,排除了其它的因素,发现这个表的数据千万级,存在几个索引,但是唯独这个语句where条件中的字段不存在相关的索引,而这个问题可以进一步分析和查看,其实就是根据rank=0,grade=0来得到结果集,从执行计划可以看出这个结果集非常大,其实就算是得到了对应CN列值,本身处理起来也是一个很庞大的工程。所以这个语句从应用层面来看也是存在问题。而另外一个就是并行度,这个表的并行度有些太高,可以适当做一个调整,同时结合起来和开发同学做进一步的确认。我想这个问题在监控体系之内应该是不会报警了。

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。

【MySQL】Tokudb安装测试初探 - 2016-08-24 14:08:02

一 前言    TokuDB 是一个高性能、支持MVCC的MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点是数据压缩功能出色,对高写压力的支持,由美国TokuTek公司(http://www.tokutek.com/) 研发,该公司于2015年4月份被Percona收购,理所当然地提供了TokuDB版本的Percona Server。本文使用Peronca server 5.6.30 版本进行测试安装。 二 安装前的准备     请参考官方文档 Percona Server YUM源

通过shell脚本添加备库日志 - 2016-08-21 17:08:14

今天下午的时候,准备顺手写一个简单的脚本,但是发现很多事情较真起来真是寸步难行。在写脚本的过程中碰到了太多的问题,很多时候感觉像要实现的功能更通用,就得做更多的检查,更多的校验也就意味着有更多的预先条件,这些条件里面有些是规范和建议,有些是按照已有的配置情况,尽管如此,自己感觉还是缺少了太多的检查。   先来说说今天尝试的简单脚本,就是给主库添加standby logfile,这个需求听起来非常简单,都甚至在我的半自动化脚本中隐去了,但是把这个需求要落到纸面上来,简直了。 首先这个需求会涉及到下面的几个数据
今天在测试时遇到一个ORA-38706ORA-38707报错,乍一看到报错内容竟然没有回过神儿来。 ORA-38706ORA-38707报错 点击( 此处 )折叠或打开 SYS @ HOEGH select banner from v$version ; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition R

Oracle之虚拟索引 - 2016-08-21 14:08:07

Oracle 之虚拟索引 1    BLOG 文档结构图     2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ①  Oracle 虚拟索引的使用   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )和微信公众号( xiaomaimiaolhr )有同步更新 ②

MySQL 事务提交过程 - 2016-08-18 17:08:13

开发老大要求通过binlog查询一条被修改的数据,数据被查出后问我,有没有可能binlog中不会记录,回答不会,因为数据被修改,若失败直接回滚,不会在binlog中记录,此刻一个朋友用了洪荒之力告诉我,失败的话也会记录,坐地无语,因为他sqlserver dba,用sqlserver的思维考虑mysql,哈哈哈哈哈,用实验让他闭嘴! 简单测试步骤如下: root(yoon) flush logs; Query OK, 0 rows affected (0.01 sec) root((none)) show

Data Guard跳归档恢复的案例 - 2016-08-18 14:08:08

自前些天写了一个脚本之后,今天特意测试了一下,没想到一下子发现了一个大问题。有一套一主两备的10gR2环境,一个异机备库一直在READ ONLY状态,也就意味着数据库在打开之后一直忘了恢复应用归档,然后在某一天发现时,已经延迟了好几个月。无论怎样,还得庆幸发现了这个问题。 目前来看一种行之有效的方法就是重搭备库,但是这种修复方式需要大量的磁盘空间,而且需要恢复的时间较长,怎么改进呢,可以考虑通过基于SCN的增量备份来跳归档恢复。目前的环境是一主两备,再怎么改进呢,我们可以基于备库1来完成基于SCN的增量备份
背景 本文对 5.6 主备场景下,在备库做物理备份遇到死锁的case进行分析,希望对大家有所帮助。 这里用的的物理备份工具是 Percona-XtraBackup(PXB),有的同学可能不清楚其备份流程,所以这里先简单说下,PXB的备份步骤是这样的: 拷贝 InnoDB redo log,这是一个单独的线程在拷,直到备份结束; 拷贝所有InnoDB ibd文件; 加全局读锁,执行 FLUSH TABLES WITH READ LOCK(FTWRL); 拷贝 frm、MYD、MYI 等文件; 获取位点信息,
链接: http://blog.itpub.net/28602568/viewspace-2123386/ 标题: Oracle not exist子查询全扫的优化   作者: lōττéry ©版权所有[文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.] 前言:   之前写过  Oracle 针对子查询里有group by 表全扫的优化 ( 子查询和外层关系是left join);   本次介绍 子查询与外层是not exists的关系是如何优化子查询全扫的;    优化前: SQL SET
【故障处理】 ORA-12545: Connect failed because target host or object does not exist 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ①  错误 ORA-12545: Connect failed because target host or object does not exis
今天写了个脚本,虽然实现的功能不多,但是个人感觉是一个好的开始,架子出来了,后面要补充的细节加进来就逐步完善了。 这个脚本的运行效果如下: OS     Version  is :[ RHEL_6.3 ] Oracle Version  is :[ 11.2.0.3.0] Oracle Instance is :[ dgtest ] dgtest ORACLE_HOME     is :[ /U01/app/oracle/product/11.2.0.2/db_1  ] Oracle  status  is