Re: block chg tracking

  • From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
  • To: Oracle-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 12 Feb 2015 11:05:24 -0600

On Thu, Feb 12, 2015 at 9:37 AM, Mladen Gogala
<dmarc-noreply@xxxxxxxxxxxxx> wrote:
> Well, in my experience, restoring an incremental backup is not a very fast
> operation. To tell the truth, I haven't done it in quite a while.

As part of our operations here, we choose on random application every
week and do a full restore.  So I've spent a lot of time doing
restores over the past few years and have improved our backup
strategies to the point where I have very high confidence in them.
Here are a few numbers from this week's restore (everything is
scripted, so these are pure restore timings):

restore: 1hr 4m
incrementals: 14 min
archivelogs 3 min

In my experience the archivelogs are the biggest variable; this
particular restore had a RPO of monday at 10pm. The full ran friday
night and we use cumulative incrementals.  The incremental ran at 7pm
so there weren't many logs.  For RPO's long after the most recent
incremental, I've seen the archivelogs run almost as long as the
original restore.  I work on databases ranging in size from a few MB
to 5-10 TB.

Personally I don't consider the incremental as "not very fast".
Nothing wrong with more frequent fulls but our recovery times are well
within our RTO's so there's no need for us to try to do anything fancy
or unusual.

> I do remember duplicate database problems in 10G, when BCT was on.

I've heard about issues with older versions too, though I haven't had
any problems yet with our 11g databases related to BCT.

--
http://about.me/jeremy_schneider
--
//www.freelists.org/webpage/oracle-l


Other related posts: