RE: Lengthening backup
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <terrysutton@xxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 7 Jul 2006 17:14:17 -0400
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,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of Terry Sutton
Sent: Friday, July 07, 2006 2:05 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Lengthening backup
I'm having some issues with a client's RMAN backup. They're on Oracle
8.1.7.4, 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
(hs)
ID Wait Event Waits Timouts Waited
Wait
----- ------------------------------------- -------- ------- --------- -----
---
436 CPU time 4157966
436 SQL*Net message from client 9165 0 471612
51
<snip>
Other related posts:
