One quick comment on this statement:
"3. True the replicated database can’t be used for anything. If you wanted to
use Active Data Guard you’ll need a license for that and it isn’t cheap (what
is cheap with Oracle anyway?)! On the flip side of that, DR testing is a
breeze. Especially if you’re doing a test and not a full failover/failback. The
storage admin stops replication, presents disks to your serve and you bring it
up. After a small time for crash recovery you’re up and ready. The best part
about this? When you’re done testing, you shut down the database and hand it
over to the storage admin. They can begin replication again from the point when
they stopped replication in the first place and it only has to update deltas
from when they stopped. If you did this with Data Guard, you’d have to
completely rebuild the environment. If you are doing a graceful switchover
(full testing), there is no crash recovery involved. You just start up the
database. No DGMGRL (granted that is very easy) to worry about."
Specifically this one - "If you did this with Data Guard, you’d have to
completely rebuild the environment."
You could convert a standby database into snapshot standby to perform the DR
tests. After the DR tests without having to rebuild the entire dataguard
environment, you could rollback the changes and apply where you left off..
https://docs.oracle.com/cd/B28359_01/server.111/b28294/manage_ps.htm#CHDFFFAJ
Managing Physical and Snapshot Standby Databases -
Oracle<https://docs.oracle.com/cd/B28359_01/server.111/b28294/manage_ps.htm#CHDFFFAJ>
See Oracle Data Guard Broker to learn how the Data Guard broker simplifies the
management of physical and snapshot standby databases. 9.1 Starting Up and
Shutting ...
docs.oracle.com
-Upendra
________________________________
From: Sheehan, Jeremy <JEREMY.SHEEHAN@xxxxxxx>
Sent: Wednesday, March 7, 2018 4:10 PM
To: arjen.visser@xxxxxxxxx; Andrew Kerber
Cc: nupendra@xxxxxxxxxxx; Mladen Gogala; oracle-l@xxxxxxxxxxxxx
Subject: RE: DG for nologging
Despite the downsides, I personally think it is better than Data Guard.
1. You don’t have to worry about it. The task for replication is in someone
else’s hands. If you think that the Storage Admins are going to let replication
get behind, then you have bad storage admins.
2. You CAN get a status check on storage replication (with EMC SRDF at least).
Our storage admin wrote a script that would notify us if there was a problem
with replication. In the 7 years I spent working for one BU, not once did I get
a notification that replication was behind.
3. True the replicated database can’t be used for anything. If you wanted to
use Active Data Guard you’ll need a license for that and it isn’t cheap (what
is cheap with Oracle anyway?)! On the flip side of that, DR testing is a
breeze. Especially if you’re doing a test and not a full failover/failback. The
storage admin stops replication, presents disks to your serve and you bring it
up. After a small time for crash recovery you’re up and ready. The best part
about this? When you’re done testing, you shut down the database and hand it
over to the storage admin. They can begin replication again from the point when
they stopped replication in the first place and it only has to update deltas
from when they stopped. If you did this with Data Guard, you’d have to
completely rebuild the environment. If you are doing a graceful switchover
(full testing), there is no crash recovery involved. You just start up the
database. No DGMGRL (granted that is very easy) to worry about.
4. The DR host can be used for TEST/DEV dbs! You don’t have to blow away their
environments either if things are configured correctly. In the event of an
unplanned outage you can just shut them down and bring things up when things
are back to normal.
Thanks - Jeremy
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Arjen Visser
Sent: Wednesday, March 7, 2018 3:22 PM
To: Andrew Kerber <andrew.kerber@xxxxxxxxx>
Cc: nupendra@xxxxxxxxxxx; Mladen Gogala <gogala.mladen@xxxxxxxxx>;
oracle-l@xxxxxxxxxxxxx
Subject: Re: DG for nologging
CAUTION - EXTERNAL EMAIL
4) the DR secondary can be used to host sandbox test/dev DBs, with the
understanding they'll be blown away in the event of a "grey swan" event
(unplanned outage), where a failover is executed
Regards Arjen
-- Sent from Phone
On 8/03/2018, at 8:02 AM, Andrew Kerber
<andrew.kerber@xxxxxxxxx<mailto:andrew.kerber@xxxxxxxxx>> wrote:
The problem I have always had with SAN replication (as a dba) is that we end up
relying on people outside of our control, sys admin, network, storage
personnel, to keep the data up to date, and we really lack the ability to
validate the status on a daily basis. I like dataguard because I have full
access to logs and status, can see what is going on, know when there are
problems, and typically have the ability to fix the problems. With SAN
replication you are relying on someone else to take care of everything.
On Wed, Mar 7, 2018 at 12:32 PM, Arjen Visser
<arjen.visser@xxxxxxxxx<mailto:arjen.visser@xxxxxxxxx>> wrote:
Some disadvantages of SAN:
1)With database SAN replication you are replicating database data 3 times so
quite inefficient and requiring more bandwidth. Once for all the changes in the
data files, once for replicating redo, and once for replicating archive logs.
With a standby database you are only replicating the changes once.
2)You do not know if your SAN replicated database will start if you really need
it. With a standby database it is always running and ready to take over.
3) The replicated SAN database cannot be used for anything. The standby
database can be used for offload reporting, offloading backups, feeding ETL etc.
Regards, Arjen
On 7/03/2018, at 11:10 PM, Upendra nerilla
<nupendra@xxxxxxxxxxx<mailto:nupendra@xxxxxxxxxxx>> wrote:
A small detour on the SAN replication..
I'm trying to understand the advantages and disadvantages of SAN replication
over Data guard..
I felt Data guard is very specific (to the DB replication task), it can
validate the recoverability of the database continuously. SAN replication on
the other hand, is useful in replicating complex application configuration to
the DR site.. Also with SAN replication, we loose the ability to go
point-in-time in the DR site (if the need arises?).
Also if multiple databases are being replicated with the same SAN replication
group, we are unable to recover each of the database to its own point-in-time..
Please share any feedback or thoughts
Thanks
________________________________
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: Tuesday, March 6, 2018 7:36 PM
To: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: DG for nologging
+2
On 03/06/2018 09:15 AM, Sheehan, Jeremy wrote:
+1 for SAN replication.
--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217<tel:(347)%20321-1217>
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
