两条报警信息的分析(第二篇)

还是继续分析报警信息的关联,下面两个看似没有直接联系的报警信息其实很有关联。
下面是主库的报警的信息,查看v$dataguard_status得到了最新的错误信息。
#############################
[DB监控系统]_adb2_p@10.127.xx.19_报警
ZABBIX-监控系统: 
------------------------------------
报警内容: DG_issue
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: dg_issue:2015-09-26 03:52:00.0Log Transport ServicesErrorError 12514 received logging on to the standby2015-09-26 03:52:00.0Log Transport ServicesErrorPING[ARC1]: Heartbeat failed to connect to standby '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxx.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=sadb2_XPT)(INSTANCE_NAME=adb2)(SERVER=dedicated)))'. Error is 12514.2015-09-26 03:52:02.0Log Transport ServicesErrorError 12514 received logging on to the standby2015-09-26 03:52:02.0Fetch Archive LogErrorFAL[server, ARC1]: Error 12514 creating remote archivelog file '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=sadb2_XPT)(INSTANCE_NAME=adb2)(SERVER=dedicated)))' 
------------------------------------ 
报警时间:2015.09.26-03:53:09

下面是相邻时间段里备库的报警信息
[DB监控系统]_acb2_s1@10.127.xx.29_报警
ZABBIX-监控系统: 
------------------------------------
报警内容: Free disk space is less than 20% on volume /opt
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: Free disk space on /opt (percentage):9.82 % 
------------------------------------ 
报警时间:2015.09.26-03:28:57

这两条信息看似没有必然的关联,我们来分析一下原委,看看怎么解决这个问题。
既然提示备库有问题,我们来看看备库的日志信息。
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1750]: Assigned to RFS process 3676
RFS[1750]: Identified database type as 'physical standby'
RFS[1750]: Archived Log: '/U01/app/oracle/admin/adb2/arch/1_7751_782793360.dbf'
Sat Sep 26 03:14:46 CST 2015
Stopping background process MMNL
Sat Sep 26 03:14:47 CST 2015
Stopping background process MMON
Sat Sep 26 03:14:48 CST 2015
SMON: disabling cache recovery
Sat Sep 26 03:14:50 CST 2015
Starting background process MMON
Sat Sep 26 03:14:50 CST 2015
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  NODELAY
Starting background process MMNL
MMON started with pid=11, OS id=20676
Sat Sep 26 03:14:50 CST 2015
Attempt to start background Managed Standby Recovery process (adb2)
MMNL started with pid=20, OS id=20678
MRP0 started with pid=21, OS id=20680
Sat Sep 26 03:14:50 CST 2015
MRP0: Background Managed Standby Recovery process started (adb2)
Managed Standby Recovery not using Real Time Apply
 parallel recovery started with 15 processes
Sat Sep 26 03:14:56 CST 2015
Waiting for all non-current ORLs to be archived...
Media Recovery Log /U01/app/oracle/admin/adb2/arch/1_7751_782793360.dbf
Sat Sep 26 03:14:56 CST 2015
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  NODELAY
Sat Sep 26 03:14:59 CST 2015
Media Recovery Waiting for thread 1 sequence 7752
Sat Sep 26 03:21:38 CST 2015
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1751]: Assigned to RFS process 21848
RFS[1751]: Identified database type as 'physical standby'
RFS[1751]: Archived Log: '/U01/app/oracle/admin/adb2/arch/1_7752_782793360.dbf'
Sat Sep 26 03:21:39 CST 2015
Media Recovery Log /U01/app/oracle/admin/adb2/arch/1_7752_782793360.dbf
Media Recovery Waiting for thread 1 sequence 7753
单纯看日志没有发现相关的ora错误。
查看备库的文件系统信息。可以看到分区/opt的空间目前是正常的,说明在之后空间得到了释放。
$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             5.9G  959M  4.6G  17% /
/dev/sda3             7.5G  6.2G  943M  88% /var
/dev/sda5              12G  2.7G  8.1G  25% /usr
tmpfs                  32G  8.0K   32G   1% /dev/shm
/dev/shm               32G  8.0K   32G   1% /tmp
/dev/sda7             495G  352G  118G  75% /opt
好了,问题背景交代完了,我们这个时候就来分析一下,这个问题在最近每天都会存在,时间段固定,可以断定这是一个scheduler或者crontab之类触发的。
而数据备份在备库中,crontab更加现实一些,因为这个库是10g的库,还在mount阶段。
所以查看了crontab,发现确实在特定的时间段存在一个备份任务。这是一个使用datapump的逻辑备份。
因为这个库也不算大,但是数据还是比较重要,在有些数据误删除的情况下,还可以根据需要做一些对应的数据恢复工作,所以采用了逻辑备份的方式做了一次全备。
查看base目录下的空间使用情况,发现备份集的数据比数据库数据文件的还要大一些。这个似乎也不太合理。
$ du -sh ./*
182G    ./backup_stage
169G    ./oracle
12M     ./oraInventory
oracle目录下的文件如下:
oracle]$ ll
total 12
drwxrwxr-x 3 oracle oinstall 4096 Feb 19  2014 admin
drwxr-xr-x 3 oracle oinstall 4096 May 14  2012 oradata
drwxrwxr-x 5 oracle oinstall 4096 Jul 30 11:08 product
查看之后发现backup_stage下存放的是近两天的备份内容,也就是近两天的数据备份都可以根据需要进行恢复。
那么crontab是怎么配置的呢?
30 1 * * * . $HOME/.adb2profile;$HOME/dbadmin/scripts/expdpfull.sh
这个重要的脚本的内容如下:
less $HOME/dbadmin/scripts/expdpfull.sh
#!/bin/bash
. ~oracle/.bash_profile
home=~oracle
export home
lexphome=/U01/app/backup_stage/exp
export lexphome
expfile=${ORACLE_SID}_`date +%Y%m%d`
export expfile
dgmgrl / "edit database sadb2 set state='READ-ONLY'"
  if [ $? -ne 0 ]; then
  echo "set read-only failed!"
  exit 1
  fi
sleep 60
exp \'/ as sysdba\'  parfile=$home/dbadmin/scripts/dbexp_full_adb2.par log=$lexphome/${expfile}.log
dgmgrl / "edit database sadb2 set state='ONLINE'"
if [ $? -ne 0 ]; then
echo "set online failed!"
exit 1
fi
find $lexphome/ -name '*.dmp' -mtime +1 -exec rm -f {} \;

所做的工作大体如下,取消备库的日志应用,然后把数据库置为read-only状态,然后做逻辑备份,备份完成之后把备库开启日志应用,然后删除前一天的备份。
流程和思路应该看不出什么问题吧。
但是这个问题仔细琢磨了下,觉得还是哪里不对劲,但又说不出。最后仔细揣摩了一番,发现这个流程其实还是可以做改进的。
打个比方,磁盘剩余空间又160G,每天的备份大概是50G,这样每天备份完成删除之后就会剩余60G的空间,
如果按照现有的流程来做,就是下面的形式
开启逻辑备份 50G, 已有近两天的备份100G,那么剩余空间就是160G-50G*2-50G=10G
如果是这种情况,就会出现空间的紧缩和抖动。使用zabbix查看近期的空间紧缩情况确实就是这样的情况

我们可以做这样一种优化,即开始备份前,删除前两天的一个备份,然后开始当天的备份,这样,备份就始终是两个,空间使用率反而还会短期扩张。
明白了思路,解决起来就轻松很多,可以直接在备份前开始清理前两天的一个备份。
脚本内容如下:
less $HOME/dbadmin/scripts/expdpfull.sh
#!/bin/bash
. ~oracle/.bash_profile
home=~oracle
export home
lexphome=/U01/app/backup_stage/exp
export lexphome
expfile=${ORACLE_SID}_`date +%Y%m%d`
export expfile
find $lexphome/ -name '*.dmp' -mtime +1 -exec rm -f {} \;
dgmgrl / "edit database sadb2 set state='READ-ONLY'"
  if [ $? -ne 0 ]; then
  echo "set read-only failed!"
  exit 1
  fi
sleep 60
exp \'/ as sysdba\'  parfile=$home/dbadmin/scripts/dbexp_full_adb2.par log=$lexphome/${expfile}.log
dgmgrl / "edit database sadb2 set state='ONLINE'"
if [ $? -ne 0 ]; then
echo "set online failed!"
exit 1
fi
find $lexphome/ -name '*.dmp' -mtime +1 -exec rm -f {} \;
这样空间使用就会始终保持在基线之上,达到一个相对合理的状态。
明白了这一点,再来看看我们所说的报警,主库的v$dataguard_status中有这样一段内容,Error 12514 creating remote archivelog file '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=sadb2_XPT)(INSTANCE_NAME=adb2)(SERVER=dedicated)))' 
大体意思就是从主库发送归档到备库失败,无法创建,无法创建的原因应该就是空间问题,但是备库的空间马上又释放了,所以从日志中还没有体现出来。
所以在空间有限的情况下我们进行流程的优化,达到的效果还是一致的。

时间: 2024-10-23 18:22:38

两条报警信息的分析(第二篇)的相关文章

两条报警信息的分析(第一篇)

任何规则都是固定的,但是人是活的,很多时候把一些细节之处结合起来,还是能够发现一些潜在的问题. 早上收到zabbix的报警,是两条看似很平常的短信. 一封邮件内容如下,这是一封报警邮件 报警内容: Free disk space is less than 20% on volume /U01 ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: Free disk

由一条报警信息发现的一系列问题

今天看到一条报警短信,提示是某个表空间的问题. ZABBIX-监控系统: ------------------------------------ 报警内容: Tablespace Usage warning ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: showtsps:-->TS_NAME:UNDOTBS1 :4.8% Free -----------

服务器进程异常的原因分析(第二篇)

最近看到一个报警,是显示某一个oracle的备库进程数达到了2000多个.ZABBIX-监控系统: ------------------------------------报警内容: Too many OS processes on ora_xxx@10.127.13.123 ------------------------------------报警级别: PROBLEM ------------------------------------监控项目: Number of processes

android emulator虚拟设备分析第二篇之pipe

一.概述 qemu pipe也是一个虚拟设备,是一个通用的虚拟设备,用于提供guest os和emulator通信的功能,类似于一个抽象的通信层,这样就不用写很多虚拟设备了. 之前在guest os中有个qemud进程,也是干这个事的,使用虚拟设备ttyS1提供guest os和emulator通信的功能,速度比较慢,已被pipe所替代. 看本篇之前,必须看完第一篇:看完本篇,然后看第三篇,这两个是结合在一起的,都看完后建议回顾一下本篇. 基于通用的数据通信pipe,emulator提供了四种服

一条简单的报警信息发现的oracle bug

系统中有这样一条报警信息,看似比较简单,但是引起了我的注意,主要原因是因为这是一个10gR2的备库,备库如果出现这样的问题,看起来似乎是在归档删除上存在一些问题. [DB监控系统]_ora_test_s2_yangjr@10.127.2.133_报警 ZABBIX-监控系统: ------------------------------------ 报警内容: Free disk space is less than 20% on volume /opt --------------------

一则orabbix报警的分析(第一篇)

最近使用zabbix监控之后,都会在凌晨收到1台数据库服务器的报警短信,报警的内容为: No data received from Orabbix 这个错误其实就是orabbix通过jdbc已经接受不到数据库实例的信息了,但是隔了10来分钟之后,又会收到问题恢复的短信. 既然问题已经自动修复了,可能在那个时间段里有一些固定的操作,操作完成之后,数据库实例的负载就自动恢复了. 可以从监控DB time的趋势图中看出一些端倪. 根据提示的信息查看了问题时间段的awr和对应ash报告. 先来看awr报

php做ios推送的服务器,后台运行的时候会推送两条信息?有代码

问题描述 php做ios推送的服务器,后台运行的时候会推送两条信息?有代码 为什么php做ios推送的服务器的时候,后台运行的时候会推送两条信息?但是手机关掉屏幕推送的时候就正常了~ 就只有后台运行的时候是两条?? 怎么改呢? 下面是代码 /** 手机推送信息类 @author:wtt */ class Push{ private $deviceToken; private $message; function __construct($deviceToken,$message){ $this-

AMiner发布计算机领域知识图谱,包括20多万条专家信息、50多万篇出版论文

日前,清华大学副教授.Arnetminer创始人唐杰在微博公开表示AMiner将发布计算机领域的专业知识图谱Science Knowledge Graph (SciKG). 据其介绍, 这个计算机领域的知识图谱包含1万个知识概念.概念关系以及概念定义,20万专家信息(专家和知识概念对应)以及50万相关论文.这个数据可以用来做一些领域信息理解,信息推荐和检索. 雷锋网 AI 科技评论了解到,AMiner官网目前已经更新了该数据集的下载通道. 从官网可以看到相关介绍, SciKG是一个丰富的知识图谱

备库报警邮件的分析案例(二)

在第一篇中分享了关于备库报警邮件的分析,发现很多问题都是一环扣一环. 起初是通过监控主库中的v$dataguard_status发现备库中可能存在一些问题,结果逐步分析,发现是由备库的crontab触发了备库的定时read-only和online状态,(即只读和应用日志,10gR2的环境),而这些关键信息都是从数据库的alert日志中发现的,但是问题还没有完,才刚刚开始,因为发现备库中竟然有ORA-1652: unable to extend temp segment by 128 in tab