ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次ORA-27037: unable to obtain file status故障的解决

一次ORA-27037: unable to obtain file status故障的解决

原创 Linux操作系统 作者:wwllzpz 时间:2019-05-25 12:24:06 0 删除 编辑

数据库前端用两台solaris服务器(DB1,DB2)做HA,数据文件存放在存储上和NAS上。试过之前没做过切换。目前运行在DB1上。


bash-2.03$ df -k
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c1t0d0s0 20655529 583463 19865511 3% /
/dev/dsk/c1t0d0s4 20655529 1173077 19275897 6% /usr
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
mnttab 0 0 0 0% /etc/mnttab
/dev/dsk/c1t0d0s1 10327372 174681 10049418 2% /var
swap 11325368 8 11325360 1% /var/run
dmpfs 11325360 0 11325360 0% /dev/vx/dmp
dmpfs 11325360 0 11325360 0% /dev/vx/rdmp
swap 11325376 16 11325360 1% /tmp
/dev/dsk/c1t1d0s0 70547482 3920578 65921430 6% /u01
/dev/dsk/c1t0d0s5 10633132 680310 9846491 7% /opt
/dev/vx/dsk/bakdg/bak
143346688 271224 141957696 1% /backup
/dev/null 0 0 0 0% /dev/odm
/dev/vx/dsk/oradg/oravol
141202432 137266680 3905064 98% /oradata
10.10.9.90:/share 249490016 220814088 28675928 89% /ns700

/oradata目录是存储, /ns700是NAS。NAS在远端。有三个数据文件存放在NAS,其他都在/ORADATA上。

由于DB1出现异常,负载很高,达到20。运行vmstat,iostat,sar命令都挂着,没有返回结果。用prstat看,负载达到20,但各个进程的cpu几乎使用为0。查看v$session_wait,发现很多latch free和buffer busy wait. latch free是cache buffers chains.于是把这些进程kill,压力还是没下去,过会又查v$session_wait,没有latch free和buffer busy wait了,但有很多 db sequence read,而且是同一个数据文件上的,于是想查是哪个个数据文件,但运行的sql没有返回结果,一直挂着。

接着想切换到DB2,于是shutdown immediate,但是不行,有进程在执行,只好shutdown abort。 数据库shutdonw 以后再看机器负载,反而变大了,达到了27左右,很是郁闷。

切换到DB2,启动数据库出现错误,看alert.log:

Errors in file /oradata/maildb/admin/umail/bdump/umail_dbw0_5533.trc:
ORA-01157: cannot identify/lock data file 209 - see DBWR trace file
ORA-01110: data file 209: '/ns700/smyxtablespace_log/SMYX_LOG_BAK01.dbf'
ORA-27086: skgfglk: unable to lock file - already in use
SVR4 Error: 11: Resource temporarily unavailable
Additional information: 8
Thu Oct 12 22:03:19 2006
Errors in file /oradata/maildb/admin/umail/bdump/umail_dbw0_5533.trc:
ORA-01157: cannot identify/lock data file 262 - see DBWR trace file
ORA-01110: data file 262: '/ns700/smyxtablespace_log/SMYX_LOG_BAK02.dbf'
ORA-27086: skgfglk: unable to lock file - already in use
SVR4 Error: 11: Resource temporarily unavailable
Additional information: 8
Thu Oct 12 22:03:24 2006
Errors in file /oradata/maildb/admin/umail/bdump/umail_dbw0_5533.trc:
ORA-01157: cannot identify/lock data file 263 - see DBWR trace file
ORA-01110: data file 263: '/ns700/smyxtablespace_log/SMYX_LOG_BAK03.dbf'
ORA-27086: skgfglk: unable to lock file - already in use
SVR4 Error: 11: Resource temporarily unavailable
Additional information: 8
Thu Oct 12 22:03:24 2006
ORA-1157 signalled during: ALTER DATABASE OPEN...

于是查ORA-27086:的解决办法,看到有的人在window下发生过同样的错误,是通过check disk来解决的。就像在solaris下用同样的办法,做磁盘检查 fcsk.但是发生错误的数据文件都是在远程的NAS上,没法做,只能放弃。突然想到出问题的数据文件都是NAS上的,而其他的数据文件都正常,考虑是不是和这个有什么关系。于是想先把问题文件cp到/oradata,再用alter database rename命令 ,看看是否有用。试过之后果然有用,于是想就在NAS上进行cp,按部就班的做剩余的文件,最后数据库OPEN.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/51726/viewspace-65968/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2003-07-10

  • 博文量
    66
  • 访问量
    42679