今天給客戶做文件系統數據文件轉移到裸設備上的操作
用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命令要改為
backup format path database diskratio=;
diskratio參數很少用到它指定的是RMAN從多少塊磁盤上讀取數據文件默認值跟FILESPERSET參數相同如果不指定FILESPERSET參數那麼該參數值是但是RMAN仍然會考慮真正參與備份的磁盤數如果小於那麼就選擇較小的那個數
更進一步地在內部站點上查一下資料可以看到跟源碼中的skgfdlndv()函數有關
只有raw devices才有affinity info而這次的備份牽涉到的文件全部都是文件系統如果對於文件系統調用了ioctl檢查affinity info那麼就會出現OER()的報錯
問題是解決了但是仍然有疑問
是什麼操作系統級別的設定(比如內核參數)或者存儲級別的設定(比如PV或者VG的參數)導致必須要指定diskratio=才能RMAN備份成功?
From:http://tw.wingwit.com/Article/program/Oracle/201311/18795.html
