前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >闪回区空间不足引发的SQL问题分析(r10笔记第32天)

闪回区空间不足引发的SQL问题分析(r10笔记第32天)

作者头像
jeanron100
发布2018-03-19 17:56:22
7410
发布2018-03-19 17:56:22
举报
文章被收录于专栏:杨建荣的学习笔记

有一天上班的时候,收到一封报警邮件。 ZABBIX-监控系统: ------------------------------------ 报警内容: archive_area_usage ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: archive_area_usage:ARCHIVED LOG-->70.25--> ------------------------------------ 报警时间:2016.09.20-08:52:47

可以看出是闪回区快满了,当然我设置了阈值70%,比Oracle默认的80%要更低一些,希望尽可能早的发现这些潜在的问题。 碰到这个问题,让我有些奇怪。 现在服务器端都有默认的crontab来设置定期删除过期的归档,怎么闪回区还会这么快就满了呢。这类问题的原因相对来说复杂一些,如果说从数据库层面来 看,如果在10gR2的版本中,可能出现这种情况,那就是有些命令的兼容性问题导致,如果是系统层面可能就是就是存储路径失效,比如nfs挂载点失效等导 致。 目前这个数据库是11gR2,存储都是本地磁盘。 我们来看看crontab的设置,可以看出是每个小时会运行,触发的频率较高,如果每天触发一次,如果存在这个问题可能还能理解,为什么在这种频率下删除归档依旧闪回区空间不足? $ crontab -l */50 * * * * . $HOME/.bash_profile;$HOME/dbadmin/scripts/rman_trun_arch.sh 我们来看看脚本的内容。我贴出关键的部分。 可以看出归档的删除过期归档,保留时间是10个小时之内,其实已经算是很短的了。保留近半天的归档而已。 rman target / <<EOF CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; crosscheck archivelog all; delete noprompt expired archivelog all; delete noprompt archivelog until time "sysdate-10/24"; exit EOF 如此频率下怎么还会有这类问题。看看当前闪回区的情况。

可以看到已经存在300多个归档。 这问题确实有意思了,有大量的归档,有频繁的删除策略,但是闪回区还报错。 我们来换个姿势看这个问题,就是查看归档频率。

这个脚本的强大的之处就在于可以查看近2周的归档频率,通过这种方式就可以看出这个问题其实是一个周期性的。在周二会定期出现,只是之前没有引起重视而已。 可以看到每个小时的归档频率极高,按照这种情况,6个小时就会积累300多个归档,一个归档日志成员是1G来算,那么这个归档量就很大了。 一个统计库怎么这么忙,这是一个问题,我们来看看数据库的负载情况。

可以看到在早间的时候数据库的负载还是有很大的提升。 那么这个时间段内是否有SQL引起的如此的变化,比如一个AWR报告,比如一个脚本就能够定位。 当然抓到罪魁祸首是关键,我是使用脚本来做,抓到了下面的语句。发现了不少负载高的查询语句。

进一步定位,发现都有千丝万缕的关键,那就是其中一个存储过程调用,会调用里面的一些SQL语句。 最终发现SQL语句是这样的形式 SQL_FULLTEXT ---------------------------------------------------------------------------------------------------- UPDATE TESTINFO A SET A.MAX_LEVEL = NVL((SELECT USER_CLASS FROM ROLE_CLASS_INFO B WHERE A.GROUPID = B.GROUP_ID AND B.CN_GUID = A.ROLE_GUID), A.MAX_LEVEL) WHERE DRAWED = 'Y' 看这个语句其实逻辑也不复杂,但是如果查看数据量就会发现这个工作量真是太大了,两个表都是亿级的数据量。

按照过滤条件,数据量2亿,过滤得到4千万,都不是小数目,所以全表看来也是一种方案。 SQL> select DRAWED,count(*)from test.testinfo group by DRAWED; D COUNT(*) - ---------- Y 43807108 N 216762221 Elapsed: 00:00:36.17 但是显然这里还是存在一些需要确认的地方,这个语句本该不需运行,至少不应该在统计层面来保证数据的业务逻辑一致性,应该在OLTP系统中就应该保证,所以我的努力方向就是取消这个JOB,这种优化才是最有效的。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-09-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档