Designing RECOVERY usefully requires knowing the topology and geography of your
operational locations and the business goals of business continuation in a
variety of scenarios with management input on which sorts of outages and data
losses cost the most per unit time (often supra-linear as elapsed time of
outage increases).
You don’t want to be in a situation where, say, a single earthquake puts a
global network of build to order manufacturing plants out of business for a
couple weeks. Neither do you want to invest in supporting that sort of recovery
and business continuation if your IT operation is in a single brick and mortar
retail store. Those are probably the polar cases, and if Jan Carel were handy
he’d probably mention that it is unacceptable for a fire in the building
holding your primary database to take out an air traffic control system.
Avoiding a little contention for i/o on the primary machine to get routine
backups is usually a smart idea as Howard notes below, and you can usually work
out that being no hindrance to recovery. You do have to work it through exactly
when you write your playbook for various RECOVERY scenarios. Backups are an
ingredient of RECOVERY. The goal is RECOVERY in accordance with business
requirements with an acceptable level of discomfiture to normal operations.
With the enormity of a lot of systems, full reloads tend to be incompatible
with recovery goals. Mladen has some practical descriptions of this on this
list server, but I cannot remember the vintage. Getting the business to
consider the insurance value of infrastructure and software purchased to meet
recovery requirements often either opens the management wallet or causes them
to realize their goals are incompatible with money available. If that
conversation does not take place, the incumbent DBA may discover that having a
valid backup is not career protection.
Good luck,
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Pap
Sent: Monday, May 03, 2021 11:37 AM
To: Howard Latham
Cc: Oracle L
Subject: Re: Backup on standby database
Thank You. Our infra team is responsible for backup , stating that running
backup on primary is followed as a standard practice in our case. So wondering
if there exists any possible negative side of switching/running the backup to
DR side. Not fully clear though, but just thinking around that in case of
backup running on DR side. If a real disaster happens to either side, will that
cause any concern? or say while the lag is bigger between primary and DR and
one of the sides(say DR on which backup is taking place) crashed , will that
pose a threat for recovery?
Regards
Pap
On Mon, May 3, 2021 at 1:31 AM Howard Latham <howard.latham@xxxxxxxxx> wrote:
We do it as standard. Keeps the impact down.
Best Wishes
Howard A. Latham
On Sun, 2 May 2021 at 20:48, Pap <oracle.developer35@xxxxxxxxx> wrote:
We are using RMAN - ZDLRA for oracle database backup. We are running it
currently on Primary database and it runs for around 2hrs daily. We see during
the backup window there is higher IO utilisation and due to that sometimes
application query sees variable execution time.
We do have dataguard configured standby database for disaster recovery so want
to know from experts if it's advisable to run backup on standby side? Or does
it have any down side?
Regards
Pap
