Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Lengthening backup

RE: Lengthening backup

From: Mark W. Farnham <>
Date: Fri, 7 Jul 2006 17:14:17 -0400
Message-ID: <>

An interesting data point would be the wait stats after a bounce and, say, 12.25 hours into the backup. Then double the CPU wait time and compare it to the nearly half a day (86400/2 is 43200, right?) you waited for CPU in the 24.5 hour backup.

If the number is similar (after doubling), then that is apples and apples and you just have a system that is too busy (but that is unrelated to the degradation of the backup duration.)

On the other hand, if the numbers are far apart you need to figure out why the machine is much less busy after a bounce. Your mileage may vary, but usually this indicates that you have runaway jobs that are grinding CPU. Load average and a ps or top to see who is grinding CPU might be helpful. If you can determine it is safe to snipe runaways, you might not have to bounce to return to acceptable performance.

Still, this is probably not the entire problem, since half of 48 is 24, and that is still a lot more than the 15 you are shooting for. And of course single measurements are nothing to bet the ranch on.

Fuad’s comment about multiple ora_i’s and Andy’s comment about possibly including a growing amount of archived redo in the backup seem likely candidates.

Good luck,


-----Original Message-----
From: []On Behalf Of Terry Sutton
Sent: Friday, July 07, 2006 2:05 PM
Subject: Lengthening backup

I'm having some issues with a client's RMAN backup. They're on Oracle, Solaris 8. It's a weekly full backup, and they're backing up
~1.5TB to disk, and the longer the instance is up, the longer the backup
takes. A recent progression has been:

Week 1: 15 hours
Week 2: 16 hours
Week 3: 19 hours
Week 4: 21 hours
Week 5: 25 hours

Week 15: 48 hours

But when we bounce the database, the length of time to backup goes back to
~15 hours. The database size fluctuates a bit, with a bit of an upward
trend, but not with a significant change in size.

One time, when the backup had been running for 24.5 hours, I checked the session stats for the session on the database which is performing the backup, and these were the stats:

 Sess                                          Total   Total Time (hs) Avg
   ID Wait Event                               Waits Timouts    Waited
----- ------------------------------------- -------- ------- --------- -----
  436 CPU time                                                 4157966
  436 SQL*Net message from client               9165       0    471612
Received on Fri Jul 07 2006 - 16:14:17 CDT

Original text of this message