Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Slow RMAN Backups

Slow RMAN Backups

From: Naqi Mirza <>
Date: Thu, 17 Aug 2006 23:51:16 -0700 (PDT)
Message-ID: <>


I was wondering whether anyone has experienced poor backup times with oracle databases on RAID 5? We are using netbackup in conjunction with rman to backup a 1.5TB database that takes about 16 hours to complete. A host of rman parameters have been tried - combinations of filesperset and maxopenfiles - with no benefit seen. Our database uses RAID 5 spread over about a 100 disks. We have noticed that no matter what we do the maximum throughput for the backup is only 50mb/s. We are using an LTO3 tape library which can write at 60mb/s per tape drive. But no matter how many tape drives we allocate for use (we use 3 channels - 3 drives) we only get 50mb/s as the total throughput - resulting in a backup that is over 16 hours. What happens is, if one channel is allocated the throughput for that might be around 50mb/s, when a second channel is allocated, the total throughput remains around 50mb/s which is distributed over the two channels. Adding a third gives no benefit as the  50mb/s throughtput is then distributed over all three channels. I have monitored v$backup_aysnc_io and have noticed that there is for the most part poor read rates as seen by the effective_bytes_per_second for TYPE='INPUT'. From that I can only infer that the slower the read done by rman the slower the backup will be - I do not see any problem with respect to writes to the tape drives - they will write as fast as they recieve data. We have seen with a filesystem backup we are able to achieve a rate of about 100mb/s - although this type of backup is different to an rman backup there is quite a difference seen in the rate. Just wondering if there is someway to work out if the RAID configuration could be the issue here and whether the diskratio parameter might be a viable option to try. Thanks

Received on Fri Aug 18 2006 - 01:51:16 CDT

Original text of this message