Re: RMAN Backup Times Anomaly

Are these two dbs also on identical hardware ? how about the wait events for both these rman backup session?

On Jan 2, 2008 1:28 PM, Sam Bootsma <sbootsma_at_georgebrown.ca> wrote:

> 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* <sbootsma_at_georgebrown.ca>
>
>
>

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