Replication, Primary Keys and Identity Columns

Hello,
Firstly I would like to apologise if I am bringing up a common subject
again, but I cannot find a definative answer to my problem.
I am using daily transactional replication to keep a copy of our SQL
server database offsite, as a disaster recovery measure. I.E. if our
servers go down here, we can flick the DNS to swap over to the offsite
servers.
My problem is that the replication appears to be copying the Indexes
with each table (which I can see by going into EM, Design mode of a
table -> properties -> Indexes/Keys). The Index is there, and even
lists the column associated. However, in the design mode, the column
does not have the Primary Key Icon. How can I ensure that this
happens?
My plan, once I get the primary keys replicated correctly, is to then
use a SQL script to set all primary key columns as Identity (this is
the case on the live server). Is this possible?
Many thanks,
Andrew
You can ensure the PKs are set up correctly by selecting the option on the
snapshot tab of the article properties to include DRI.
Manually altering the PKs on the subscriber to be Identity columns will
cause the stored procedure calls which are used by transactional replication
updates to fail.
If you want a DR server in this way I would recommend using log shipping or
queued updating subscribers.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks Paul.
I take it that Queued updating simply gives you protection against
network problems?
Does log shipping involve a more manual process?
In addtion to this, is there any way to be replicating Permissions on
objects and perhaps even DB logins/users/roles etc?
Cheers.
Andrew
|||Also, I was just wondering:
What if I set the PKs to "Indentity (Not for Replication)". Would this
solve my problem?
|||No - this is for merge and queued updatable subscribers so you'd still lose
the identity property this way.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||It is for those cases where there isn't a need for distributed transactions
ie longer latency. The side effect is that the identity property is retained
and the stored procedure code is altered accordingly.
As for permissions, they'll be handled automatically with log-shipping. In
replication, there is no way to automatically replicate them, so
sp_addscriptexec is usually used (manually).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||I have limited bandwidth to play with. Does log shipping require a lot
of data to be transferred?
Can I schedule this to only occur overnight?
|||The size of the log backup really depends on your particular situation -
you'll have to look at your log backups to determine if this solution will
be feasible. If your database is not large, you might want to zip up the
database backup once it's completed in the evening, then ship it over, unzip
and restore. This is a very simple solution, although you'll have to script
it yourself.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)