Re: block chg tracking
Date: Thu, 12 Feb 2015 10:37:38 -0500
Message-ID: <54DCC8C2.9090703_at_yahoo.com>
On 02/12/2015 09:57 AM, Powell, Mark wrote:
> 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?
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. I do remember duplicate database problems in 10G, when BCT was on. The control file of the auxiliary instance was restored from the target instance and contained an information about the BCT file which was not restored on the auxiliary instance. The database refused to open. The workaround was to disable the BCT during the duplicate DB and then to re-enable it, thereby messing up my incremental backups.
>
> 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.
And that's exactly the thing that de-duplication is supposed to address. Of course, very large databases have corresponding hardware requirements. The primary means of maintaining the availability is always a physical standby, if the up-time requirements are 7x24x365, and they usually are.
>
> I think backup requirements are very site specific.
Yes they are. And more complex and expensive than people realize. I see many people abandoning tapes altogether, but I am not quite clear as to why. There is nothing else that can store 6TB of data on a $45 piece of medium. 6TB of EMC disk space will cost much more, even if it's Isilon or VNX. I don't even want to discuss VMAX. Problem is that with the advent of WWW, many more sites are being asked to remain up 7 days a week, 24 hours per day. Long, long time ago, in a galaxy far, far away, when there was no Amazon, book shops could have shut their systems down for the Sunday afternoon. Do that these days, and your shop will likely go the way of the Borders Books. Banks, news and media outlets and even mortar and click shops like Walmart have to remain open 24 hours a day, 7 days a week, 365 days per year. Such extreme up-time requirements which were once reserved only for the credit card companies, huge international banks, HMO's and 911 services are now common. And that puts a completely new set of requirements on the backup strategy. I doubt that Google could tell internet users that they're doing maintenance and are shutting down their systems on every first Sunday in a month, for 1 hour. Even that would be considered far too much. And that would still be 99% up-time. Backup and restore become extremely expensive when it is not possible to shut the company production database down for 12 hours per year. The classic wisdom of doing a weekly full backup over the weekend and incremental backups in the meantime no longer apples.
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala
> Sent: Thursday, February 12, 2015 4:02 AM
> To: oracle-l_at_freelists.org
> 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_at_commvault.com. 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
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
> ��i��0���zX���+�� n��{�+i�^l===
-- Mladen Gogala Oracle DBA http://mgogala.freehostia.com -- http://www.freelists.org/webpage/oracle-lReceived on Thu Feb 12 2015 - 16:37:38 CET