Re: Backup on standby database

Hi Pap,

I apologize for hijacking your thread, it's no longer about ZDLRA. Jared asked me why do I think that incremental backups are a bad idea and I answered, all in the thread started by you. Furthermore, you mention merging L1 backups into a new full. That feature is called "synthetic full backup" and is not native to RMAN. That means that you have some kind of 3rd party backup software which can do that. I know of at least one such software and it changes the situation since you have a daily full, created by taking daily incremental. I don't have much experience with zero loss data recovery appliance, I am not sure whether it includes an active DG license. I know that the hardware is essentially an Exadata, configured as a standby. Out of curiosity, what kind of backup suite do you use?

Regards

On 5/14/21 2:26 AM, Pap wrote:
> Correct me if wrong, maybe this recent discussion is about something
> else, but in the case of ZDLRA(which we are using now), we have only
> one FULL backup in its lifecycle, the other subsequent are L1 only.
> And these daily L1s are merged back to form L0 for that day. So I am
> not seeing any space concern in this case. And at any point of failure
> it will be just the last L1(which is nothing but a L0 in case of
> ZDLRA) + delta archive Logs needed to recover.
>
> But it seems the backup can well be driven from DR/physical standby
> without any issue considering we have an active data guard license.
>
> Regards
> Pap
>
> On Fri, May 14, 2021 at 12:55 AM Mladen Gogala
> <gogala.mladen_at_gmail.com <mailto:gogala.mladen_at_gmail.com>> wrote:
>
> Hi Mark.
>
> Restoring just a full backup is simpler because you don't have to
> wait for the restore of the incremental backups. However, you are
> right: I should have said "faster" not "simpler". Second, do you
> mean taking more than one backup per day? In that case, you maybe
> right, depending on the timing. Space for the daily full backup is
> not a problem if you have deduplication enabled. File space
> consumed is approximately the same as the incremental backup.
> Deduplication will take care of backing up only the blocks that
> are different from the previous backup. The snag is that not all
> deduplication algorithms work well with compression. However,
> those are the details specific to the particular backup software.
> For instance, Data Domain Boost works well with lzip compression
> but not with gzip which is used by rman.
>
> Lastly, backup and restore are always the last line of defense.
> The  first line is RAC, the second line is Data Guard and the last
> line is the backup. If you are in situation that you have to
> restore backup, you are already in trouble. In that case, I want
> to restore a full backup, because I must do that anyway, and apply
> all the archive logs for the period between the last log and the
> crash. The shorter the period between the last full backup and the
> crash, the faster the recovery will be. If you can backup the
> database within 4 hours,  you can even take 2 full backups per
> day. It doesn't matter, they're running off the standby anyway.
>
> Regards
>
>
> On 5/13/21 1:18 PM, Powell, Mark wrote:
>> "You MUST restore the last full backup and all incremental
>> backups taken after the last full. It is much simpler to restore
>> only the last full backup and apply the logs."
>>
>> Why is it simpler?  You just issue recover database and rman
>> takes care of the rest.  it is not like you must manually figure
>> out which incremental backups and archive logs you need to apply.
>>
>> While I would prefer running level 0 backups daily where possible
>> and may or may not use level 1 backups with them the only real
>> cost of level 1 backups is the extra file space consumed by the
>> level 1 backup that would not be consumed if you only ran archive
>> logs backups to go along with your level 0 or full.  On systems
>> with high update to the same rows use of level 1 backups can save
>> a log of recovery time and time to recover is important.
>>
>>
>> Mark Powell
>> Database Administration
>> (313) 592-5148
>>
>>
>> ------------------------------------------------------------------------
>> *From:* oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>
>> <oracle-l-bounce_at_freelists.org>
>> <mailto:oracle-l-bounce_at_freelists.org> on behalf of Mladen Gogala
>> <gogala.mladen_at_gmail.com> <mailto:gogala.mladen_at_gmail.com>
>> *Sent:* Thursday, May 13, 2021 11:01 AM
>> *To:* Jared Still <jkstill_at_gmail.com> <mailto:jkstill_at_gmail.com>
>> *Cc:* Oracle-L Freelists <oracle-l_at_freelists.org>
>> <mailto:oracle-l_at_freelists.org>
>> *Subject:* Re: Backup on standby database
>>
>> Well, it is not possible to recover DB from an incremental backup
>> alone. You MUST restore the last full backup and all incremental
>> backups taken after the last full. It is much simpler to restore
>> only the last full backup and apply the logs. That is possible if
>> you have daily full backups w/o any incremental backups. The
>> problem with such strategy is storage, not the duration of the
>> full backup which takes longer than the incremental. That doesn't
>> matter since the standby is not open and is not doing anything
>> for the end users. Nobody will suffer because you're running
>> backup from standby. The storage problem can be resolved by
>> deduplication. If the OP's backup software supports
>> deduplication, and pretty much every backup suite does support
>> it, his subsequent full backups will take as much space as an
>> incremental.
>>
>> On 5/13/21 10:01 AM, Jared Still wrote:
>>> Hi Mladen,
>>>
>>> Please explain:
>>>
>>> Also, if you plan on running incremental backups, which I
>>> don't consider a good idea,
>>>
>>>
>>>
>>> Jared Still
>>> Certifiable Oracle DBA and Part Time Perl Evangelist
>>> Principal Consultant at Pythian
>>> Oracle ACE Alumni
>>> Pythian Blog http://www.pythian.com/blog/author/still/
>>> <https://clicktime.symantec.com/a/1/mJVSISzEHH_JAKz4tadrbRlYlYaxeNAK2II35gDcTY8=?d=hLvgTrsk498zgqlutYWbrJKoENsE3eej5Vig62q94j0BZZlIBO_Yv1wM18JrdYtAcOouO6FH1gJrR8CtfGdV-FTfSpUzhC1jktpFxVfDUFDTe0w3-jWFl8rrmDXfFeBSqOy-SWgIt6Ldh4A6e-LM21aRfC2IEhAdR6e_mcmhVRvbtZVkGOCX2lCIemFLfDLzolwBiLi2jJ45vruLkGuh9j30Z3QlgZmCJU-E758oVP4qVAso9MAVW-au9bywxEkdzslpbOneuMflAsGAVFDrNzpmkbx1RCEkfAyNDPD2lUJKRsEUAQaY241Mo69DZS-05Qt4YWFjE4SmAqD_9M5NA908wX9qTXy8_CCaZkUcp1rL5g9syMU6G9eM3r88iX4G9l0_BsLCz6r77YAJrlNEmQ8fmzL95XHPic5upOGaxWQf_m-KKH-TFAhzbVJdpQgc_8Z_&u=http%3A%2F%2Fwww.pythian.com%2Fblog%2Fauthor%2Fstill%2F>
>>> Github: https://github.com/jkstill
>>> <https://clicktime.symantec.com/a/1/xVPUmQWc5I54MyvyOLlGVR4xucrp39n40JumOJDHzhI=?d=hLvgTrsk498zgqlutYWbrJKoENsE3eej5Vig62q94j0BZZlIBO_Yv1wM18JrdYtAcOouO6FH1gJrR8CtfGdV-FTfSpUzhC1jktpFxVfDUFDTe0w3-jWFl8rrmDXfFeBSqOy-SWgIt6Ldh4A6e-LM21aRfC2IEhAdR6e_mcmhVRvbtZVkGOCX2lCIemFLfDLzolwBiLi2jJ45vruLkGuh9j30Z3QlgZmCJU-E758oVP4qVAso9MAVW-au9bywxEkdzslpbOneuMflAsGAVFDrNzpmkbx1RCEkfAyNDPD2lUJKRsEUAQaY241Mo69DZS-05Qt4YWFjE4SmAqD_9M5NA908wX9qTXy8_CCaZkUcp1rL5g9syMU6G9eM3r88iX4G9l0_BsLCz6r77YAJrlNEmQ8fmzL95XHPic5upOGaxWQf_m-KKH-TFAhzbVJdpQgc_8Z_&u=https%3A%2F%2Fgithub.com%2Fjkstill>
>>>
>> --
>> Mladen Gogala
>> Database Consultant
>> Tel: (347) 321-1217
>> https://dbwhisperer.wordpress.com <https://clicktime.symantec.com/a/1/z3OB4l0tHKYEqyX9dB5pwAtjADgiQgdf1usx1snB77o=?d=hLvgTrsk498zgqlutYWbrJKoENsE3eej5Vig62q94j0BZZlIBO_Yv1wM18JrdYtAcOouO6FH1gJrR8CtfGdV-FTfSpUzhC1jktpFxVfDUFDTe0w3-jWFl8rrmDXfFeBSqOy-SWgIt6Ldh4A6e-LM21aRfC2IEhAdR6e_mcmhVRvbtZVkGOCX2lCIemFLfDLzolwBiLi2jJ45vruLkGuh9j30Z3QlgZmCJU-E758oVP4qVAso9MAVW-au9bywxEkdzslpbOneuMflAsGAVFDrNzpmkbx1RCEkfAyNDPD2lUJKRsEUAQaY241Mo69DZS-05Qt4YWFjE4SmAqD_9M5NA908wX9qTXy8_CCaZkUcp1rL5g9syMU6G9eM3r88iX4G9l0_BsLCz6r77YAJrlNEmQ8fmzL95XHPic5upOGaxWQf_m-KKH-TFAhzbVJdpQgc_8Z_&u=https%3A%2F%2Fdbwhisperer.wordpress.com>
>>
>>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
> https://dbwhisperer.wordpress.com <https://dbwhisperer.wordpress.com>
>
> -- http://www.freelists.org/webpage/oracle-l
> <http://www.freelists.org/webpage/oracle-l>
>

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com


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