Re: block chg tracking
Date: Thu, 12 Feb 2015 11:05:24 -0600
Message-ID: <CA+fnDAZ1oafS4-_Pj8YXxoS3M47pggmwJuqrAuu9etm_jH-A8g_at_mail.gmail.com>
On Thu, Feb 12, 2015 at 9:37 AM, Mladen Gogala <dmarc-noreply_at_freelists.org> 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 -- http://www.freelists.org/webpage/oracle-lReceived on Thu Feb 12 2015 - 18:05:24 CET