Re: RMAN impact

Assuming you have Grid Control set up, build a quick service test against any 
of the web apps that the db supports in Grid Control.  
set it to run every 10 minutes or so, and after a few days look at the trend of 
how that web application is performing.

is there a pattern that forms that coincides with the backup window?  
overlaying the backup window on that chart that shows service response time 
would easily show if an actual end user is affected by the backup as well as 
the general load during that time.  

now if the 10 hour backup window is off-peak, than maybe it just off-sets the 
peak usage, but either way, if you have Grid Control already set up, a few 
minutes to build and deploy a test to a beacon

this kind of actual end user experience monitoring is an easy way to tell if 
someone is actually affected.  (other than comparing session traces during on 
and off times, which may or may not reflect the real end user experience due to 
the fact that there are multiple tiers involved)

My personal experience was that 9i RMAN fully consumed the I/O bandwidth of the 
system for incrementals/fulls.  Using the resource manager in the database to 
support a throttled read rate for RMAN led to a series of other issues.  RMAN 
had some support for being able to define limits for read rate for various 
channels (which in turn used resource manager) if performance is deemed to be 
affected.

the more you throttle it back, the longer it takes, its a trade-off. 10 hours a 
day seems excessive though.

<quote>
By default, RMAN uses all available I/O bandwidth to read/write to disk. You 
can limit the I/O resources consumed by a backup job with the RATE option of 
the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands. The RATE option specifies 
the maximum number of bytes for each second that RMAN reads on the channel.
</quote>

Job


----- Original Message ----
From: Dennis Williams <oracledba.williams@xxxxxxxxx>
To: ganstadba@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Sent: Wednesday, October 18, 2006 2:17:57 PM
Subject: Re: RMAN impact


Mike,
 
In the case of what I mentioned, this was definately a "whole-system" review. 
My system admin and myself were very carefully watching server performance 
indicators, and had one hand on the phone in case the users called. 
   Brandon, thanks for a good analysis on what is likely happening behind the 
scenes. And this system was heavily loaded, but not so stressed that a few 
additional FTSs would send things into a tailspin.
 
Dennis Williams

Other related posts: