Re: Dataguard / Archive Logs
- From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
- To: David Sharples <davidsharples@xxxxxxxxx>
- Date: Wed, 01 Jun 2005 21:09:29 +0200
David,
Is the SAN replicating synchronously or asynchronously?
Data Guard needs less bandwidth than storage based replication. Most of
the times SAN's are configured to replicate asynchrously. Just think of
the amount of data that needs to be sent over when storage is
replicated: Redo writes (all members), archive copies (maybe also
redundant?), the writes to data files, and the updates of the
controlfile. Mind that storage based replication is often disk block
based, or even disktrack-based! You can imagine what amount of data
needs to go through the pipe for that. Compare that with just sending
the redo entries with Data Guard. The standby site will take care of
applying them, writing to data files and performing the archive job
locally.
Furthermore, Data Guard gives you the feature applying the redo at a
delayed basis. This gives you the opportunity to recover from 'human'
errors, e.g. dropping a table. When the delay is 4 hours, and you
discover the problem within that time, you can make the standby
read-only and copy the missing table to the primary. Of course Flashback
offers this option also, but at the cost of extra I/O on the primary.
The delay comes at the cost of longer failover time, becouse the redo of
the 4 hours delay need to be applied at that time.
SAN replication wil just replicate any error on the primary to the
standby. With Data Guard you can put the standby in read-only mode (e.g.
for reporting purposes). In the meantime it will continue receiving the
redo, your transactions are still safe. Again, at the cost of somewhat
longer failover time bevause of extra redo waiting to be applied. Some
of my DG customers decided to have two standby's for some reasons: The
delay is enabled at only one site (most of the times the remote
standby), the other (the 'local' standby in the same building) is as
actual as possible.
FInally, SAN replication pretty much requires the same (expensive) iron
on both ends. Data Guard can have a highly sophistacated SAN at one end,
and some cheap system with cheaper disks at the other end. Of course
that might hurt performance and availability in a failed over situation,
but having two cheap standby's can be better than just one expensive
one.
It's getting a little bit a chapter of a book in stead of a post to
elaborate on all that, but maybe this may help you to determine the
right configuration for your situation.
Best regards,
Carel-Jan Engel
===
If you think education is expensive, try ignorance. (Derek Bok)
===
On Wed, 2005-06-01 at 20:29, David Sharples wrote:
> I think you are right, im not convicned it will work though - doesnt
> seem right to me
>
> On 6/1/05, Dimitre Radoulov <cichomitiko@xxxxxxxxx> wrote:
> > do you really need DataGuard with
> > this configuration?
> >
> > You just can stop the primary and start the other one ... or you need the
> > secondary open in read only(and you could open it anyway without DataGuard)?
--
//www.freelists.org/webpage/oracle-l
Other related posts:
