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_at_gmail.com>
To: ganstadba_at_hotmail.com
Cc: oracle-l_at_freelists.org
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
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 18 2006 - 13:58:09 CDT
