So if you want to replicate (no pun intended) the performance of your local
system remotely on the cloud, there are (at least) three critical
considerations:
1) Does the cloud vendor have a platform that can meet or exceed your
current database performance levels, most ideally with a short term on demand
ramp up so you can run at a level of service sufficient for delayed log
application most of the time and ramp up for testing fail/switchover to make
sure everything database AND applications are ready to go?
2) Is the “chattiness” (ping plus bandwidth) in total from your applications
handled sufficiently?
3) Do you have a sufficient remote resource for the applications in case
we’re dealing with a site disaster? (which you also test with respect to #2)
Knowing those things and the prices for them will help you properly frame for
management what is possible and how much it will cost.
Engaging vendors in trials may yield good advice in how to make each of their
individual offerings shine with respect to your needs, and possibly you can get
fees waived for the trials if they understand this is a competition for a long
term deal. Mike Prince, the IT boss at Burlington Coat during my contract there
1989-1994 was an absolute master at this. Done correctly, everyone wins,
because even the losing vendors learn about their limits and competition.
Good luck.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Pap
Sent: Wednesday, May 11, 2022 3:43 AM
To: Lok P
Cc: Mladen Gogala; Mark W. Farnham; Clay Jackson (cjackson);
tim.evdbt@xxxxxxxxx; Oracle L
Subject: Re: Minimize recovery time
Others can correct here but with current use cases, as you mentioned your on
premise primary and physical standby are already on Oracle Exadata. So I don't
think you will get a similar Oracle exadata engineered system(mainly wrt the
engineered storage cells) on AWS EC2 for your second physical standby/dataguard
with delayed log apply. On AWS that would be a simple non exadata like
environment with oracle software running on it and you may lose some of the
features like automatic indexing, in memory rac etc if using currently. And I
am not sure if applying redo logs from a primary exadata to a physical standby
non-exa can be possible or can cause any issue during recovery or can cause
issues in log apply itself etc.Also your application may not really able to run
on that environment with same speed then on that non exa database.
Or else you may just live with a nonrac nonexa database on AWS with a golden
gate replication with delayed log apply. That way it will just make sure your
data is clean and then you can get the specific corrupted tables created back
in your on premise db from that.
On Wed, May 11, 2022 at 1:59 AM Lok P <loknath.73@xxxxxxxxx> wrote:
Just curious to understand here, regarding having a second data guard setup
with delayed log apply:- We have the primary and physical standby(with real
time log apply) set up on premise. And to minimize the storage/maintenance
cost and modernization perspective, In this situation, Is it advisable to have
this additional physical standby(with delayed log apply) hosted on a cloud( say
e.g. AWS) environment, or will it have any downside?
On Thu, Apr 28, 2022 at 9:35 AM Lok P <loknath.73@xxxxxxxxx> wrote:
Thank You So much for the guidance.
So it looks like having another data guard setup with a good enough apply lag
is the easiest way with minimal overhead as compared to other strategies like
compression etc.
Also as Mladen pointed out we do have exadata as data guard setup only. So
perhaps we currently have a single 10GB ethernet adapter which is why the
backup team has put the figure of ~2TB/hr of RTO. And having multiple 10GB
adapters we would be able to minimize the RTO even with current DB size. Will
check on this with the team.
Regarding if we really need Exadata for this application, actually we got ~50%
performance improvement across the application jobs post movement Exadata. But
yes wil see if just having a large SGA is enough to get the similar performance.
Regards
Lok
On Thu, Apr 28, 2022 at 5:39 AM Mladen Gogala <gogala.mladen@xxxxxxxxx> wrote:
On 4/27/22 19:55, Clay Jackson (Clay.Jackson) wrote:
It would appear that DataGuard has you pretty well covered for “normal” sorts
of disasters and outages, and that your (or your management’s) concern now is
“What happens if my entire system gets corrupted and/or hijacked, including my
DataGuard “backups”?”
You can also take a backup off the standby database. It will be recognized as
the backup of the primary, provided you're using RMAN catalog.
Regards
--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
-- //www.freelists.org/webpage/oracle-l ;
