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

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

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月份开始的数据增长情况如下:

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

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

原文发表时间:2015-12-28

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏散尽浮华

分布式监控系统Zabbix3.4-钉钉告警配置记录

群机器人是钉钉群的高级扩展功能,群机器人可以将第三方服务的信息聚合到群聊中,实现自动化的信息同步。例如:通过聚合GitHub,GitLab等源码管理服务,实现源...

43650
来自专栏CodingToDie

微信机器人

使用它可以方便的完成 回复消息、搜索好友、被添加自动回复、获取好友信息等功能,当然功能不止于这些,这里我们用到了回复信息功能

1.5K20
来自专栏智能大石头

性能&分布式&NewLife.XCode对无限数据的支持

上周发布了《改进版CodeTimer及XCode性能测试》,展示了NewLife.XCode在性能上的表现。实际上NewLife.XCode是一个很平凡的ORM...

25380
来自专栏程序员的SOD蜜

PDF.NET 数据开发框架 许可限制 框架源码的获取

欢迎使用 PDF.NET 数据开发框架 (Ver 4.0) 关于框架的名字由来          在我设计www.pwmis.cn 站点(原域名已经过期,现在正...

21660
来自专栏FreeBuf

低成本玩转硬件安全(一) | BadUSB on Arduino

引言 鉴于硬件安全对于大多数新人是较少接触的,而这方面又非常吸引我,但是部分专业安全研究设备较高的价格使人望而却步。在该系列中,笔者希望对此感兴趣的读者在花费较...

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

通过外部表改进一个繁琐的大查询 (r8笔记第32天)

今天处理了一个比较有意思的案例,说是有意思,因为涉及多个部门,但是哪个部门似乎都不愿意接。最后还是用了一些巧力,化干戈为玉帛。 问题的背景是这样的,业务部门需要...

34190
来自专栏程序员互动联盟

数据库常见的图形工具有哪些?

疑惑一 MySQL常用的图形化管理工具有哪些? 现在随着PHP+MySql越来越火,周边相关产品也受到众多人的关注。在PC上修改数据库,查看数据库内容是研发人员...

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

Oracle和MySQL的高可用方案对比(二)

昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。 今天来说下Oracle的DG和MySQL的方案对比,相比来说,可能这方面MySQ...

35850
来自专栏Hadoop数据仓库

HAWQ取代传统数仓实践(十四)——事实表技术之累积快照

一、累积快照简介         累积快照事实表用于定义业务过程开始、结束以及期间的可区分的里程碑事件。通常在此类事实表中针对过程中的关键步骤都包含日期外键,并...

46150
来自专栏数据和云

从原理到实践:Oracle 12.2 Sharding技术揭秘

何剑敏 Oracle ACS华南区售后团队,首席技术工程师 曾供职于中国联通信息计费部、卓望数码,系统支撑部首席DBA,负责中国移动全网梦网业务和移动应用商城...

45870

扫码关注云+社区

领取腾讯云代金券