Re: DG for nologging

From: Upendra nerilla <nupendra_at_hotmail.com>
Date: Wed, 7 Mar 2018 22:46:52 +0000
Message-ID: <CY1PR10MB0683E2E5F47DB8B4AA067762D8D80_at_CY1PR10MB0683.namprd10.prod.outlook.com>

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_at_fpl.com> Sent: Wednesday, March 7, 2018 4:10 PM
To: arjen.visser_at_gmail.com; Andrew Kerber Cc: nupendra_at_hotmail.com; Mladen Gogala; oracle-l_at_freelists.org Subject: RE: DG for nologging

Despite the downsides, I personally think it is better than Data Guard.

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.
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.
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.
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Arjen Visser Sent: Wednesday, March 7, 2018 3:22 PM
To: Andrew Kerber <andrew.kerber_at_gmail.com> Cc: nupendra_at_hotmail.com; Mladen Gogala <gogala.mladen_at_gmail.com>; oracle-l_at_freelists.org 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_at_gmail.com<mailto:andrew.kerber_at_gmail.com>> 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_at_gmail.com<mailto:arjen.visser_at_gmail.com>> 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_at_hotmail.com<mailto:nupendra_at_hotmail.com>> 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_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org>> on behalf of Mladen Gogala <gogala.mladen_at_gmail.com<mailto:gogala.mladen_at_gmail.com>> Sent: Tuesday, March 6, 2018 7:36 PM
To: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org> Subject: Re: DG for nologging

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.'

--

http://www.freelists.org/webpage/oracle-l Received on Wed Mar 07 2018 - 23:46:52 CET

This message: [ Message body ]
Next message: Noveljic Nenad: "RE: DBA Job Functions"
Previous message: Kenny Payton: "GoldenGate Newb question ???"
In reply to: Sheehan, Jeremy: "RE: DG for nologging"
Next in thread: Sheehan, Jeremy: "RE: DG for nologging"
Reply: Sheehan, Jeremy: "RE: DG for nologging"

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

Original text of this message