RMAN Backup Times Anomaly

We have two almost identical databases - both cloned in November from the same database. While troubleshooting a problem related to the RMAN backup of one of the databases, I discovered the backup time for one of the backup pieces was vastly different for the two databases. For one database, the backup time was 9 minutes, for the other it was 34 minutes. The files backed up in this backup piece were the same and the sizes were almost exactly the same too. Can anybody suggest why backup of the same data takes so much longer with DEVL then with TEST, for the first backup piece? Thanks for any suggestions!  

Here are more details

• We have databases B, and C.
• B was cloned from database A on November 7/07.
• C was cloned from database A on November 9/07.
• We do a full RMAN backup of B and C to tape once a week on Sunday (a low activity period). These backups are generally successful.
• The backups occur at different times and do not overlap
• We consistently receive a "Touchnet" error during the backup of C. This Touchnet error is NOT an RMAN error, but an error from another application.
• We believe this Touchnet error is occurring because the RMAN backup of C is hogging all the CPU leaving the Touchnet related process CPU-starved.
• We rarely or never encounter the Touchnet error during the full RMAN backup of B.
• I switched the backup times of B and C, and for about 3 weeks we did not receive the Touchnet Error
• The past two Sundays we received the Touchnet Error again.

I reviewed the RMAN log files for the most recent RMAN backup and discovered:

• On C, the first backup (piece 1) using channel 2 took almost 34 minutes
• On B, the first backup (piece 1) using channel 2 took just over 9 minutes
• In total, there were 14 backup pieces in each database
• The time differences between B and C for the other backup pieces are much closer together.

I suspect the lengthy backup time for the first backup piece on C may be related to the Touchnet Errors we receive.  

I confirmed the files backed up in this piece were the same in both cases. And the file sizes are almost identical:

select file#, name, bytes/1024/1024 MB, status

from v$datafile

where file# in (18,17,26,27)  

system_at_C> /  

     FILE# NAME                                             MB STATUS

---------- ---------------------------------------- ---------- -------

        17 /san1/oradata/C/help01.dbf                   200 ONLINE

        18 /san1/oradata/C/index01.dbf                12047 ONLINE

        26 /san1/oradata/C/mercury01.dbf             148.75 ONLINE

        27 /san1/oradata/C/banaq01.dbf                  120 ONLINE

 

system_at_B> /  

     FILE# NAME                                             MB STATUS

---------- ---------------------------------------- ---------- -------

        17 /san1/oradata/B/help01.dbf                   200 ONLINE

        18 /san1/oradata/B/index01.dbf                11883 ONLINE

        26 /san1/oradata/B/mercury01.dbf             148.75 ONLINE

        27 /san1/oradata/B/banaq01.dbf                  120 ONLINE

 

Can anybody suggest why backup of the same data takes so much longer with C then with B, for the first backup piece? Thanks for any suggestions!    

Sam Bootsma

Oracle Database Administrator

Information Technology Services
George Brown College

Phone: 416-415-5000 x4933
Fax: 416-415-4836
E-mail: sbootsma_at_georgebrown.ca <mailto:sbootsma_at_georgebrown.ca>  

--
http://www.freelists.org/webpage/oracle-l