Re: block chg tracking
- From: MARK BRINSMEAD <mark.brinsmead@xxxxxxxxx>
- To: dmarc-noreply@xxxxxxxxxxxxx
- Date: Thu, 12 Feb 2015 10:45:34 -0500
I don't see the connection between 24x7x365 uptime and level-0 backups.
Yeah -- you're going to use a physical standby as your first line of
recovery. Nobody is going to take their retail site offline for 4 hours
while you spin backup tapes. But in the event of a disaster, you are
probably going to failover (immediately) to the standby and continue
operations while you restore the (former) "primary" database from backups.
Why would this preclude the "traditional" level-0 / level-1 backup?
On Thu, Feb 12, 2015 at 10:37 AM, Mladen Gogala <dmarc-noreply@xxxxxxxxxxxxx
> wrote:
> 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@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
>>
>>
>> ��i��0���zX���+�� n��{�+i�^l===
>>
>
>
> --
> Mladen Gogala
> Oracle DBA
> http://mgogala.freehostia.com
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
