Re: Tuning RMAN backup and recovery

See my answers inline below. Thanks again for all the help!

On Nov 16, 2007 2:47 AM, Greg Rahn <greg_at_structureddata.org> wrote:
> What are the disk stats during the backups (from iostat)? Some things
> I would investigate:
> - are the target drives saturated?
> - are the I/O channels saturated?

I presume these things can only be known during backup times. Any special parameters to pass to iostat to get the specific information for these questions? Should I take a sample every hour during the level 0?

> - do /rman and the db file luns share physical spindles? (hopefully not)

Right now they do actually. It is a temporary situation until we can move some more disk around in Jan/Feb 2008. Perhaps any real investigation is moot until we get it isolated?

To Brandon: /rman is RAID 10.

> I would suggest that you should have N luns where N is the number of
> parallel streams. This allows N I/O SCSI queues to be simultaneously
> serviced vs. one. Think of this like more check out lanes at the
> grocery store.

So this would be something like /rman1, /rman2, /rman3, /rman4 when I have parallelism=4? I presume I need to configure the individual channels then to each write to one of those locations. Perhaps I'm confusing terms.

> Compression has the CPU overhead, but reduces the IO bandwidth and
> storage space requirement. If you are not I/O bound (or space) then
> it won't provide any visible performance gains - it will just consume
> more CPU. It's basically a trade off.

Just to confirm, last night's level 1 backup saw a load as high as 22.43. I'll try to get I/O readings this weekend.

> Ultimately you want the target writes to be the bottleneck, but
> operating at optimal efficiency.

I assumed as much, I just want to make sure that the bottleneck is as wide as can be. ;)

To Alex G:
I'll try to get 10046 traces as well this weekend.

-- 
Don Seiler
http://seilerwerks.wordpress.com
ultimate: http://www.mufc.us
--
http://www.freelists.org/webpage/oracle-l