SEO

The following text is taken from IBM Red book

http://www.redbooks.ibm.com/redpiece...7488.html?Open
============================
7.1 Redirected Write capability
Redirected Writes provide an automatic transfer from the Secondary to the
Primary node when an update operation is to be performed. This is done without
taking a distributed lock on the row at Secondary and the Primary. Instead, the
Primary server uses a form of optimistic concurrency. This means that the
Primary server will consider the write operation only if the before image is
identical between the Primary and the Secondary server. If it is not, then the
server will consider the operation as having encountered a deadlock type of
error
and abort the operation.
7.1.1 A Redirected Write environment
In this section we describe the behavior of Primary and Secondary servers in a
Redirected Write environment. When a client application connects to a
Secondary server, the server begins an SQL session in which the application can
start an SQL transaction. When any DML operations, such as INSERT, DELETE,
and UPDATE, are executed in that transaction, the Secondary server transports
those operations to the Primary server over the network. On receiving those
operations, the Primary server applies them and sends the logical logs to the
Secondary server. On receiving the logical logs, the Secondary server replays
the logs and thus makes the changes performed by the client persistent at the
Secondary server.
During the period in which the write operations are sent and then received back
from Primary, through the logical logs, the Secondary server makes the changes
available to the SQL transaction by caching them in memory.
========================================

Two questions:

1. How does the secondary node determine that the before image of primary and
secondary server are same.

2. What is meant by "During the period in which the write operations are sent
and then received back from Primary, through the logical logs, the Secondary
server makes the changes available to the SQL transaction by caching them in
memory.

Can anyone from IBM explain this in bit more detail.

Thanks.

From: <dcruncher4@aim.com>

>
> Two questions:
>
> 1. How does the secondary node determine that the before image of primary
> and
> secondary server are same.
>
> 2. What is meant by "During the period in which the write operations are
> sent
> and then received back from Primary, through the logical logs, the
> Secondary
> server makes the changes available to the SQL transaction by caching them
> in
> memory.
>
> Can anyone from IBM explain this in bit more detail.
>


I'm not from IBM but I can take a crack at this until the IBMers can
respond.

1. The Primary will check to see that the row has not changed by comparing
2 optional shadow columns (called VERCOLS) that contain the row version id
and a row checksum. If you choose to not use VERCOLS, the entire contents
of the row before the update will be sent from the Secondary to the Primary
to verify the row is not stale.

2. I don't know exactly, but I would imagine that the buffered version of
the page on the Secondary is modified to reflect the change.

A follow up question for the IBMers.

1. What happens to the cached version of the modified row on the secondary
if the attempt to modify the row on the primary fails?

Andrew

Andrew Ford wrote:
> From: <dcruncher4@aim.com>
>
>> Two questions:
>>
>> 1. How does the secondary node determine that the before image of primary
>> and
>> secondary server are same.
>>
>> 2. What is meant by "During the period in which the write operations are
>> sent
>> and then received back from Primary, through the logical logs, the
>> Secondary
>> server makes the changes available to the SQL transaction by caching them
>> in
>> memory.
>>
>> Can anyone from IBM explain this in bit more detail.
>>
>
>
> I'm not from IBM but I can take a crack at this until the IBMers can
> respond.
>
> 1. The Primary will check to see that the row has not changed by comparing
> 2 optional shadow columns (called VERCOLS) that contain the row version id
> and a row checksum. If you choose to not use VERCOLS, the entire contents
> of the row before the update will be sent from the Secondary to the Primary
> to verify the row is not stale.
>
> 2. I don't know exactly, but I would imagine that the buffered version of
> the page on the Secondary is modified to reflect the change.


Close enough...

>
> A follow up question for the IBMers.
>
> 1. What happens to the cached version of the modified row on the secondary
> if the attempt to modify the row on the primary fails?

The locally cached version is known only by the session which performs
the update on the secondary. If the operation fails, then the cached
entry is invalidated so that the local session does not see the changes
any longer.
>
> Andrew
>
>