peer to peer 2008 docs or papers

[Ron]

Hi
I've managed to set up my peer-peer replication under 2008, and have since
been digging around the net about information relating to administering this,
with respect to schema changes, and backup restore etc

The BOL docs seem a bit light here, mentioning 'quiescing' and such procs as
sp_requestpeerresponse and sp_helppeerresponses with little info about why
and what these do.

Does anyone have to hand a more comprehensive link or paper that I can read
to understand what I can and can't do with respect to keeping the replication
up and working well etc?

Any help greatly appreciated as always

[Paul Ibison]

The details about quiescing seem ok:
http://technet.microsoft.com/en-us/library/ms147385.aspx. This is not the
normal use of the word in the sense of "pausing" but the process itself
makes sense. Basically the procs are used to ensure that nothing is waiting
to be propagated to the nodes involved. In other words this is pretty much
an offline process as far as the peer-to-peer setup is concerned. Assuming
this is done and correct responses involved, then the schema changes will
propagate as per usual. If not done, then the schema change to the local
publication could invalidate the transactions waiting to propagate to it
from another node.
HTH,
Paul Ibison

[Hilary Cotter]

This is a doc bug. It is no longer necessary to quiese a p2p topology when
making schema changes.

This documentation actually refers to the SQL 2005 version.

"Paul Ibison" <Paul....@ReplicationAnswers.Com.(donotspam)> wrote in
message news:05BA5727-6FCE-4760...@microsoft.com...

[Ron]

Hi,

Thanks all for taking the time to reply as always

Just for my clarity, i'm using sql 2008. Are we saying that I don't need to
'quiese' to make schema changes?

"Hilary Cotter" wrote:

> .
>

[Paul Ibison]

Perhaps Hilary is referring to a separate issue or different setup?

I have just tested this in a setup with 2 peers. After initialization I stop
the 2 distribution agents. On one peer I drop a column and on the other I
update a row on the same column. When I restart the distribution agents the
order of restarting is crucial: one order will fail and the other succeed.
If the drop column goes first, the update will try to update a non-existant
column and fail with an "Invalid column name" error. This explains the need
to quiesce. The other order would of course work - update followed by the
drop column.

So "quiesce" refers to every node apart from the one where I do the drop
column - if any of the other nodes insert/update a row in the table then
their distribution agent could fail if the agents synchronize in the wrong
order.

HTH,

Paul Ibison

[Ron]

Hi Paul

This test is useful for my understanding, thanks for that

Apologies for not responding earlier. It seems that even tho i click 'Notify
me of replies', I never get notified...hmm!! perhaps I should raise that on
another forum! lol!

(Ps, nice work on the deep dives chapters Gents, just got my copy last week.)