RE: block chg tracking
- From: "Powell, Mark" <mark.powell2@xxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 12 Feb 2015 14:57:18 +0000
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: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Mladen Gogala
Sent: Thursday, February 12, 2015 4:02 AM
To: oracle-l@xxxxxxxxxxxxx
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 mgogala@xxxxxxxxxxxxx. 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.
>
> www.jhdba.wordpress.com
>
>
>
> ______________________________________________________________________
> 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: http://www.morrisons.co.uk/gscop
>
> 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
http://mgogala.freehostia.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
