Re: Difference Between RMAN Incremental and Full Backups - Driving me Nuts!

  • From: "David Barbour" <david.barbour1@xxxxxxxxx>
  • To: "Jared Still" <jkstill@xxxxxxxxx>
  • Date: Thu, 17 Jul 2008 14:43:39 -0400

Makes sense.  I bet the issue with blowing out the read cache comes into
play.  I've put forth the suggestion we run an additional full backup during
the week and skip the incrementals until we can get the databases upgraded.
I have been relying on the archive logs, but if I have an issue towards the
end of the week, applying those puppies can takes up to 36hrs.

On Thu, Jul 17, 2008 at 1:04 PM, Jared Still <jkstill@xxxxxxxxx> wrote:

> On Thu, Jul 17, 2008 at 7:20 AM, David Barbour <david.barbour1@xxxxxxxxx>
> wrote:
>> Incremental backup (Level 1):  System slows to a crawl.  People complain.
>> Jobs take hours longer than expected (it's like they don't even start until
>> the backup completes).  Statspack snapshot covering period when backup is
>> running shows top 5 timed events as follows:
>> ...
>> What is the difference between disk access for the two types of backups?
> Level 0 incremental (full)
> Oracle fills the buffer, sends it to tape
> Level 1 incremental
> Oracle scans files looking for blocks.  When the buffer is full
> it is sent to tape
> Here's what I suspect is occurring:
> During the level 1 backup not a lot of changed blocks are being found,
> and Oracle is reading through datafiles as fast as possible.
> eg. io rates go up a lot.
> When doing a level 0, there are many more waits when writing to tape,
> and RMAN is not reading disk as often.
> Could be that level 1 backups are also killing the read cache on your IO
> system
> due to RMAN scanning the datafiles with far fewer interruptions for tape
> writes.
> Possible solutions?
> *Less frequent level 1 backups.
> Determine how many archive logs are being generated between
> Level 1 backups, perhaps you can rely more on the archive logs
> for recovery and reduce the frequency of Level 1 backups.
> This would be at the cost of recovery time however.
> *Upgrade to 10gR2 and use Block Change Tracking
> BCT was introduced in 10gR1, but was not fully baked until R2
> --
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist

Other related posts: