Re: Slow 'alter tablespace begin backup'

andy_pennington_at_yahoo.com (Andy Pennington) wrote in message news:<60313e96.0312172149.32ba7799_at_posting.google.com>...
> What influences the time taken for the 'alter tablespace begin backup'
> statement?
> Until a couple of weeks ago, I could get my entire database (50
> tablespaces, 1TB) into backup mode in about 10-15 minutes, but then
> all of a sudden it started taking 45-50 minutes to do the same action.
> The only change I am aware of which coincided, was an increase by 4GB
> (from 12GB to 16GB) in the data cache (db_block_buffers). I am
> interested to understand what actually happens as the 'begin backup'
> statement is executed. What does it wait for?

It has to be sure there aren't any "split blocks," that is, Oracle blocks that are only half updated because the copy spans two OS blocks while Oracle is updating them. RMAN knows about making consistent blocks so it doesn't have this problem.

It also has to checkpoint, flush dirty blocks to disk, so that might explain some of the difference (especially since there might be proportionally more dirty blocks after increasing the SGA).

Also, any blocks being changed during the hot backup need to be entirely written to the redo logs, rather than just changes vectors, which can of course impact performance.

jg

--
@home.com is bogus
http://msnbc.msn.com/Default.aspx?id=3540652&p1=0