Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from smtp-aa.freelists.org (smtp-aa.freelists.org [23.23.80.81]) by malta2546.startdedicated.com (Postfix) with ESMTPS id 2806110033F190 for ; Fri, 14 May 2021 08:27:03 +0200 (CEST) Received: from turing.freelists.org (ip-10-0-0-164.ec2.internal [10.0.0.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp-aa.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 6E02A40B4E; Fri, 14 May 2021 06:27:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id 60D024081D; Fri, 14 May 2021 06:27:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1620973621; bh=Jr9Dekd9uQMbIWTqOKL11GYl1fD5BpA+ht55cdIiZIM=; h=From:Sender:Sender:From; b=nGAUEmXu+WPFnWoOm7hOahPDZXXKXNPhxpoXBi1K9PpfLG2C+QWCtwsK3b81Ythpl EvGqn5uZrlYRnuaLtgFeUTu/5mN/jr1Nqg3zQW68KSo5/WZOd+OMMmZDmdIuFKECfU dLMuTd1yrU4UF9R4p1cHyHQpGTlntAnjoPmDlZIw= X-Virus-Scanned: by FreeLists at turing2.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDTYsNrVNaP9; Fri, 14 May 2021 06:27:01 +0000 (UTC) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id ED4C24081E; Fri, 14 May 2021 06:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1620973620; bh=Jr9Dekd9uQMbIWTqOKL11GYl1fD5BpA+ht55cdIiZIM=; h=From:Sender:Sender:From; b=WKllms8U25tOqejMCBfijKHEhC6Q/6uduxhAPfWb9c9ZlSHff7ZDN5KFQvEiOR6b2 2V+UG/QG7Yrl5M60LEhLhANJZnYt8Gb8TVvJvl/D74r8wNxNGL4HMO+BIhrmOF2hiN BraDBb2B7AYlq+Q5q18w/BSI++wqtAgzH1vjX4qA= Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 14 May 2021 06:26:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id 7FEB44081D for ; Fri, 14 May 2021 06:26:57 +0000 (UTC) Authentication-Results: turing.freelists.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=JMvOxH0u; dkim-atps=neutral Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vspxGOkroCSM for ; Fri, 14 May 2021 06:26:57 +0000 (UTC) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by turing.freelists.org (Postfix) with ESMTPS id 682E94081C for ; Fri, 14 May 2021 06:26:57 +0000 (UTC) Received: by mail-ua1-f43.google.com with SMTP id z7so9331153uav.4 for ; Thu, 13 May 2021 23:26:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LWxA5EwHw+o+36e0dHSb3JDdDNrp4o4UmNVOQjjvmSI=; b=ciDlQhD0ZXDrb1yg6/mtdIpA1uCWxdupK2OB1b7xWiuVrrWTmRwoSfP6P1ich67tY6 p4S7y8IMyEdLHezoWUIq9dud9jkpHu8Sqa9bCOQUhREJcUx8PHwtDyWMxIZ0VjyVllv0 9oq1esVp1a5EdqECaLohmL0Q4k9wRCMo2/k6knX4eXFfExrmDbDT0ghzmfoyoADCMKUh Ph+SZvkOyss3Q22tyO52Y6iEBC8sO6o5rvsNpotDmOpM7TADuRx9a5Hn8y5cdLbwG60+ 85cBS6TTEGknurmuj1YhF7WxHfFpMoS+QI1FejJnr6976oMskdTGcByKo9Rrgr5bSzqg rdoA== X-Gm-Message-State: AOAM531TxkhsAyM71v0Niyl/clPFpc8LusBzwuc2i4mWUw2cn09YmZ/6 bvIU9cu07ie6ZA2BzbnZehl7+H7DS8AkERw4NBY= X-Google-Smtp-Source: ABdhPJzFDAywjeBpiNdEazS0iWy1zg3BRTQYOl3YpzqiR8xKBVff5U6vMcXS1J56if8VOr6yXomZIvq1CdjiNFA08Ms= X-Received: by 2002:ab0:6309:: with SMTP id a9mr41740163uap.75.1620973616947; Thu, 13 May 2021 23:26:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pap Date: Fri, 14 May 2021 11:56:44 +0530 Message-ID: Subject: Re: Backup on standby database To: Mladen Gogala Cc: Oracle L Content-Type: multipart/alternative; boundary="000000000000a0e66405c2445483" X-archive-position: 79942 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: oracle.developer35@gmail.com Precedence: normal Reply-To: oracle.developer35@gmail.com List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-Subscribe: List-Owner: List-post: List-Archive: X-list: oracle-l --000000000000a0e66405c2445483 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi Mark. > > Restoring just a full backup is simpler because you don't have to wait fo= r > the restore of the incremental backups. However, you are right: I should > have said "faster" not "simpler". Second, do you mean taking more than on= e > 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 deduplicatio= n > enabled. File space consumed is approximately the same as the incremental > backup. Deduplication will take care of backing up only the blocks that a= re > different from the previous backup. The snag is that not all deduplicatio= n > algorithms work well with compression. However, those are the details > specific to the particular backup software. For instance, Data Domain Boo= st > 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 firs= t > line is RAC, the second line is Data Guard and the last line is the backu= p. > 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 la= st > log and the crash. The shorter the period between the last full backup an= d > the crash, the faster the recovery will be. If you can backup the databas= e > 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 o= f > 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 you= r > level 0 or full. On systems with high update to the same rows use of lev= el > 1 backups can save a log of recovery time and time to recover is importan= t. > > > Mark Powell > Database Administration > (313) 592-5148 > > > ------------------------------ > *From:* oracle-l-bounce@freelists.org > on behalf of Mladen Gogala > > *Sent:* Thursday, May 13, 2021 11:01 AM > *To:* Jared Still > *Cc:* Oracle-L Freelists > *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 backup= s > w/o any incremental backups. The problem with such strategy is storage, n= ot > 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 anythi= ng > 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 suit= e > does support it, his subsequent full backups will take as much space as a= n > 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/ > > Github: https://github.com/jkstill > > > -- > Mladen Gogala > Database Consultant > Tel: (347) 321-1217https://dbwhisperer.wordpress.com > > > > -- > Mladen Gogala > Database Consultant > Tel: (347) 321-1217https://dbwhisperer.wordpress.com > > -- http://www.freelists.org/webpage/oracle-l --000000000000a0e66405c2445483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct=C2=A0me 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 onl= y. 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 ar= chive Logs needed to recover.

But it seems the backup ca= n well be driven from DR/physical standby without any issue considering we = have an active data guard license.

Regards
Pap=C2=A0

On Fri, May 14, 2021 at 12:55 AM Mladen Gogala <gogala.mladen@gmail.com> wr= ote:
=20 =20 =20

Hi Mark.

Restoring just a full backup is simpler because you don't have t= o 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.=C2=A0

Lastly, backup and restore are always the last line of defense. The=C2=A0 first line is RAC, the second line is Data Guard and the la= st 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,=C2=A0 you can even take 2 full backups per day. It doesn't matter, they're running off the standby anywa= y.

Regards


On 5/13/21 1:18 PM, Powell, Mark wrote:
=20 =20
"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?=C2=A0 You just issue recover database and rman takes care of the rest.=C2=A0 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.=C2=A0 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@freelists.org <oracle-l-bounce@freelists.org> on behalf of Mladen Gogala <gogala.mladen@gmail.com>
Sent: Thursday, May 13, 2021 11:01 AM
To: Jared Still <jkstill@gmail.com>
Cc: Oracle-L Freelists <oracle-l@freelists.org>
Subject: Re: Backup on standby database
=C2=A0

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 prett= y 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

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



--=20
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbw=
hisperer.wordpress.com
-- htt= p://www.freelists.org/webpage/oracle-l
--000000000000a0e66405c2445483-- -- http://www.freelists.org/webpage/oracle-l