今天给客户做文件系统数据文件转移到裸设备上的操作
用RMAN来完成
本来很简单的事情
但是却意外地碰到了下面的错误
RMAN> backup database;
Starting backup at NOV
allocated channel: ORA_DISK_
channel ORA_DISK_: sid= devtype=DISK
RMAN: =============================
RMAN: = ERROR MESSAGE STACK FOLLOWS =
RMAN: =============================
RMAN: failure of backup command at // ::
ORA: internal error code arguments: [] [xDE] [] [library cache] [] [x] [device information] []
ORA: unable to open file
IBM AIX RISC System/ Error: : Not a typewriter
Additional information:
在alertlog中也有相同的ORA报错检查了RMAN要备份的数据文件权限检查了RMAN备份目的地的目录权限检查了数据库启动之后RMAN备份之前的alertlog没有发现任何异常怪哉
Metalink上相关的文章有Note: 和 Bug No
只是简单地描述这是一个只有在AIX平台上才会碰到的问题是因为RMAN在备份过程中查询X$KRBAFF表(KRB is Kernel Backup/Restore AFF is disk and node AFFinity)引起的解决方法是使用diskratio=来进行备份也就是backup命令要改为
backupformatpathdatabasediskratio=;
diskratio参数很少用到它指定的是RMAN从多少块磁盘上读取数据文件默认值跟FILESPERSET参数相同如果不指定FILESPERSET参数那么该参数值是但是RMAN仍然会考虑真正参与备份的磁盘数如果小于那么就选择较小的那个数
更进一步地在内部站点上查一下资料可以看到跟源码中的skgfdlndv()函数有关
只有raw devices才有affinity info而这次的备份牵涉到的文件全部都是文件系统如果对于文件系统调用了ioctl检查affinity info那么就会出现OER()的报错
问题是解决了但是仍然有疑问
是什么操作系统级别的设定(比如内核参数)或者存储级别的设定(比如PV或者VG的参数)导致必须要指定diskratio=才能RMAN备份成功?
