In short, I am looking for a step by step best practice for making
database changes to a database that is using merge replication between
multiple locations.
Background information:
Using SQL 2000, I have a publisher and 3 subscribers of a very large
database. The database is in use 24/7/365. The entire database is
replicated.
In the next release of the application I need to update views, add
fields to certain tables, add entirely new tables, constraints, and
indexes.
Is there a way to implement these changes at the publisher and have it
update the subscribers or at least update the publication information
as the new tables will need to be replicated as well and I want to make
sure all associated rowguids, triggers, etc. are created internally for
replication.
Pls have a look at sp_repladdcolumn and sp_repldropcolumn in BOL. Also there
is my article on making changes to an existing column:
http://www.replicationanswers.com/AddColumn.asp
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||To replicate schema only objects (like views, functions, stored procedures,
etc) use snapshot replication.
If you use sp_addmergearticle to add new articles (tables) to your
publication a snapshot of all of your tables will be generated. If you can
use a separate publication for these new articles.
Otherwise other schema changes can be performed by using sp_repladdcolumn
and sp_repldropcolumn. These procs are limited in what they can do, so you
might find yourself having to recreate the publications in some cases.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Steve B" <SBaxter.RBS@.gmail.com> wrote in message
news:1162949137.394153.305500@.k70g2000cwa.googlegr oups.com...
> In short, I am looking for a step by step best practice for making
> database changes to a database that is using merge replication between
> multiple locations.
> Background information:
> Using SQL 2000, I have a publisher and 3 subscribers of a very large
> database. The database is in use 24/7/365. The entire database is
> replicated.
> In the next release of the application I need to update views, add
> fields to certain tables, add entirely new tables, constraints, and
> indexes.
> Is there a way to implement these changes at the publisher and have it
> update the subscribers or at least update the publication information
> as the new tables will need to be replicated as well and I want to make
> sure all associated rowguids, triggers, etc. are created internally for
> replication.
>
Tuesday, March 20, 2012
Best Practices
Labels:
betweenmultiple,
database,
makingdatabase,
merge,
microsoft,
mysql,
oracle,
practice,
practices,
replication,
server,
sql,
step
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment