Adding New Column & updating bulk data in merge replication

Hi,
We have about 50 databases (SQL Server 2000, SP3) which are merge
replicated. We merge replicate about 100 odd tables in each of these
database. We need to add couple of columns in one of our major transaction
table where most insert/updates are being done. This table presently on
average has 5 lacs records.
During testing, we noticed that it takes about 60-80 minutes to add a
column in this table. Considering the # of database we have where the change
need to implemented, we will not be able to plan the upgrade without
production downtime. For upgrade 50 database it will take about 50 hours.
What are the options available in Replication so this can be done quickly
w/o any production downtime.
Adding to this, in one of the column we have added to the transaction table
, we need to update a new value. On testing we found that for 5 lacs records
it takes anyway between 2-3 hours. This takes roughly another 75 hours for
us to do this update after adding the new column in the table. How can this
be speeded up ?
thanks,
Soura
What's a lacs?
Basically there is probably no good solution for this. I would look at doing
a sync. Then creating my publication and then backing it up and restoring it
to all the subscribers and doing a no sync subscription, or I would look at
regenerating a snapshot and distributing it after you have made the column
change.
Hilary Cotter
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
"SouRa" <SouRa@.discussions.microsoft.com> wrote in message
news:A19172BF-E8AC-4BB7-9FED-87EEC5353D89@.microsoft.com...
> Hi,
> We have about 50 databases (SQL Server 2000, SP3) which are merge
> replicated. We merge replicate about 100 odd tables in each of these
> database. We need to add couple of columns in one of our major transaction
> table where most insert/updates are being done. This table presently on
> average has 5 lacs records.
> During testing, we noticed that it takes about 60-80 minutes to add a
> column in this table. Considering the # of database we have where the
> change
> need to implemented, we will not be able to plan the upgrade without
> production downtime. For upgrade 50 database it will take about 50 hours.
> What are the options available in Replication so this can be done quickly
> w/o any production downtime.
> Adding to this, in one of the column we have added to the transaction
> table
> , we need to update a new value. On testing we found that for 5 lacs
> records
> it takes anyway between 2-3 hours. This takes roughly another 75 hours for
> us to do this update after adding the new column in the table. How can
> this
> be speeded up ?
> thanks,
> Soura
|||5 lacs is 500 K or 500 thousand i.e 500,000
lacs is primarily an indian unit of measurment. 1 lac is 0.1 million
"Hilary Cotter" wrote:

> What's a lacs?
> Basically there is probably no good solution for this. I would look at doing
> a sync. Then creating my publication and then backing it up and restoring it
> to all the subscribers and doing a no sync subscription, or I would look at
> regenerating a snapshot and distributing it after you have made the column
> change.
> --
> Hilary Cotter
> 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
> "SouRa" <SouRa@.discussions.microsoft.com> wrote in message
> news:A19172BF-E8AC-4BB7-9FED-87EEC5353D89@.microsoft.com...
>
>

Adding column in replicated table with nosync initialization

I'm not sure how can I replicate the table which is part of nosync
transactional replication? I have to add a column in that table and to
replicate again. I'm using no-sync initialization?
Thanks,
BaniSQL
I want to add some additional explainations regarding this issue. I'm
currently running transactional replication with nosync initialization. In
one of the articles - replicating table I want to add 2 additional fields for
future usage. Some good explainations exists in the www.replicationanwers.com
website, but I'm not so sure what I have exactly to do? Removing the table
from replication, adding 2 additional fileds ... thereafter do I have to run
all the process from the beginning or I can create the same table in the
subscriber with the new structure, make sure that all records exists in
subscriber same as they are in publisher, and drop the Push subscribtion and
run again (with no-sync initialization, knowing that the structure and data
already exists in the subscriber?)
Can somebody give me some additional informations if I'm right or not?
Thanks, BaniSQL.
"BaniSQL" wrote:

> I'm not sure how can I replicate the table which is part of nosync
> transactional replication? I have to add a column in that table and to
> replicate again. I'm using no-sync initialization?
> Thanks,
> BaniSQL
|||Interesting. I just tried this and even though my subscription was a nosync
one, using sp_repladdcolumn on the publisher propagated the change to the
subscriber, along with the new set of stored procedures. This was quite
unexpected for me as well, but it means that you don't need to jump through
loads of hoops here and can make your changes quite easily.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Hi Paul,
As I understood it worked simply by only running sp_repladdcolumn in the
publisher database, even without generating custom procedures for
INSERT/UPDATE/DELETE on the Subscriber for this article/table?
Thanks,
BaniSQL.
"Paul Ibison" wrote:

> Interesting. I just tried this and even though my subscription was a nosync
> one, using sp_repladdcolumn on the publisher propagated the change to the
> subscriber, along with the new set of stored procedures. This was quite
> unexpected for me as well, but it means that you don't need to jump through
> loads of hoops here and can make your changes quite easily.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||Exactly - I tried it in a test environment and it worked fine.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .