Re: San-Based replication VS DataGuard replication

On Oct 5, 7:04 pm, Palooka <nob..._at_nowhere.com> wrote:
> Steve Howard wrote:
> > On Oct 4, 5:27 pm, DA Morgan <damor..._at_psoug.org> wrote:
> >> hpuxrac wrote:
> >>> Sounds like you are just making up stuff.
> >> Sounds like you weren't in San Francisco a week ago sitting in on the
> >> excellent briefing Mark Townsend gave the Oracle Ace Directors. <g>
> >> --
> >> Daniel A. Morgan
> >> Oracle Ace Director & Instructor
> >> University of Washington
> >> damor..._at_x.washington.edu (replace x with u to respond)
> >> Puget Sound Oracle Users Groupwww.psoug.org
>
> > I don't think this is an Oracle issue.  Oracle is just like an other
> > app (I know it hurts to hear that) when it comes to stuff being
> > physically written to physical disk.
>
> > The disk subsystem controls what is physically written when and
> > where.  Oracle merely twiddles its thumbs until it gets a return code
> > from the storage subsystem.  The subsystem can do what it likes in the
> > meantime.  If it hasn't made it to both subsystems, it will return an
> > error condition to the application doing the write (Oracle in this
> > case).
>
> > I know for a fact that EMC SRDF does it this way, as we use it.
>
> Well said.
>
> Palooka

Thanks to all for the valuable/insightful thoughts on my original post.

It sounds like (in summary), that using DG will save network bandwidth as opposed to relying on SAN-based replication. However, CPU utilization on the secondary (disaster-recover) database will most likely be higher when using DG.

Also, there is a quote in "Oracle Data Guard in Oracle Database 10g - Disaster Recovery for the Enterprise" that reads:   "Data Guard allows the administrator to choose whether this redo data is sent synchronously or asynchronously to a standby site."

Can anyone think of any instance when the disaster-recovery database would not be usable in the event of an emergency if you were relying on SAN-based replication??

Thanks again. Received on Mon Oct 06 2008 - 08:33:32 CDT