前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一次归档报错的处理和分析(r7笔记第60天)

一次归档报错的处理和分析(r7笔记第60天)

作者头像
jeanron100
发布2018-03-16 17:41:32
6030
发布2018-03-16 17:41:32
举报
文章被收录于专栏:杨建荣的学习笔记

昨天在睡觉前接到了一条报警短信,本来已经疲倦的身轻如燕,但是看到报警,还是警觉了起来

ZABBIX-监控系统: ------------------------------------ 报警内容: DG_issue ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: dg_issue:2015-12-27 00:35:17.0Log Transport ServicesErrorARC0: Encountered disk I/O error 195022015-12-27 00:35:17.0Log Transport ServicesErrorARC0: I/O error 19502 archiving log 1 to '/U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_27/o1_mf_1_71969_c7xjg564_.arc' ------------------------------------ 报警时间:2015.12.27-00:35:22

登录到主库,看到磁盘空间确实已经满了。使用普通的DB用户已经登录不了了。几个和磁盘空间相关的分区情况如下。当时/dev/sdb还剩下不到2G。 Filesystem Size Used Avail Use% Mounted on /dev/sda8 243G 103G 129G 45% /home /dev/sdb 1.7T 1.6T 29G 99% /U01 对于这个问题,自己为了火速进行处理,就从/U01下面开始找文件进行清理,首要就是找归档文件,但是失望的是发现归档文件现在确实也不多了。而且目前的 归档删除策略也是半个小时删除一次。截止到问题发生的时候,归档文件只有4个,而且也是半个小时内生成的,就算删除了也腾不出多少空间,更关键的是还需要 到备库去查看是否归档已经接受。所以简单确认之后从主库删除了已经被备库应用的归档,省下来1个G多一点的空间,问题暂时解决了,就开始从其他目录查看是 否还有更多的空间清理,但是发现除了一些历史的日志,其实可清理的空间也就不到1G. 所以这个时候问题很可能再次发生,需要马上进行处理。 从目前的情况来看/U01下的空间确实屈指可数,改进空间已经不大了。那么还有一个分区就是/home大概还有几百个G还能勉强应付一下。 这个时候一种方法就是把归档路径直接切换到/home分区下,但是这种变更很快会导致dg broker报警,为了减少给监控同学更多的解释和对系统本身的影响,我决定下临时把归档目录切过去。 比如今天是12月27日,就在/home/下生成一个软链接,比如我现在给自己几天的buffer时间,这部分的100多G的空间就先在这个目录下刷新,不会有太大的抖动。 [oracle@tlbb3dbidb arch]$ ll lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:17 2015_12_27 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_27 lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:21 2015_12_28 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_28 lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:22 2015_12_29 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_29 lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:22 2015_12_30 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_30 当然这个问题为什么没有早点发现,其实很早就发现了,但是对于这个统计库的空间问题,阀值设置为90~95%,但是老是报警,而且又没有更多的空间就搁置下来了。所以先这样处理,自己也好协调跟进。 当然回过头来,这么多空间都消耗在哪里了。可以从下面的图形看出,其实最近的归档切换频率在凌晨会有一个小高峰,应该是批量的数据处理。之后基本趋于稳定。

所以对于这个问题的更深一层的分析,就是如果空间的消耗在逐渐增大,那么这个空间的消耗瓶颈在哪里。 其实想得到这个结果,也是分分钟就会有结果。直接从dba_segments里面查找即可。可以看到下面的几个表的空间占用极高。 segment_name segment_type bytes_MB LOGIN_LOG TABLE PARTITION 103331 M_START_LOG TABLE PARTITION 117842 MOL_TIME INDEX PARTITION 120922 M_ONLINE_LOG TABLE PARTITION 809661 这个M_ONLINE_LOG竟然占用了近800多个G,作为一个分区表而言数据量也着实惊人。 那么这部分数据是不是历史数据太多了呢,发现数据量也是在逐渐递增,而且都是近半年的数据。没有之前的历史数据了。 分区从4月份开始的数据增长情况如下:

看来最近的数据增长情况还在不断递增,所以这个问题还是有很多的确认之处,是否需要这么多的数据,如果确实需要,需要进一步考虑挂载新的分区,如果只是需要部分的数据,那么就需要考虑一个持久的数据清理方案。夜深了,看看手机,应很晚了。工作是干不完的,睡觉睡觉。

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

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

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
短信
腾讯云短信(Short Message Service,SMS)可为广大企业级用户提供稳定可靠,安全合规的短信触达服务。用户可快速接入,调用 API / SDK 或者通过控制台即可发送,支持发送验证码、通知类短信和营销短信。国内验证短信秒级触达,99%到达率;国际/港澳台短信覆盖全球200+国家/地区,全球多服务站点,稳定可靠。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档