Re: San-Based replication VS DataGuard replication

From: Madison Pruet <mpruet1_at_verizon.net>
Date: Fri, 03 Oct 2008 20:43:21 GMT
Message-ID: <48E683ED.2050502@verizon.net>


DA Morgan wrote:

> Madison Pruet wrote:

>> DA Morgan wrote:
>>> macdba321 wrote:
>>>> Group,
>>>>  I have a database at Site1 stored on a SAN, and a disaster-recovery
>>>> site2 with identical hardware. They are connected by high-speed fiber.
>>>> (Both SANs are enterprise-class with full journaling capabilities in
>>>> case the connection were ever severed.)
>>>
>>> 4. Data Guard, interestingly enough, is more efficient. What is being
>>>    replicated is the transactions themselves not operating system
>>>    blocks so are shipping less data.
>>

>> This does not make sense. SAN based replication is done only when a
>> physical write occurs. Since DG is pushing the logs to the secondary
>> to achieve replication, it is replicating for any change in the page.
>> Unless Oracle is flushing every page to disk as it is updated, then
>> the impact to performance for a SAN based solution should be much more
>> efficient than pushing the logs to the secondary.
>>

>> Also consider the case with hot pages, such as index pages. DG will
>> be forced to send each update to the page to the secondaries while SAN
>> based replication will only replicate the page as it is flushed to disk.
>>

>> The only logical way that DG could be more efficient would be if the
>> Oracle database flushes every dirty page to disk as it is updated. I
>> can see the logs being flushed immediately, but the data and index
>> pages???? Is that the case?
> 
> You are assuming all Data Guard activities involve log file shipping:
> They do not. Synchronous Data Guard, would never function if a commit
> required waiting for a log file switch. I should have been clearer.

I'll buy that. And also don't forget about the impact of avoiding full/informational logging. Received on Fri Oct 03 2008 - 15:43:21 CDT

Original text of this message