RE: block chg tracking

From: Powell, Mark <>
Date: Thu, 12 Feb 2015 14:57:18 +0000
Message-ID: <>

I am not sure I agree with the following logic: "With a really big DB, overhead of restoring several incremental backups becomes unacceptable. I don't know the sizes of your databases and the SLA time specified to bring them back, but chances are that restoring several incremental backups will take significant amount of time."

With a large database just restoring the files will take a large amount of time, perhaps rendering the time necessary to apply the incremental and archive log relatively insignificant in comparison. You have to apply the archived redo logs from the last backup to bring the database current. Incremental backups are actually just collections of changes and the applying of the incremental backup replaces applying all the logs generated between the full backup (level 0 in this case) and the incremental backup so does applying incremental backups really add much if any time to the total recovery process?

My ideal would be to run full backups every night and not use incremental backups however if I remember right incremental backups were introduced as a way to reduce the time necessary to run the nightly backups. So if you are using incremental backups to reduce the load on the machines during say, nightly batch, you may not really have a choice. Then we get to those sites where an rman full backup takes more than 24 hours to run.

I think backup requirements are very site specific.

-----Original Message-----
From: [] On Behalf Of Mladen Gogala Sent: Thursday, February 12, 2015 4:02 AM To:
Subject: Re: block chg tracking

Comments in-line

On 02/12/2015 02:58 AM, John Hallas wrote:
> I find backup with de-duplication technology, like Commvault Simpana, far preferable to incremental backups.
> And yes, I do work for Commvault Systems.
> Why are the 2 not compatible Mladen?

The two are compatible, but incremental backups are a nuisance. You have to restore the last full backup and all incremental backups since the last backup. And then apply logs. A full backup with de-duplication will shrink your backups and reduce backup time so that the storage taken by the full backup will be approximately the same as the storage taken by an incremental backup without de-duplication. Well, not quite, the usual de-duplication granularity is 128k and the most frequent db_block_size is 8k, so there is some beef added, but the savings are significant.

> BCT reduces the use of CPU and disk I/O as it knows which blocks have
> changed. Yes there is an overhead in writing that information and on
> a massively performant system such as trading system that overhead
> might be too much, however small it is, however on most systems it is
> not really noticeable. The benefits when running the backups are a
> very significant trade-off though

Well, with database sizes in tens of TB, every backup becomes too slow. With a really big DB, overhead of restoring several incremental backups becomes unacceptable. I don't know the sizes of your databases and the SLA time specified to bring them back, but chances are that restoring several incremental backups will take significant amount of time. Restoring a single full backup will have to be done anyway, it's only the question of storage and the amount of time needed to recover. These days, it is possible even to use SAN snapshots and copy to another storage cabinet using SRDF, SnapVault, HDR or something similar. That is the most expensive option with respect to storage but definitely the fastest to restore. The restore is essentially SAN snapshot revert. However, for larger databases incremental backups are exceedingly rare. If something like hurricane Sandy happens, recovery will take much longer if incremental backups need to be restored. At some point, it pays off to do only full backups, with de-duplication, despite the slightly larger amount of storage used.

> And yes, we use Commvault
> John

I am very glad that you do. Hopefully, you like it, too. If there is anything I can help with, my office email is Of course, the opinions stated on this list are mine and do not reflect the opinions of my employer. I am not authorized to speak or make any statements for my employer. That is why I use Yahoo address.

> ______________________________________________________________________
> Wm Morrison Supermarkets Plc is registered in England with number 358949. The registered office of the company is situated at Gain Lane, Bradford, West Yorkshire BD3 7DL. This email and any attachments are intended for the addressee(s) only and may be confidential.
> If you are not the intended recipient, please inform the sender by replying to the email that you have received in error and then destroy the email.
> If you are not the intended recipient, you must not use, disclose, copy or rely on the email or its attachments in any way.
> This email does not constitute a contract in writing for the purposes of the Law of Property (Miscellaneous Provisions) Act 1989.
> Our Standard Terms and Conditions of Purchase, as may be amended from
> time to time, apply to any contract that we enter into. The current
> version of our Standard Terms and Conditions of Purchase is available
> at:
> Although we have taken steps to ensure the email and its attachments
> are virus-free, we cannot guarantee this or accept any responsibility, and it is the responsibility of recipients to carry out their own virus checks.
> ______________________________________________________________________
> i 0 zX + n { +i ^l===

Mladen Gogala
Oracle DBA


i0zX+n{+i^ Received on Thu Feb 12 2015 - 15:57:18 CET

Original text of this message