Mladen,
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?
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.
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...
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@xxxxxxxxxxx> 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@xxxxxxxxx> wrote:From consulting.
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.
--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com
--
//www.freelists.org/webpage/oracle-l
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
