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> 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> 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> 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 <oracle-l-bounce@xxxxxxxxxxxxx> on
behalf of Mladen Gogala <gogala.mladen@xxxxxxxxx>
Sent: Tuesday, March 6, 2018 7:36 PM
To: 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
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
