Dataguard same server
Date: Thu, 19 Nov 2020 09:39:21 +1100
Message-ID: <CAFeFPA9Og9vMvTLYcNiXP_QGVr4eV9gOJKAehpufOw4S_yhoiQ_at_mail.gmail.com>
Hi All,
We have a quarter rack EXA (2 node RAC) with oracle 12.2 databases multi
tenant
We have a remote site that has the same and we use dataguard to replicate
between the 2 sites and keep them in sync.
I was asked a question about a second Dataguard instance that is lagging
behind a few hours on one of those systems (we do not have any hardware to
run this on).
After thinking about that I am having the following thoughts
1. Flashback database is configured and can be used to flashback the
database (currently 50+ hours according to v$flashback_database_log) so
really no need to have another Dataguard.
2. We can not have a Dataguard on the same server as the service names will
clash. I have in the past built standby databases on the same server for
testing but that was not multi tenant or on clusters. And with multi tenant
I dont think we can change the service names of the PDB in the standby.
Is there anything I am overlooking here?
This is all coming up because of an audit that is happening. One of the things that came up is an attack that encrypts your data and how we can prevent that from happening in Oracle.
As we are using EXA data I don't think an attacker will be able to get to the OS and encrypt my database files and even if they do on one site, the DR will still be unaffected, right?
I have asked my manager to get me a more detailed risk assessment so I get a better understanding of what it is exactly they are trying to avoid
Jack van Zanen
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Thank you for your cooperation
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Nov 18 2020 - 23:39:21 CET