Re: Slow 'alter tablespace begin backup'

So, to replay this: its the checkpointing which is taking longer (approximately 1 minute for each tablespace).

The thing that confuses me is that immediately prior to the 'begin backup' statements, there is a log switch, so I would have thought this would have already checkpointed the database, flushing all the dirty blocks etc, leaving only a few to flush when the begin backup statements start. Is this not the case?

Can I shorten this checkpointing period, perhaps by forcing a checkpoint earlier, or by somehow otherwise flushing the dirty blocks?

By the way, many thanks for your responses so far, guys.

Andy.

joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0312181652.5fb18236_at_posting.google.com>...
> 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
Received on Fri Dec 19 2003 - 11:25:52 CST