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@xxxxxxxxx>
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@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx>
<oracle-l-bounce@xxxxxxxxxxxxx> on behalf of Mladen Gogala
<gogala.mladen@xxxxxxxxx> <gogala.mladen@xxxxxxxxx>
*Sent:* Thursday, May 13, 2021 11:01 AM
*To:* Jared Still <jkstill@xxxxxxxxx> <jkstill@xxxxxxxxx>
*Cc:* Oracle-L Freelists <oracle-l@xxxxxxxxxxxxx> <oracle-l@xxxxxxxxxxxxx>
*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-1217https://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-1217https://dbwhisperer.wordpress.com
-- //www.freelists.org/webpage/oracle-l
