During one of our 11gR2 database restore activity we found below error message in the RMAN “duplicate database command”
channel aux4: ORA-19870: error while restoring backup piece /oraclone/ORCL/rman_clone/ORCL_F_20170605_c1s60alv_1_1 ORA-19504: failed to create file "+DATA3" ORA-15045: ASM file name '+DATA3' is not in reference form ORA-17502: ksfdcre:5 Failed to create file +DATA3 ORA-15081: failed to submit an I/O operation to a disk ORA-27091: unable to queue I/O ORA-27041: unable to open file SVR4 Error: 13: Permission denied
Our Source and target database are on 184.108.40.206 and we ran “duplicate database” command to clone from source to target.
Intriguing thing was restore was not failing for all the data files that were being restored to +DATA3 ASM diskgroup. Some of the data files that were getting restored to this AMS disk group were getting successfully written while some other were producing above kind of error when RMAN restore process was trying to write to this Disk Group.
On verifying further it was found that two new disks were added to this diskgroup +DATA3 earlier in the day.
Next step was to verify what disks were under this disk group +DATA3 (DISKGROUP # 10)
SQL> select DISK_NUMBER,PATH from v$asm_disk where GROUP_NUMBER=10; DISK_NUMBER PATH ----------- --------------------------------- 7 /dev/rdsk/emcpower72a 0 /dev/rdsk/emcpower111a 1 /dev/rdsk/emcpower112a
Running simple “ls -ltr” command on the disks path given above showed that these above paths were pointing to actual disk:
Disk_Number 7 points to>> crw-rw---- 1 oragrid dba 326, 576 Jun 7 11:14 /devices/pseudo/emcp@72:a,raw Disk_Number 0 points to>> crw-r--r-- 1 oragrid dba 326, 888 Jun 7 11:14 /devices/pseudo/emcp@111:a,raw Disk_Number 1 points to >> crw-r--r-- 1 oragrid dba 326, 896 Jun 7 11:14 /devices/pseudo/emcp@112:a,raw
As you can see that two new disks (disk # 0 and 1) that were added to this diskgroup do not have the WRITE permission given to “dba” OS group.
On this system we have two OS user: oracle and oragrid. Oracle manages database and is part of “DBA” group. Now since the two new disks were not given write permission for “DBA” group so ‘oracle’ OS userid was not able to write to above two new disks and RMAN was producing error messages.
After we provided write permission on above two disks, RMAN restore process went fine.
$ chmod g+w <disk_name>
[Post Views: 255]
You can connect with me on LinkedIn.
Latest posts by Brijesh Gogia (see all)
- Performance Tuning Basics 16 : Using SQL Tuning Health-Check Script (SQLHC) - April 1, 2018
- Physical and Logical Block Corruption in Oracle Database - March 10, 2018
- Performance Tuning Basics 15 : AWR Report Analysis - February 6, 2018