Hi,
I have the following scenario, and need to configure
replication for this. Pls advice.
We have 3 SQL server databases, at 3 locations on SQL
server 2000 servers. They are connected over WAN by 2
MBPS link (triangle). I have to configure replication on
this. Database has around 200 tables, and size of
database would be around 200-500 MB each. Changes would
be minor on daily basis.
I have these servers at following locations.
Loc1 (HeadOffice)
Loc2 (branch office)
Loc3 (branch office)
Data has to replicate from Loc2 and Loc3 to Loc1 at short
intervals during the day.
Somewhere in midnight (off peak hours), data has to
replicate from Loc1 to Loc2 and Loc3 (for changes made at
Loc1 to be reflected in Loc2 and Loc3).
These database are modified only during the day, and
number of users at each location will not exceed 30.
I have following queries
- Can I configure Transactional replication for Loc2 ->
Loc1 and Loc3 -> Loc1 to replicate at short intervals.
And additionally Snapshot to happen at midnight from
Loc1 -> Loc2 and Loc3.
Or do I require Merge replication for this scenario. (or
any other solution you think would suit this requirement)
Pls suggest.
Thanx,
Shrikant,
the easiest scenario would be mege replication. Snapshot will copy over the
whole tables and unless the tables are small or all rows are always updated,
this is not recommended, and you'd have to set up replication each time
after the snapshot - possible but not so nice. Also, if the data is
partitioned then great, but if not then merge will take care of that with
the conflict resolvers. The only thing is that you won't be able to easily
prevent the download of data from Loc1 until the evening, as these changes
will propagate during the frequent synchronizations. If this is not at all
desirable, than you might have to consider a more radical solution - you
could have Loc1 as the publisher but use unidirectional merge with the
subscribers and reinitialize each evening.
HTH,
Paul Ibison
|||Hi Paul,
Thanx for your reply.
But would not be using the bi-directional transactional
replication solve this ?
Loc1 acts as Publisher with Loc2 and Loc3 as subscribers.
And then Loc2 and Loc3 as Publishers, and Loc1 as
Subscriber ?
regds,
Shrikant
>--Original Message--
>Shrikant,
>the easiest scenario would be mege replication. Snapshot
will copy over the
>whole tables and unless the tables are small or all rows
are always updated,
>this is not recommended, and you'd have to set up
replication each time
>after the snapshot - possible but not so nice. Also, if
the data is
>partitioned then great, but if not then merge will take
care of that with
>the conflict resolvers. The only thing is that you won't
be able to easily
>prevent the download of data from Loc1 until the
evening, as these changes
>will propagate during the frequent synchronizations. If
this is not at all
>desirable, than you might have to consider a more
radical solution - you
>could have Loc1 as the publisher but use unidirectional
merge with the
>subscribers and reinitialize each evening.
>HTH,
>Paul Ibison
>
>.
>
|||Shrikant,
this would be an option. If you expect conflicts then it can become terribly complicated, and the initial setup is not straightforward, but you're right - it is in some ways a simpler solution. To You might want to have a look at the most recent issue of
SQL Server magazine if you're thinking of going down this route - there is a nice article on setting it up.
Regards,
Paul Ibison
Showing posts with label advice. Show all posts
Showing posts with label advice. Show all posts
Monday, March 26, 2012
Replication design
Hi,
I'm new to MSSQL replication, and was hoping for some advice as to
recommended practices for my scenario.
I will have a 4 SQL server scenario at four locations connected through a
TCP/IP wan (i.e. each site is connected to the internet).
One of the sites is the headquarters site. Some tables are only updated
at the headquarter, and these changes should replicate to the other sites.
For example the table that contains the list of all products is only updated
at the main site.
Each site (including the headquarter) inserts many transactions within the
day. I wish for all the transactions to replicate to all sites. For
example, if I insert a transaction at site A, I want this transaction to
replicate to site B, site C, and headquarters as well. The same goes for
all sites. Ideally this should happen within an hour from when the
transaction was entered.
The databases will be about 10-15GB each I think.
Any comments or suggestions appreciated,
Edgard
Edgard,
for those tables which are only updated at HO, I'd recommend transactional
replication.
For all other tables I'd recommend merge.
One hour's latency should not be a problem, provided you have the necessary
bandwidth and the amount of changes is not too great.
Regards,
Paul Ibison
I'm new to MSSQL replication, and was hoping for some advice as to
recommended practices for my scenario.
I will have a 4 SQL server scenario at four locations connected through a
TCP/IP wan (i.e. each site is connected to the internet).
One of the sites is the headquarters site. Some tables are only updated
at the headquarter, and these changes should replicate to the other sites.
For example the table that contains the list of all products is only updated
at the main site.
Each site (including the headquarter) inserts many transactions within the
day. I wish for all the transactions to replicate to all sites. For
example, if I insert a transaction at site A, I want this transaction to
replicate to site B, site C, and headquarters as well. The same goes for
all sites. Ideally this should happen within an hour from when the
transaction was entered.
The databases will be about 10-15GB each I think.
Any comments or suggestions appreciated,
Edgard
Edgard,
for those tables which are only updated at HO, I'd recommend transactional
replication.
For all other tables I'd recommend merge.
One hour's latency should not be a problem, provided you have the necessary
bandwidth and the amount of changes is not too great.
Regards,
Paul Ibison
Tuesday, March 20, 2012
Replication and Rebuild index
Hi:
If replication and rebuild index happen at the same time, which one
will fail ?
Please advice
JCVoonThis really depends on a few factors. Firstly, how do you rebuild your
indexes? DBCC DBREINDEX and DBCC INDEXDEFRAG are considered offline and
online operations respectively, due to the different locking behaviour. In
SQL Server 2005 this corresponds to ALTER INDEX ALL on tablename REBUILD
WITH (ONLINE = ON) and ALTER INDEX ALL on tablename REBUILD WITH (ONLINE =OFF), or the old DBCC syntax can be used as well. The online options should
be compatible with the distribution or merge agent running while the offline
is less likely. It really all depends on the QUERYTIMEOUT parameter's value
and how this realtes to the time taken to rebuild the table indexes.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)|||It depends on which one starts first. index rebuild requires an exclusive
lock on the table. If the rebuild starts first, replication will not be able
to update it until the rebuild finishes. If the replication is updating the
table when the index rebuild attempts to run, it will fail because it can not
get an exclusive lock.
Regards
John
"jcvoon" wrote:
> Hi:
> If replication and rebuild index happen at the same time, which one
> will fail ?
> Please advice
> JCVoon
>
If replication and rebuild index happen at the same time, which one
will fail ?
Please advice
JCVoonThis really depends on a few factors. Firstly, how do you rebuild your
indexes? DBCC DBREINDEX and DBCC INDEXDEFRAG are considered offline and
online operations respectively, due to the different locking behaviour. In
SQL Server 2005 this corresponds to ALTER INDEX ALL on tablename REBUILD
WITH (ONLINE = ON) and ALTER INDEX ALL on tablename REBUILD WITH (ONLINE =OFF), or the old DBCC syntax can be used as well. The online options should
be compatible with the distribution or merge agent running while the offline
is less likely. It really all depends on the QUERYTIMEOUT parameter's value
and how this realtes to the time taken to rebuild the table indexes.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)|||It depends on which one starts first. index rebuild requires an exclusive
lock on the table. If the rebuild starts first, replication will not be able
to update it until the rebuild finishes. If the replication is updating the
table when the index rebuild attempts to run, it will fail because it can not
get an exclusive lock.
Regards
John
"jcvoon" wrote:
> Hi:
> If replication and rebuild index happen at the same time, which one
> will fail ?
> Please advice
> JCVoon
>
Monday, March 12, 2012
Replication Advice needed
Hello,
We are developing a software for a logistic company, which will have around 1000 branches, and we need to synchronize the database(SQL Server) between all the branches using the database at web server, i.e the branches can get the new data from the web server,as well as push the data at the web server, please tell us how can we accomplish this task,
ThanksThis wont work if I'm reading this correctly. You want to have a server both receiving and pushing data. Besides using it as the web server and replication on one server to feed 1000 sites. I say get 4 deal Racs Use
1. database server
2. replication server
3. webserver
4. backupserver.
at sites, have 2 server interfaces and one for live and the other for replication. Users should never get the live data. They only see the replication and thats transparent to them. Hope this helps. I'd also checkout lazydba.com real good info
We are developing a software for a logistic company, which will have around 1000 branches, and we need to synchronize the database(SQL Server) between all the branches using the database at web server, i.e the branches can get the new data from the web server,as well as push the data at the web server, please tell us how can we accomplish this task,
ThanksThis wont work if I'm reading this correctly. You want to have a server both receiving and pushing data. Besides using it as the web server and replication on one server to feed 1000 sites. I say get 4 deal Racs Use
1. database server
2. replication server
3. webserver
4. backupserver.
at sites, have 2 server interfaces and one for live and the other for replication. Users should never get the live data. They only see the replication and thats transparent to them. Hope this helps. I'd also checkout lazydba.com real good info
Replication Advice Needed
Environment:
SQL 2000 SP4 on Windows 2003
Replication Type = Transactional Replication
Servers involved = server 1, server 2
Activity = server 1 has lots of activity for inserts,updates but no deletes
for 7:30 AM - 6 PM NY TIME then it becomes stable and becomes active again
from 9 PM - 4 AM NY TIME for offshore processing.
Situation:
I need to set up an environment to support minimum latency as low as few
seconds or so. I need to make sure that two systems stay in sync with Data
and schema though there are very less chances of making schema changes. I
thought of considering replication but there are few concerns.
1. Data can be replicated very quickly but then schema changes are a big
concern as replication blocks most of the schema changes.
2. When a new table is added on server A, I want it to be added to a server
B as well which can not happen without adding this table to a new or existing
publication and run snapshot\distribution agent etc..
3. On existing stored procedure, if I replicate the schema and executions,
do the subsequent alter procedure commands also get replicated? OR if the
proc is altered on Server 1, I need to manually run ALTER Table on server 2.
Then I thought of using Log Shipping and ran into following concerns.
1. If I set up transaction log backup very frequently on server 1 say every
minute, performance becomes a nightmare which is not acceptable at all in
this situation.
One more question on replication:
If I take the publisher server backup and restore on subscriber, how would
it affect replication? Would the replication be still funtional after restore
is done on subscriber?
Please advice if replication is a right approach in this scenario and if I
do implement replication, what additional steps would I need to take should
new schema changes appear. If Replication is not a good approach and Log
Shipping is a performance bottleneck, what other directions can I look at,.
Thanks for reading my request and I appreciate your suggestions.
Thanks in advance.
Nitin
Nitin,
to clarify a bit, I'd like to know what the second server is to be used
for - is it a HA box, or is it to be used for reporting?
Also, how definite are you on the idea of a few seconds latency?
My first reflex is database mirroring, with database snapshots if you
require a reporting solution, but let's find out more first.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul:
Thanks fror your response. Second server is used only in read only mode.
There wont be new transactions other than what are happening on Server 1.
Also, Database mirroring is not supported on SQL 2005 yet and is turned off.
I dont know if we can mirror DB in SQL 2000. Few seconds latecy is ok. I have
spoken to people and they have said latency shouldnt go in minutes, seconds
are OK as nothing can be instantaneous in real world.
What are your thoughts on it.
-Nitin
"Paul Ibison" wrote:
> Nitin,
> to clarify a bit, I'd like to know what the second server is to be used
> for - is it a HA box, or is it to be used for reporting?
> Also, how definite are you on the idea of a few seconds latency?
> My first reflex is database mirroring, with database snapshots if you
> require a reporting solution, but let's find out more first.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Nitin,
database mirroring is not yet supported, but it is available. Some companies
are using it but admittedly it is a little worrying in a production
environment if it is not yet supported. Anyway, log shipping would have too
long a latency and mirroring doesn't exist in SQL Server 2000 so
transactional replication would be the obvious choice. Whether you'll
achieve the latency you require is difficult to say - I guess you'll need to
do a POC.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul:
Since this is production environment, I really cant use DB Mirroring since
it is not supported if somethig goes wrong tomorrow and I cant get a support
on it, I will be in trouble. What do you recommend for moving the schema
changes to server 2 when changes were made on server 1 without replication
being stopped. For example: a dba can create index on an article without
affecting replication but now two servers are out of sync with schema. Do you
think there is a way to script out the schema differences and some automated
job can run those schema changes on server 2.
Nitin
"Paul Ibison" wrote:
> Nitin,
> database mirroring is not yet supported, but it is available. Some companies
> are using it but admittedly it is a little worrying in a production
> environment if it is not yet supported. Anyway, log shipping would have too
> long a latency and mirroring doesn't exist in SQL Server 2000 so
> transactional replication would be the obvious choice. Whether you'll
> achieve the latency you require is difficult to say - I guess you'll need to
> do a POC.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Nitin,
as you're on SQL 2000, the process is more manual but you can use
sp_repladdcolumn and sp_repldropcolumn for most things (including many
schema changes http://www.replicationanswers.com/AddColumn.asp). As I say,
this is manual, and you'll need to ensure this is done on the publications.
Index changes aren't propagated in SQL 2005 either so I tend to do these
manually although if I had a lot of subscribers or disconnected pull
subscribers I'd use sp_addscriptexec. Keeping the databases in sync will
require a strict way of working, and sometimes you might have to
reinitialize a table (yes, it's possible in transactional replication using
SQL 2000).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
SQL 2000 SP4 on Windows 2003
Replication Type = Transactional Replication
Servers involved = server 1, server 2
Activity = server 1 has lots of activity for inserts,updates but no deletes
for 7:30 AM - 6 PM NY TIME then it becomes stable and becomes active again
from 9 PM - 4 AM NY TIME for offshore processing.
Situation:
I need to set up an environment to support minimum latency as low as few
seconds or so. I need to make sure that two systems stay in sync with Data
and schema though there are very less chances of making schema changes. I
thought of considering replication but there are few concerns.
1. Data can be replicated very quickly but then schema changes are a big
concern as replication blocks most of the schema changes.
2. When a new table is added on server A, I want it to be added to a server
B as well which can not happen without adding this table to a new or existing
publication and run snapshot\distribution agent etc..
3. On existing stored procedure, if I replicate the schema and executions,
do the subsequent alter procedure commands also get replicated? OR if the
proc is altered on Server 1, I need to manually run ALTER Table on server 2.
Then I thought of using Log Shipping and ran into following concerns.
1. If I set up transaction log backup very frequently on server 1 say every
minute, performance becomes a nightmare which is not acceptable at all in
this situation.
One more question on replication:
If I take the publisher server backup and restore on subscriber, how would
it affect replication? Would the replication be still funtional after restore
is done on subscriber?
Please advice if replication is a right approach in this scenario and if I
do implement replication, what additional steps would I need to take should
new schema changes appear. If Replication is not a good approach and Log
Shipping is a performance bottleneck, what other directions can I look at,.
Thanks for reading my request and I appreciate your suggestions.
Thanks in advance.
Nitin
Nitin,
to clarify a bit, I'd like to know what the second server is to be used
for - is it a HA box, or is it to be used for reporting?
Also, how definite are you on the idea of a few seconds latency?
My first reflex is database mirroring, with database snapshots if you
require a reporting solution, but let's find out more first.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul:
Thanks fror your response. Second server is used only in read only mode.
There wont be new transactions other than what are happening on Server 1.
Also, Database mirroring is not supported on SQL 2005 yet and is turned off.
I dont know if we can mirror DB in SQL 2000. Few seconds latecy is ok. I have
spoken to people and they have said latency shouldnt go in minutes, seconds
are OK as nothing can be instantaneous in real world.
What are your thoughts on it.
-Nitin
"Paul Ibison" wrote:
> Nitin,
> to clarify a bit, I'd like to know what the second server is to be used
> for - is it a HA box, or is it to be used for reporting?
> Also, how definite are you on the idea of a few seconds latency?
> My first reflex is database mirroring, with database snapshots if you
> require a reporting solution, but let's find out more first.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Nitin,
database mirroring is not yet supported, but it is available. Some companies
are using it but admittedly it is a little worrying in a production
environment if it is not yet supported. Anyway, log shipping would have too
long a latency and mirroring doesn't exist in SQL Server 2000 so
transactional replication would be the obvious choice. Whether you'll
achieve the latency you require is difficult to say - I guess you'll need to
do a POC.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul:
Since this is production environment, I really cant use DB Mirroring since
it is not supported if somethig goes wrong tomorrow and I cant get a support
on it, I will be in trouble. What do you recommend for moving the schema
changes to server 2 when changes were made on server 1 without replication
being stopped. For example: a dba can create index on an article without
affecting replication but now two servers are out of sync with schema. Do you
think there is a way to script out the schema differences and some automated
job can run those schema changes on server 2.
Nitin
"Paul Ibison" wrote:
> Nitin,
> database mirroring is not yet supported, but it is available. Some companies
> are using it but admittedly it is a little worrying in a production
> environment if it is not yet supported. Anyway, log shipping would have too
> long a latency and mirroring doesn't exist in SQL Server 2000 so
> transactional replication would be the obvious choice. Whether you'll
> achieve the latency you require is difficult to say - I guess you'll need to
> do a POC.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Nitin,
as you're on SQL 2000, the process is more manual but you can use
sp_repladdcolumn and sp_repldropcolumn for most things (including many
schema changes http://www.replicationanswers.com/AddColumn.asp). As I say,
this is manual, and you'll need to ensure this is done on the publications.
Index changes aren't propagated in SQL 2005 either so I tend to do these
manually although if I had a lot of subscribers or disconnected pull
subscribers I'd use sp_addscriptexec. Keeping the databases in sync will
require a strict way of working, and sometimes you might have to
reinitialize a table (yes, it's possible in transactional replication using
SQL 2000).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Replication Advice
Hi all,
I am in need of some replication advice...
We have the following scenario:
Publisher running SQL Server 2005 with SP1
Multiple subscribers (at the minute, 10, but there will eventually be
around 30), running a mixture of SQL Server 2005 Express and SQL
Server 2005.
Now, I am fairly inexperienced with replication via the web service
(IIS), and have started looking at this particular project at work
using replication, and noticed something that does not seem right.
Whenever any schema changes are committed, we are forced to regenerate
the complete snapshot, and as such, the subscribers are forced to
download and re-initialise their snapshot.
Surely this is incorrect? Is there any way of configuring incremental
snapshot changes?
The big problem we have is that there database is around 200Mb, and we
have users who pay per MB...
Sorry for lack of information, as I say, I'm fairly new to Server to
Client replication - I normally only configure Server to Server!
Regards,
Andy Neillans
I too would be interested in this reply because my databasr is 1.6gb and to
generate a snapshot every time a schema changes is a real pain in the
butt....
Is it possible to create a snapshot on the publisher and then 'part' copy
over the new schema and tables to the subscriber (in my case).
Thanks
"Andrew Neillans" wrote:
> Hi all,
> I am in need of some replication advice...
> We have the following scenario:
> Publisher running SQL Server 2005 with SP1
> Multiple subscribers (at the minute, 10, but there will eventually be
> around 30), running a mixture of SQL Server 2005 Express and SQL
> Server 2005.
> Now, I am fairly inexperienced with replication via the web service
> (IIS), and have started looking at this particular project at work
> using replication, and noticed something that does not seem right.
> Whenever any schema changes are committed, we are forced to regenerate
> the complete snapshot, and as such, the subscribers are forced to
> download and re-initialise their snapshot.
> Surely this is incorrect? Is there any way of configuring incremental
> snapshot changes?
> The big problem we have is that there database is around 200Mb, and we
> have users who pay per MB...
> Sorry for lack of information, as I say, I'm fairly new to Server to
> Client replication - I normally only configure Server to Server!
> Regards,
> Andy Neillans
>
I am in need of some replication advice...
We have the following scenario:
Publisher running SQL Server 2005 with SP1
Multiple subscribers (at the minute, 10, but there will eventually be
around 30), running a mixture of SQL Server 2005 Express and SQL
Server 2005.
Now, I am fairly inexperienced with replication via the web service
(IIS), and have started looking at this particular project at work
using replication, and noticed something that does not seem right.
Whenever any schema changes are committed, we are forced to regenerate
the complete snapshot, and as such, the subscribers are forced to
download and re-initialise their snapshot.
Surely this is incorrect? Is there any way of configuring incremental
snapshot changes?
The big problem we have is that there database is around 200Mb, and we
have users who pay per MB...
Sorry for lack of information, as I say, I'm fairly new to Server to
Client replication - I normally only configure Server to Server!
Regards,
Andy Neillans
I too would be interested in this reply because my databasr is 1.6gb and to
generate a snapshot every time a schema changes is a real pain in the
butt....
Is it possible to create a snapshot on the publisher and then 'part' copy
over the new schema and tables to the subscriber (in my case).
Thanks
"Andrew Neillans" wrote:
> Hi all,
> I am in need of some replication advice...
> We have the following scenario:
> Publisher running SQL Server 2005 with SP1
> Multiple subscribers (at the minute, 10, but there will eventually be
> around 30), running a mixture of SQL Server 2005 Express and SQL
> Server 2005.
> Now, I am fairly inexperienced with replication via the web service
> (IIS), and have started looking at this particular project at work
> using replication, and noticed something that does not seem right.
> Whenever any schema changes are committed, we are forced to regenerate
> the complete snapshot, and as such, the subscribers are forced to
> download and re-initialise their snapshot.
> Surely this is incorrect? Is there any way of configuring incremental
> snapshot changes?
> The big problem we have is that there database is around 200Mb, and we
> have users who pay per MB...
> Sorry for lack of information, as I say, I'm fairly new to Server to
> Client replication - I normally only configure Server to Server!
> Regards,
> Andy Neillans
>
Replication advice
Hello,
I have 30 remote WinXP sites connected to a Win 2K3 server via VPN.
Each remote site runs MSDE. Basically, they are automated data aquisition
machines recording into a DB about 200K of data every 15 minutes.
The data at each remote site needs to be replicated into its own DB on the
Win 2K3 server on a regular basis, hopefully within 1 or 2 hours of being
first recorded..
What form of replication would be recommended for this scenario?
Thank you
Unfortunately MSDE cannot be a transactional publisher which is the best fit
for what you are trying to do. What you will have to do is use merge
replication with the with the exchangetype being upload only.
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
"MikeH" <MikeH@.community.nospam> wrote in message
news:1AD6F4E7-B7B0-412E-BA9F-D05B7BE6168F@.microsoft.com...
> Hello,
> I have 30 remote WinXP sites connected to a Win 2K3 server via VPN.
> Each remote site runs MSDE. Basically, they are automated data aquisition
> machines recording into a DB about 200K of data every 15 minutes.
> The data at each remote site needs to be replicated into its own DB on the
> Win 2K3 server on a regular basis, hopefully within 1 or 2 hours of being
> first recorded..
> What form of replication would be recommended for this scenario?
> Thank you
I have 30 remote WinXP sites connected to a Win 2K3 server via VPN.
Each remote site runs MSDE. Basically, they are automated data aquisition
machines recording into a DB about 200K of data every 15 minutes.
The data at each remote site needs to be replicated into its own DB on the
Win 2K3 server on a regular basis, hopefully within 1 or 2 hours of being
first recorded..
What form of replication would be recommended for this scenario?
Thank you
Unfortunately MSDE cannot be a transactional publisher which is the best fit
for what you are trying to do. What you will have to do is use merge
replication with the with the exchangetype being upload only.
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
"MikeH" <MikeH@.community.nospam> wrote in message
news:1AD6F4E7-B7B0-412E-BA9F-D05B7BE6168F@.microsoft.com...
> Hello,
> I have 30 remote WinXP sites connected to a Win 2K3 server via VPN.
> Each remote site runs MSDE. Basically, they are automated data aquisition
> machines recording into a DB about 200K of data every 15 minutes.
> The data at each remote site needs to be replicated into its own DB on the
> Win 2K3 server on a regular basis, hopefully within 1 or 2 hours of being
> first recorded..
> What form of replication would be recommended for this scenario?
> Thank you
Subscribe to:
Posts (Atom)