同事早上打电话说数据推不进去,查看日志有报警,让我帮忙解决下.
日志如下:
con=2(OMCSDATA): ORA-01157: cannot identify/lock data file 303 - see DBWR trace file#ORA-01110: data file 303: '/dev/romcs_omcsmd04'
con=1(OMCSDATA): ORA-01157: cannot identify/lock data file 305 - see DBWR trace file#ORA-01110: data file 305: '/dev/romcs_omcsmd05'
con=1(OMCSDATA): ORA-01157: cannot identify/lock data file 305 - see DBWR trace file#ORA-01110: data file 305: '/dev/romcs_omcsmd05'
发现日志涉及到的数据文件为303和305在报错.数据库环境为AIX6.1,RAC采用的是lv+裸设备.
解决过程:
1.首先去检查数据文件的权限
ls -l /dev/romcs*
经检查发现/dev/romcs_omcsmd03,05的权限在第二个节点为非oracle组的,故先把权限改掉
改好权限之后,在权限不对的第二个节点把数据库重启.
2.重启之后,检查alert日志,发现提示305已经正常,但303的状态仍然在报错提示是offline的,于是查询dba_data_files,发现303的online_status的值是recover.
在这儿先检查一下dba_segments中,装在303上面的看看有哪些对象.然后再开始去恢复.
3.对数据文件进行recover
recover datafile 303
在恢复过程中,会用到两个节点的归档日志
在这儿又遇到在操作节点无法正常访问nfs(第2节点的归档通过nfs的方式被第1节点访问),这个地方的报错应该是NFS的配置有问题.可以参考:http://space.itpub.net/13177610/viewspace-675077和http://blog.chinaunix.net/uid-20607558-id-3075762.html. 我偷懒了一下,直接使用的scp方式,把需要的归档传到节点1的归档路径下.
恢复完成之后,再把数据文件online:
alter database datafile 303 online;
online之后再去检查2个节点的alert日志,发现已经正常.