1、用户数据库不能登陆,查看警告日志,发现下面的错误:
ORA-19510: failed to set size of 102395 blocks for file "/oradata/gpsdb/archive/1_9410.dbf" (blocksize=1024)
ORA-27037: unable to obtain file status
HP-UX Error: 2: No such file or directory
Additional information: 5
ORA-16038: log 1 sequence# 9409 cannot be archived
ORA-19510: failed to set size of blocks for file "" (blocksize=)
ORA-00312: online log 1 thread 1: '/oradata/gpsdb/redo01.log'
ARCH: Connecting to console port...
2、针对数据库不能归档的问题,首先查询了归档路径的权限和剩余空间的问题:/oradata/gpsdb/archive的权限是755,属主是oracle用户,oracle用户拥有对该路径的所有权限。另外通过bdf命令看到oradata卷的剩余空间所占比例为16%,大小远大于100M归档日志的大小,可见不能归档与权限和剩余空间无关。
3、数据库的警告日志和产生的TRACE文件中的信息说明数据库不能归档是遇到了HP UX ERROR,下面是一段TRACE文件的错误信息:
*** 2007-04-28 00:11:13.153
ARC1: Error 19510 Closing archive log file '/oradata/gpsdb/archive/1_9409.dbf'
*** 2007-04-28 00:11:13.193
kcrrfail: dest:1 err:19510 force:0
ORA-19510: failed to set size of 102398 blocks for file "/oradata/gpsdb/archive/1_9409.dbf" (blocksize=1024)
ORA-27037: unable to obtain file status
HP-UX Error: 2: No such file or directory
对该错误的解读:
错误信息ARC1: Error 19510 Closing archive log file '/oradata/gpsdb/archive/1_9409.dbf'说明归档后关闭归档生成的文件时出错。而原因是unable to obtain file status,之所以不能获取文件的状态则是因为HP-UX Error: 2: No such file or directory
4、几天后应用户要求检查主机上定义的作业,执行crontab –l,得到下面的结果
* * * * 6 /oracle/bin/del_archive.sh
至此真相大白:
有人定义了执行删除归档日志的定时作业,该作业会在每周六的cron进程的每一次调用的时候都执行,因为它没有定义执行该作业的时间点,这样周六的时候该作业会不断执行。
5、联想到上面出现的因为不能获取刚生成的归档文件的状态因而不能关闭归档文件最终导致归档不成功的问题,感觉与该定时作业有关,因为刚刚写完归档日志文件,准备关闭该文件时,该文件被删除了,因而归档总是出错。
进一步查询警告日志文件,发现所有因无法关闭归档文件导致归档不成功错误出现的时间都是周六,而且每个周六都有这样的事情发生。而之所以以前没有发现,在4月28日才发现这样的事情是因为以前周六没有上班,4月28日因为5.1长假的原因上班了。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/85922/viewspace-922136/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/85922/viewspace-922136/