数据库日志中一条"异常"信息所包含的细节

今天在梳理服务器的信息的时候,发现有一台服务器没有设置crontab作业,一般的服务器中可能会需要一些定时的任务来触发一些备份,清理等等工作。
因为这是一台备库机器,上面有11gR2的备库,所以首要工作就是查看是否在正常应用日志。
从日志来看,归档已经正常应用。不过似乎有一些相对陌生的操作在日志里面。
Archived Log entry 68735 added for thread 1 sequence 95373 ID 0x70141a28 dest 1:
Tue Aug 04 16:00:29 2015
Media Recovery Waiting for thread 1 sequence 95374 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 95374 Reading mem 0
  Mem# 0: /U01/app/oracle/oradata/xxxxxx/std_redo04.log
Tue Aug 04 16:22:32 2015
RFS[6]: Selected log 5 for thread 1 sequence 95375 dbid 1880348712 branch 828552874
Tue Aug 04 16:22:32 2015
Deleted Oracle managed file /U01/app/oracle/fast_recovery_area/xxxxxx/archivelog/2015_07_15/o1_mf_1_92947_btbdqpm3_.arc
Tue Aug 04 16:22:32 2015
Media Recovery Waiting for thread 1 sequence 95375 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 95375 Reading mem 0
  Mem# 0: /U01/app/oracle/oradata/xxxxxx/std_redo05.log
Archived Log entry 68736 added for thread 1 sequence 95374 ID 0x70141a28 dest 1:
Tue Aug 04 16:45:30 2015
RFS[6]: Selected log 4 for thread 1 sequence 95376 dbid 1880348712 branch 828552874
Tue Aug 04 16:45:30 2015
Deleted Oracle managed file /U01/app/oracle/fast_recovery_area/xxxxxx/archivelog/2015_07_15/o1_mf_1_92948_btbdqwmt_.arc
Tue Aug 04 16:45:30 2015
Media Recovery Waiting for thread 1 sequence 95376 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 95376 Reading mem 0
  Mem# 0: /U01/app/oracle/oradata/xxxxxx/std_redo04.log
Archived Log entry 68737 added for thread 1 sequence 95375 ID 0x70141a28 dest 1:
按照这个频率,似乎每次接受一次归档,都会触发一次自动的删除就归档的操作。
这个操作很明显不是在crontab中触发的,因为crontab没有启用,就算启用,这些操作也不会同步的如此紧密,数据库日志中不会有这些信息。
带着疑问,查看了一些相关的帖子,其中有一篇文章是老熊写的,http://www.laoxiong.net/oracle-11g-data-guard-archived-log-managemen.html
在文章中还提供了一个metalink的链接解释。
Files being deleted in the flash recovery area, messages in the alert log Deleted Oracle managed file <filename> (文档 ID 1369341.1)
对于这个问题,其实在11gR2开始,Oracle会根据闪回恢复区的大小,设定一个阀值,默认是80%,即如果归档空间的使用率超过80%,则会自动触发删除归档。
可以在当前的环境简单验证。
SQL> SQL> show parameter recover
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /U01/app/oracle/fast_recovery_area                                                 
db_recovery_file_dest_size           big integer 120G
查看闪回区域的使用情况如下:
[fast_recovery_area]$ du -sh ./*
18M     ./hxxxx
96G     ./SHxxxxx
如果细细查看,会发现在近期确实生成了大量的归档文件。
...
3.9G    ./2015_07_23
3.8G    ./2015_07_24
3.9G    ./2015_07_25
3.9G    ./2015_07_26
8.7G    ./2015_07_27
3.9G    ./2015_07_28
4.1G    ./2015_07_29
4.0G    ./2015_07_30
4.3G    ./2015_07_31
4.1G    ./2015_08_01
4.1G    ./2015_08_02
8.9G    ./2015_08_03
3.2G    ./2015_08_04
当然系统级查看似乎还是不够清晰,我们可以用个试图来看看,一目了然。
SQL> select * from V$RECOVERY_AREA_USAGE;  
FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------------- ------------------ ------------------------- ---------------
CONTROL FILE                          0                         0               0
REDO LOG                              0                         0               0
ARCHIVED LOG                      79.98                     79.92            2427
BACKUP PIECE                          0                         0               0
IMAGE COPY                            0                         0               0
FLASHBACK LOG                         0                         0               0
FOREIGN ARCHIVED LOG                  0                         0               0
可以看到现在的使用情况已经达到了79.98%,已经处于触发的临界点了。
对于这个问题,明白了原因,解决起来就容易多了,自己也暗自庆幸这个库是一个11gR2的库,要不然没准我在近期就会收到报警短信了。
删除归档,还是直接用rman来做,可以使用下面的脚本来简单处理,把一天前的归档删除。
rman target / <<EOF
CONFIGURE ARCHIVELOG DELETION POLICY TO applied on all standby ;
crosscheck archivelog all;
delete noprompt expired archivelog all;
delete noprompt archivelog until time "sysdate-1";
exit
EOF

删除后再次查看,空间就释放了不少。
[archivelog]$ du -sh .
4.1G 
如果对于80%这个阀值存在异议,还是可以通过事件19823来触发,比如我们希望把阀值调整为90%
就可以这么设置。
alter system set event='19823 trace name context forever,level 90‘ scope=spfile; 然后需要重启数据库生效。
所以通过这个问题我们看到日志中的一个细小的差别,其实在数据库层面在触发一些工作,这个特性相对来说还是比较合理的一个处理。

时间: 2024-10-24 04:16:48

数据库日志中一条"异常"信息所包含的细节的相关文章

让你提前认识软件开发(28):数据库存储过程中的重要表信息的保存及相关建议

第2部分 数据库SQL语言 数据库存储过程中的重要表信息的保存及相关建议   1. 存储过程中的重要表信息的保存         在很多存储过程中,会涉及到对表数据的更新.插入或删除等,为了防止修改之后的表数据出现问题,同时方便追踪问题,一般会为一些重要的表建立一个对应的debug表.这个debug表中的字段要包括原表的所有字段,同时要增加操作时间.操作码和操作描述等字段信息.         例如,在某项目中,包括了如下一个重要的表tb_XXX: create table tb_XXX (  

提前认识软件开发(28) 数据库存储过程中的重要表信息的保存

1. 存储过程中的重要表信息的保存 在很多存储过程中,会涉及到对表数据的更新.插入或删除等,为了防止修改之后的表数据出现问题,同时方便追踪问题,一般会为一些重要的表建立一个对应的debug表.这个debug表中的字段要包括原表的所有字段,同时要增加操作时间.操作码和操作描述等字段信息. 例如,在某项目中,包括了如下一个重要的表tb_XXX: create table tb_XXX ( AAA varchar(30) not null, -- AAA BBB varchar(30) not nul

Python中捕捉详细异常信息的代码示例_python

大家在开发的过程中可能时常碰到一个需求,需要把Python的异常信息输出到日志文件中. 网上的办法都不太实用,下面介绍一种实用的,从Python 2.7源码中扣出来的. 废话不说 直接上代码,代码不多,注释比较多而已. import sys, traceback traceback_template = '''Traceback (most recent call last): File "%(filename)s", line %(lineno)s, in %(name)s %(ty

为什么tomcat的catalina.log日志中,没有把控制台所有的信息都记录下来

问题描述 如题,控制台报错,打印出了异常信息,但是到logs目录下打开catalina.log文件查看却没有记录,这是什么原因而且以前我见过日志里出现过异常信息,是同一个tomcat,也是同样的环境,没有修改过配置 问题补充:引用 解决方案 我也碰到这样的问题了,由于项目中处理异常的代码比较多,且以前没有用log4j记录,如果修改的话基本上每一个java文件都要修改成log.error("",e)这样的方式才能记录,我采用了这样的方式来记录,虽然不太好,但是应该可以应付过去把tomca

python中使用traceback处理异常信息

近来编写一个程序,该程序可以在设定时间内,获取指定文件夹更新的文件夹和文件列表,并根据获取到的更新列表,做一些操作.由于所写程序是放在服务器上运行,为了保证程序在运行的过程中,不时不时跳出些异常信息出来吓其他用户,就在程序中添加了异常处理.将网上的资料整理下,试着将sys.exce_info()和traceback搭配一起使用.效果还算不错,以下信息是我当前处理异常的方式,其中type是异常的类型,value是出现异常的原因,traceback则是通过traceback追中到的异常信息,能够定位

alert日志中的两种ORA错误分析

今天在巡检系统的时候,发现alert日志中有两种类型的ora错误. Errors in file /U01/app/oracle/diag/rdbms/XX/XX/trace/xxdb_j002_20401.trc: ORA-12012: error on auto execute of job "XXDATA"."S_XXXX_HIST_OPS_SERINFO_K" ORA-12170: TNS:Connect timeout occurred ORA-06512

通过java程序抽取日志中的sql语句

今天在翻看以前的笔记时,发现自己在很早之前写过一个java程序,能够解析日志中的sql语句. 当时使用的环境是weblogic,日志目录下总是有几十上百个日志文件,有时候排查问题的时候只需要找到对应的DML语句即可. 使用linux命令固然也可以,但是解析的时候还是比较被动,不能够正确地解析出sql语句来.比如日志中出现insert的字样可能只是日志中的一段信息,不是insert语句. 这些通过linux命令来完成还是有一定的难度,记得当时问题比较多,自己也饱受这种困扰.于是写了一个java程序

exception-向数据库插数据时到9万条左右发生的异常,找不到原因,下面是具体的异常信息

问题描述 向数据库插数据时到9万条左右发生的异常,找不到原因,下面是具体的异常信息 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at com.mysql.jdbc.PreparedStatement.(PreparedStatement.java:437) at com.mysql.jdbc.Connection.clientPrepareStatement(Connection.java

Perl中捕获警告信息、异常信息并写入日志详解

  这篇文章主要介绍了Perl中捕获警告信息.异常信息并写入日志详解,本文分别给出了捕获警告--不处理.捕获警告--并转换成异常.捕获警告--并写入日志.捕获并写日志的完整例子等实用实例,需要的朋友可以参考下 虽然建议在每个Perl脚本和模块中开启警告,可是你又不想用户看到Perl发出的警告. 一方面你想在代码前面使用use warnings作为你的安全网,另一方面,通常警告会出现在屏幕上.多数情况下,客户不知道如何处理这些警告.如果幸运的话这些警告仅仅让客户惊讶一下,当然,不幸的是他们尝试着去