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