Re: diff between incremental and archive backups

On 11/14/15 16:15, Mladen Gogala wrote:
> What is the point in taking incremental backups from the standby
> database? To mitigate the impact on the production users?
The purpose of physical standbys should be obvious, right? I should also mention that if RTO requirements are strict enough, that not only one standby is recommended? One standby should be kept at the current point-in-time for immediate switchover, while another should be kept with a 24-48 hour lag, for faster point-in-time recoveries? I mean, if RTO is very strict regardless of failure scenario, then what solutions other than replicated standbys exist? So, hopefully we're not getting into a discussion about standbys and so we will just talk about backups?

So then I'll turn your question back to you: if you have a physical standby, what is the point in taking backups (incremental or otherwise) from the primary?

If that was not your point, and instead you're asking why take incrementals (as opposed to fulls) from the standby, again I'll turn the question back to you: what is the point of wasting resources performing full backups when one can perform a far more efficient incremental backup?

Cumulative incremental backups meet halfway on the tradeoff between backups and restores that you've mentioned, and might well satisfy RTO requirements while minimizing resources consumed. Maybe so? Maybe not?

> My position is a bit specific, because I am a high level consultant
> working for a backup vendor. I usually participate in the creation of
> the backup strategy.

I'm just a grunt DBA, always have been, always will be.

I've never felt that it makes sense to start off by discussing "how" (i.e. backups) before you've decided on "what" (i.e. how to recover in event of failure), no matter one's job description.

So, I prefer the term "recovery strategy", because backups are only one mechanism used in recovery.

> Also, what kind of recovery time do you expect from restoring
> incremental backups of a multi-TB database?
If failover to a standby doesn't resolve the problem, then the next probable solution is a partial recovery of the affected datafiles or tablespaces. If a partial restore/recovery isn't possible, then there is nothing left but a full restore/recovery. Having blown past two good recovery mechanisms already, I'd be just as concerned with "will it work?" rather than "how long will it take?" And, even with no incrementals, restore of a multi-TB database is not a happy occasion, ever. That is why it is the last resort.

> The backup product that I use to suggest backup strategy is Commvault
> Simpana, which also includes deduplication as a part of the backup
> solution. So, if the client is running a multi-TB database and is
> doing incremental backups, what kind of SLA do they have for restore
> and recovery? They have to restore the entire database, since they
> have to restore the last full backup. And then they have to restore
> every incremental backup between the full backup and the point of
> failure. After that, they have to restore archive logs between the
> last incremental and the point of failure. With a multi-TB database,
> that sounds like a very lengthy exercise. Such strategy can be a
> resume generating event.

OK, I'll be your huckleberry...

Please explain in detail how the stated solution (i.e. Simpana) is superior to an RMAN incremental strategy, especially when RMAN is secondary to one or more standby databases, as discussed above? No need to state RPO (i.e. let's assume zero data loss), but please state RTO for each scenario?

Perhaps too explain how Simpana is better than EMC Networker, Symantec (soon to be Veritas again) NetBackup, IBM TSM, etc which also have deduplication capabilities? Many on this list are using those solutions too, so it would be interesting to understand if one product is arguably better than another?

We appreciate any insight you can offer.

Thanks!

-Tim

> Regards
>
> On 11/14/2015 06:00 PM, Tim Gorman wrote:
>> Over my past 16 years as a DBA consultant/contractor, incremental
>> backups have been very much in the majority. Some use cumulative
>> incrementals, most use differential incrementals. Many use BCT to
>> make incrementals more efficient. Many also backup DataGuard
>> physical standbys, instead of the primaries, although there are some
>> RMAN bugs involved between 11.1.0.6 and 11.2.0.3.
>>
>> Organizations with strict RTO and RPO objectives use DataGuard,
>> GoldenGate, or other replication options as the primary recovery
>> method, with RMAN restore/recovery as the last resort.
>>
>>
>>
>> On 11/14/15 15:30, Andrew Kerber wrote:
>>> That's about the same as my experience.
>>>
>>> Sent from my iPad
>>>
>>>> On Nov 14, 2015, at 4:13 PM, Neil Chandler
>>>> <neil_chandler_at_hotmail.com> wrote:
>>>>
>>>> I have worked for 5 corporations this year, small and huge. Oracle
>>>> 10, 11 and 12. All of them used incremental backups.
>>>>
>>>> Regards
>>>>
>>>> Neil Chandler
>>>> Oracle ACE
>>>> sent from my phone
>>>>
>>>>>> On 14 Nov 2015, at 17:48, Mladen Gogala <gogala.mladen_at_gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On 11/14/2015 08:38 AM, Andrew Kerber wrote:
>>>>>> am not sure where you get the idea that most places don't use
>>>>>> incremental backups. That is the opposite of my experience.
>>>>> From consulting.
>>>>>
>>>>> --
>>>>> Mladen Gogala
>>>>> Oracle DBA
>>>>> http://mgogala.freehostia.com
>>>>>
>>>>> --
>>>>> http://www.freelists.org/webpage/oracle-l
>>>>>
>>>>>
>>> --
>>> http://www.freelists.org/webpage/oracle-l
>>>
>>>
>>>
>>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>
>

--
http://www.freelists.org/webpage/oracle-l