So I set up a "Replication/Local Publication" on a Production SQL
2005
Database.
It publishes a Database on the production database.
I then set up a "Replication/Local Subscription" on another Database
we call "Report Database"
that will have reports running on it and querying the Subscription
which is feed from the
production database.
They are syncronizing fine and everthing looks great.
My question is how do I access the Subscription? Can I query it like
a
database
using a "Database Engine Query"? Do I have to create a Database
instance on the "Report Database" Server
feeding off the Subscription?
Am I not going to be able to access the subscription because I don't
have snap shots?
I have no idea what to do now? How can I query the subscription? Can
the subscription act like a database?
I am having problems understanding the question. You have transactional
replication set up correctly and it is syncing ok to the Report Database.
This database can now be queried as per usual. if you are concerned about
blocking, you could use read_committed_snapshot isolation level to help with
the concurrency of reports.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Replication makes copies of tables and their data which by default will be
identical to the tables in the publication database. You should be able to
query them in the same way you query them in the publication database.
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
"jughead" <mike.aarset@.gmail.com> wrote in message
news:1173882913.696871.315700@.o5g2000hsb.googlegro ups.com...
> So I set up a "Replication/Local Publication" on a Production SQL
> 2005
> Database.
> It publishes a Database on the production database.
> I then set up a "Replication/Local Subscription" on another Database
> we call "Report Database"
> that will have reports running on it and querying the Subscription
> which is feed from the
> production database.
>
> They are syncronizing fine and everthing looks great.
>
> My question is how do I access the Subscription? Can I query it like
> a
> database
> using a "Database Engine Query"? Do I have to create a Database
> instance on the "Report Database" Server
> feeding off the Subscription?
> Am I not going to be able to access the subscription because I don't
> have snap shots?
>
> I have no idea what to do now? How can I query the subscription? Can
> the subscription act like a database?
>
|||On Mar 14, 8:12 am, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> Replication makes copies of tables and their data which by default will be
> identical to the tables in the publication database. You should be able to
> query them in the same way you query them in the publication database.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "jughead" <mike.aar...@.gmail.com> wrote in message
> news:1173882913.696871.315700@.o5g2000hsb.googlegro ups.com...
>
>
>
>
> - Show quoted text -
I'm just wondering how to query the subscription.
When the subscription is created on the Report Database is a database
created on that server?
|||On Mar 14, 8:15 am, "jughead" <mike.aar...@.gmail.com> wrote:
> On Mar 14, 8:12 am, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> I'm just wondering how to query the subscription.
> When the subscription is created on the Report Database is a database
> created on that server... Hide quoted text -
> - Show quoted text -
I had an existing database on my Report Server that was the same name
of the Database on the Production Server that is getting publicated.
I am going to do a new publication on a different database and see how
it goes. Thanks guys
|||No, its not, you have to pre-create it.
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
"jughead" <mike.aarset@.gmail.com> wrote in message
news:1173885320.499067.58050@.y66g2000hsf.googlegro ups.com...
> On Mar 14, 8:12 am, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> I'm just wondering how to query the subscription.
> When the subscription is created on the Report Database is a database
> created on that server?
>
|||On Mar 14, 10:58 am, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> No, its not, you have to pre-create it.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "jughead" <mike.aar...@.gmail.com> wrote in message
> news:1173885320.499067.58050@.y66g2000hsf.googlegro ups.com...
>
>
>
>
>
>
>
>
> - Show quoted text -
You guys are right. I don't know what the heck I was doing when I
created my first Publication and Subscription.
Seems that everything is awesome now!
Thanks everyone
sql
Showing posts with label local. Show all posts
Showing posts with label local. Show all posts
Wednesday, March 28, 2012
Monday, March 26, 2012
replication script
Hi All:
I set up a merge replication on my own local computer and works fine, so i
generated a script and tried to run this script in another computer ,which
already has a replication. (i change the server name before running script)
but still got two errors:
Server: Msg 14099, Level 16, State 1, Procedure sp_adddistributor, Line 72
The server 'repl_distributor' is already defined as a Distributor.
The dependent aliases were mapped to the new database owner.
Database owner changed.
Server: Msg 14074, Level 16, State 1, Procedure sp_adddistpublisher, Line
196
The server 'NICK' is already listed as a Publisher.
but the my replication still works even i got two errors when run script.
so how can i change my script to avoid those two errors when running script?
Cheers
Nick
Nick,
comment out the calls to sp_adddistributor and sp_adddistpublisher.
Rgds,
Paul Ibison
|||Thanks Paul.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:#iJ4CmXCFHA.560@.TK2MSFTNGP15.phx.gbl...
> Nick,
> comment out the calls to sp_adddistributor and sp_adddistpublisher.
> Rgds,
> Paul Ibison
>
I set up a merge replication on my own local computer and works fine, so i
generated a script and tried to run this script in another computer ,which
already has a replication. (i change the server name before running script)
but still got two errors:
Server: Msg 14099, Level 16, State 1, Procedure sp_adddistributor, Line 72
The server 'repl_distributor' is already defined as a Distributor.
The dependent aliases were mapped to the new database owner.
Database owner changed.
Server: Msg 14074, Level 16, State 1, Procedure sp_adddistpublisher, Line
196
The server 'NICK' is already listed as a Publisher.
but the my replication still works even i got two errors when run script.
so how can i change my script to avoid those two errors when running script?
Cheers
Nick
Nick,
comment out the calls to sp_adddistributor and sp_adddistpublisher.
Rgds,
Paul Ibison
|||Thanks Paul.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:#iJ4CmXCFHA.560@.TK2MSFTNGP15.phx.gbl...
> Nick,
> comment out the calls to sp_adddistributor and sp_adddistpublisher.
> Rgds,
> Paul Ibison
>
Friday, March 23, 2012
replication question
What is the thought on replicating over WAN links.
I have a DB hosted at an off-site ISP it is about 1.2 GB in size. I would
like a local copy of the DB. So I would like to set up one-way replication.
The ISP says that replication is resource intensive. We have a 768K
Fractional T-1 they tell me that replication would suck up all that
bandwidth? There aren't a lot of updates that go on the DB in a day over
time there are a lot of updates but on a typical day there aren't a terrible
lot.
So I'm trying to gauge whether the ISP is right or if they aren't really
sure in what they are telling me. I would just
like to have a local copy of our DB on-site in-case the ISP's site goes down
for whatever reason.
Thanks,
Geo
Hi Marc
If you are applying normal transactional replication and don't have a lot of
transactions then your line would be more than adequate. The only bandwidth
intensive process would be when you initialize and apply a 1.2 GB snapshot
accross the line. Then SQL will use as much bandwidth as possible.
We've run transactional replication successfully on 256k lines without it
having a huge impact on the line. Again depending on the transaction volumes.
Regards
Cube
http://www.sqlserver.co.za
"marc" wrote:
> What is the thought on replicating over WAN links.
> I have a DB hosted at an off-site ISP it is about 1.2 GB in size. I would
> like a local copy of the DB. So I would like to set up one-way replication.
> The ISP says that replication is resource intensive. We have a 768K
> Fractional T-1 they tell me that replication would suck up all that
> bandwidth? There aren't a lot of updates that go on the DB in a day over
> time there are a lot of updates but on a typical day there aren't a terrible
> lot.
> So I'm trying to gauge whether the ISP is right or if they aren't really
> sure in what they are telling me. I would just
> like to have a local copy of our DB on-site in-case the ISP's site goes down
> for whatever reason.
> Thanks,
> Geo
>
>
I have a DB hosted at an off-site ISP it is about 1.2 GB in size. I would
like a local copy of the DB. So I would like to set up one-way replication.
The ISP says that replication is resource intensive. We have a 768K
Fractional T-1 they tell me that replication would suck up all that
bandwidth? There aren't a lot of updates that go on the DB in a day over
time there are a lot of updates but on a typical day there aren't a terrible
lot.
So I'm trying to gauge whether the ISP is right or if they aren't really
sure in what they are telling me. I would just
like to have a local copy of our DB on-site in-case the ISP's site goes down
for whatever reason.
Thanks,
Geo
Hi Marc
If you are applying normal transactional replication and don't have a lot of
transactions then your line would be more than adequate. The only bandwidth
intensive process would be when you initialize and apply a 1.2 GB snapshot
accross the line. Then SQL will use as much bandwidth as possible.
We've run transactional replication successfully on 256k lines without it
having a huge impact on the line. Again depending on the transaction volumes.
Regards
Cube
http://www.sqlserver.co.za
"marc" wrote:
> What is the thought on replicating over WAN links.
> I have a DB hosted at an off-site ISP it is about 1.2 GB in size. I would
> like a local copy of the DB. So I would like to set up one-way replication.
> The ISP says that replication is resource intensive. We have a 768K
> Fractional T-1 they tell me that replication would suck up all that
> bandwidth? There aren't a lot of updates that go on the DB in a day over
> time there are a lot of updates but on a typical day there aren't a terrible
> lot.
> So I'm trying to gauge whether the ISP is right or if they aren't really
> sure in what they are telling me. I would just
> like to have a local copy of our DB on-site in-case the ISP's site goes down
> for whatever reason.
> Thanks,
> Geo
>
>
replication question
My situation:
I have a DB hosted by a 3rd party ISP. I want to replicate that DB locally
with in my office on our local server, mainly for backup purposes. I then
want to replicate that backup DB to a development DB for testing purposes.
Basically I'll have a LIVE DB hosted at the ISP. A backup version of the
LIVE
DB on our local server (peace of mind really) Then a development DB for
testing
purposes.
The Publisher will be the DB at the ISP.
Question 1. Is this a doable or a reasonable solution. I figured
transaction replication
from LIVE to BACKUP. Then Snapshot from BACKUP to
DEVELOPMENT.
It isn't absolutely necessary to have the most recent
data on the development db
since I will only be using it for testing purposes. But
would be nice to draw from
real data, almost live situations.
Question 2. Can a DB or server be both a Publisher and a Subscriber in this
case the BACKUP DB
would be both?
Thanks,
George
George,
this is possible - it is known as republishing. In your case my preference
would be to use merge between the live system and the Backup system, as it
is ideal for this sort of high latency situation. This would allow you to
have the Backup system as the publisher (with merge, the
publisher/subscriber metaphor doesn't especially hold), as you can then
control the configuration settings locally, and I'd have the live system as
a push subscriber. The other system is used as a testing system and the data
could become incompatible with replication from the Backup system, so I
wouldn't use replication to transfer to this box. Instead, I'd use a backup
and restore of the whole database - Backup to Test.
HTH,
Paul Ibison
|||I'd use transactional as
1) it offers better performance
2) it doesn't add a GUID key to every table.
The con of transactional replication is that you need a PK on every table you wish to replicate, and with republishing transactional is more sensitive to schema changes. By more sensitive I mean you have to drop your publications and subscriptions, make c
hanges and re-build again.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
sql
I have a DB hosted by a 3rd party ISP. I want to replicate that DB locally
with in my office on our local server, mainly for backup purposes. I then
want to replicate that backup DB to a development DB for testing purposes.
Basically I'll have a LIVE DB hosted at the ISP. A backup version of the
LIVE
DB on our local server (peace of mind really) Then a development DB for
testing
purposes.
The Publisher will be the DB at the ISP.
Question 1. Is this a doable or a reasonable solution. I figured
transaction replication
from LIVE to BACKUP. Then Snapshot from BACKUP to
DEVELOPMENT.
It isn't absolutely necessary to have the most recent
data on the development db
since I will only be using it for testing purposes. But
would be nice to draw from
real data, almost live situations.
Question 2. Can a DB or server be both a Publisher and a Subscriber in this
case the BACKUP DB
would be both?
Thanks,
George
George,
this is possible - it is known as republishing. In your case my preference
would be to use merge between the live system and the Backup system, as it
is ideal for this sort of high latency situation. This would allow you to
have the Backup system as the publisher (with merge, the
publisher/subscriber metaphor doesn't especially hold), as you can then
control the configuration settings locally, and I'd have the live system as
a push subscriber. The other system is used as a testing system and the data
could become incompatible with replication from the Backup system, so I
wouldn't use replication to transfer to this box. Instead, I'd use a backup
and restore of the whole database - Backup to Test.
HTH,
Paul Ibison
|||I'd use transactional as
1) it offers better performance
2) it doesn't add a GUID key to every table.
The con of transactional replication is that you need a PK on every table you wish to replicate, and with republishing transactional is more sensitive to schema changes. By more sensitive I mean you have to drop your publications and subscriptions, make c
hanges and re-build again.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
sql
Tuesday, March 20, 2012
Replication Performance -- Many publishers, 1 subscriber
I have a situation where I need about 50 client machines that are
collecting data to synchronize with a network server on our local 100
Mbps LAN. Am running SQL Server Enterprise 2000 on the back end.
Have experimented with using MSDE on the client machines and using
merge replication with a push subscription to the server. Everything
seems to work good on a single client, but I'm wondering:
- How does this scale? Is it realistic to think I can do this with 50
machines?
- Locking implications. Since this is an automated process, The
ability to have real-time inserts needs to be always available
Typically happens 1 - 2 times per minute. (Updates can be handled
through standard error handling since a human operator is involved.)
- As time goes by and table sizes increase would this slow down, even
if the primary activity on the table is the addition of records?
Thanks in advance.
Mike
Mike,
I would say it is preferable to have a single publisher on the main server
and multiple push subscribers for this topology.
I'm not sure what your separation of inserts and updates is for - could you
explain a little further.
Inserts shouldn't cause any locking contention. For contention of resources,
you could stagger the synchronization, and limit the number of concurrent
merge processes.
Increasing table size for inserts should be no problem. You'll have a
gradual increase in metadata, which will be removed automatically though.
HTH,
Paul Ibison
|||do you need bi-directional replication? From what you describe you have
selected merge, where if you don't need bi-directional replication you can
get away with transactional which will offer better performance.
"Mike Von Stein" <mvonstein@.yahoo.com> wrote in message
news:c92d1754.0405070936.fcab9ad@.posting.google.co m...
> I have a situation where I need about 50 client machines that are
> collecting data to synchronize with a network server on our local 100
> Mbps LAN. Am running SQL Server Enterprise 2000 on the back end.
> Have experimented with using MSDE on the client machines and using
> merge replication with a push subscription to the server. Everything
> seems to work good on a single client, but I'm wondering:
> - How does this scale? Is it realistic to think I can do this with 50
> machines?
> - Locking implications. Since this is an automated process, The
> ability to have real-time inserts needs to be always available
> Typically happens 1 - 2 times per minute. (Updates can be handled
> through standard error handling since a human operator is involved.)
> - As time goes by and table sizes increase would this slow down, even
> if the primary activity on the table is the addition of records?
> Thanks in advance.
> Mike
|||Paul-
Thanks for the info. It was helpful. The reason I was pursuing this
topology is because the clients are the ones collecting the data.
Which need to be warehoused in a central place. (There is also
static setup data that is coming one way from the server, which I'm
doing exactly what you describe.)
The inserts and updates separation issue is because some of the data
comes automatically from the machine while another, different type of
data, data comes from the operator. It's stored in separate tables in
MSDE. The person's data can be corrected by the person to fix
mistakes. The machine data "never makes mistakes" (or at least it
doesn't know it does) so it's only an insert operation.
Thanks again,
Mike
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:<#vLI3YGNEHA.1616@.TK2MSFTNGP12.phx.gbl>...
> Mike,
> I would say it is preferable to have a single publisher on the main server
> and multiple push subscribers for this topology.
> I'm not sure what your separation of inserts and updates is for - could you
> explain a little further.
> Inserts shouldn't cause any locking contention. For contention of resources,
> you could stagger the synchronization, and limit the number of concurrent
> merge processes.
> Increasing table size for inserts should be no problem. You'll have a
> gradual increase in metadata, which will be removed automatically though.
> HTH,
> Paul Ibison
|||Hilary-
Thanks for the info. Not sure exactly what you mean by "selected
merge"? Like horizontal selection? You're right. Actually, I don't
need bi-directional replication in this case but, to my knowledge,
MSDE (which is running on the client) doesn't support transactional
and I thought snapshot would be inefficient.
Thanks again,
Mike
mvonstein@.yahoo.com (Mike Von Stein) wrote in message news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...
> I have a situation where I need about 50 client machines that are
> collecting data to synchronize with a network server on our local 100
> Mbps LAN. Am running SQL Server Enterprise 2000 on the back end.
> Have experimented with using MSDE on the client machines and using
> merge replication with a push subscription to the server. Everything
> seems to work good on a single client, but I'm wondering:
> - How does this scale? Is it realistic to think I can do this with 50
> machines?
> - Locking implications. Since this is an automated process, The
> ability to have real-time inserts needs to be always available
> Typically happens 1 - 2 times per minute. (Updates can be handled
> through standard error handling since a human operator is involved.)
> - As time goes by and table sizes increase would this slow down, even
> if the primary activity on the table is the addition of records?
> Thanks in advance.
> Mike
|||I meant "selected" in the sense of "chosen".
MSDE can be a subscriber to a transactional publication, or a publisher for
merge or snapshot publications. On further reflection I guess this is why
you have selected merge.
I have worked on a topology that used over 60 merge subscribers to a single
publisher, so it is highly scalable.
I have heard about people using merge with over 100 subscribers with no real
problems.
Achieving real time replication with merge is a problem. Set your
pollinginterval to something low - perhaps 10s or so.
"Mike Von Stein" <mvonstein@.yahoo.com> wrote in message
news:c92d1754.0405080525.16417da3@.posting.google.c om...
> Hilary-
> Thanks for the info. Not sure exactly what you mean by "selected
> merge"? Like horizontal selection? You're right. Actually, I don't
> need bi-directional replication in this case but, to my knowledge,
> MSDE (which is running on the client) doesn't support transactional
> and I thought snapshot would be inefficient.
> Thanks again,
> Mike
>
> mvonstein@.yahoo.com (Mike Von Stein) wrote in message
news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...[vbcol=seagreen]
|||Mike,
as you know either way works, but I'd still choose to use use a central
publisher and multiple subscribers, as the metadata and alerts etc are then
in a central place and maintenance is simpler. For merge, the distinction
between publisher and subscriber is not too relevant if you don't have
conflicts.
Cheers,
Paul
|||Paul-
Okay, I guess I was thinking since the clients would be the primary
information generators, they would be the "Publishers", but I guess
the names shouldn't be taken literally in this case. I think I see
the benefits you are suggesting.
One question though. How does this impact future schema changes?
Would you have to drop all subscriptions remotely at the clients and
recreate? (That's a maintenance concern, since there are so many.)
We're kind of in a "formative" phase here and I'm expecting to have to
do some tweaks...
Thanks,
Mike
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:<#of5O$cNEHA.3328@.TK2MSFTNGP10.phx.gbl>...
> Mike,
> as you know either way works, but I'd still choose to use use a central
> publisher and multiple subscribers, as the metadata and alerts etc are then
> in a central place and maintenance is simpler. For merge, the distinction
> between publisher and subscriber is not too relevant if you don't have
> conflicts.
> Cheers,
> Paul
|||Hilary-
The performance info is interesting. Yes, that is why I was talking
about Merge, but maybe I should look at reversing the terminology like
Paul in this thread suggested. Then maybe I could use transactional
with MSDE?
One concern, though, is the whole reason we are doing this is to
buffer the system to handle things such as planned/unplanned,
server/network downtime, etc. (The clients have to be available 24/7,
but not necessarily the server, if that makes sense...) Read in BOL,
that transactional was for a constant connection. In general, this
would be more like a 99.9% constant connection... So not sure what to
think about that...
Thanks,
Mike
"Hilary Cotter" <hilaryk@.att.net> wrote in message news:<O1Ly#gXNEHA.2500@.TK2MSFTNGP12.phx.gbl>...[vbcol=seagreen]
> I meant "selected" in the sense of "chosen".
> MSDE can be a subscriber to a transactional publication, or a publisher for
> merge or snapshot publications. On further reflection I guess this is why
> you have selected merge.
> I have worked on a topology that used over 60 merge subscribers to a single
> publisher, so it is highly scalable.
> I have heard about people using merge with over 100 subscribers with no real
> problems.
> Achieving real time replication with merge is a problem. Set your
> pollinginterval to something low - perhaps 10s or so.
> "Mike Von Stein" <mvonstein@.yahoo.com> wrote in message
> news:c92d1754.0405080525.16417da3@.posting.google.c om...
> news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...
|||Transaction does not support bi-directional replication through the wizards. You can configure it for bi-directional replication using the replication stored procedures, or you could use queued replication (but it is tuned for less than 10 subscribers whi
ch rules it out in this case) or immediately updating susbcribers (only if your subscribers/publisher are always well connected).
Transactional does support the subscribers going offline, however you are updating the subscribers, so your best option in this case is merge.
Merge also supports having the publisher and susbcribers going offline.
The caveat in this is the more frequently your publisher/subscribers goes off line the greater the chance of having conflicts.
-- Mike Von Stein wrote: --
Hilary-
The performance info is interesting. Yes, that is why I was talking
about Merge, but maybe I should look at reversing the terminology like
Paul in this thread suggested. Then maybe I could use transactional
with MSDE?
One concern, though, is the whole reason we are doing this is to
buffer the system to handle things such as planned/unplanned,
server/network downtime, etc. (The clients have to be available 24/7,
but not necessarily the server, if that makes sense...) Read in BOL,
that transactional was for a constant connection. In general, this
would be more like a 99.9% constant connection... So not sure what to
think about that...
Thanks,
Mike
"Hilary Cotter" <hilaryk@.att.net> wrote in message news:<O1Ly#gXNEHA.2500@.TK2MSFTNGP12.phx.gbl>...[vbcol=seagreen]
> I meant "selected" in the sense of "chosen".
> merge or snapshot publications. On further reflection I guess this is why
> you have selected merge.
> publisher, so it is highly scalable.
> problems.
> pollinginterval to something low - perhaps 10s or so.
> news:c92d1754.0405080525.16417da3@.posting.google.c om...
> news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...
collecting data to synchronize with a network server on our local 100
Mbps LAN. Am running SQL Server Enterprise 2000 on the back end.
Have experimented with using MSDE on the client machines and using
merge replication with a push subscription to the server. Everything
seems to work good on a single client, but I'm wondering:
- How does this scale? Is it realistic to think I can do this with 50
machines?
- Locking implications. Since this is an automated process, The
ability to have real-time inserts needs to be always available
Typically happens 1 - 2 times per minute. (Updates can be handled
through standard error handling since a human operator is involved.)
- As time goes by and table sizes increase would this slow down, even
if the primary activity on the table is the addition of records?
Thanks in advance.
Mike
Mike,
I would say it is preferable to have a single publisher on the main server
and multiple push subscribers for this topology.
I'm not sure what your separation of inserts and updates is for - could you
explain a little further.
Inserts shouldn't cause any locking contention. For contention of resources,
you could stagger the synchronization, and limit the number of concurrent
merge processes.
Increasing table size for inserts should be no problem. You'll have a
gradual increase in metadata, which will be removed automatically though.
HTH,
Paul Ibison
|||do you need bi-directional replication? From what you describe you have
selected merge, where if you don't need bi-directional replication you can
get away with transactional which will offer better performance.
"Mike Von Stein" <mvonstein@.yahoo.com> wrote in message
news:c92d1754.0405070936.fcab9ad@.posting.google.co m...
> I have a situation where I need about 50 client machines that are
> collecting data to synchronize with a network server on our local 100
> Mbps LAN. Am running SQL Server Enterprise 2000 on the back end.
> Have experimented with using MSDE on the client machines and using
> merge replication with a push subscription to the server. Everything
> seems to work good on a single client, but I'm wondering:
> - How does this scale? Is it realistic to think I can do this with 50
> machines?
> - Locking implications. Since this is an automated process, The
> ability to have real-time inserts needs to be always available
> Typically happens 1 - 2 times per minute. (Updates can be handled
> through standard error handling since a human operator is involved.)
> - As time goes by and table sizes increase would this slow down, even
> if the primary activity on the table is the addition of records?
> Thanks in advance.
> Mike
|||Paul-
Thanks for the info. It was helpful. The reason I was pursuing this
topology is because the clients are the ones collecting the data.
Which need to be warehoused in a central place. (There is also
static setup data that is coming one way from the server, which I'm
doing exactly what you describe.)
The inserts and updates separation issue is because some of the data
comes automatically from the machine while another, different type of
data, data comes from the operator. It's stored in separate tables in
MSDE. The person's data can be corrected by the person to fix
mistakes. The machine data "never makes mistakes" (or at least it
doesn't know it does) so it's only an insert operation.
Thanks again,
Mike
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:<#vLI3YGNEHA.1616@.TK2MSFTNGP12.phx.gbl>...
> Mike,
> I would say it is preferable to have a single publisher on the main server
> and multiple push subscribers for this topology.
> I'm not sure what your separation of inserts and updates is for - could you
> explain a little further.
> Inserts shouldn't cause any locking contention. For contention of resources,
> you could stagger the synchronization, and limit the number of concurrent
> merge processes.
> Increasing table size for inserts should be no problem. You'll have a
> gradual increase in metadata, which will be removed automatically though.
> HTH,
> Paul Ibison
|||Hilary-
Thanks for the info. Not sure exactly what you mean by "selected
merge"? Like horizontal selection? You're right. Actually, I don't
need bi-directional replication in this case but, to my knowledge,
MSDE (which is running on the client) doesn't support transactional
and I thought snapshot would be inefficient.
Thanks again,
Mike
mvonstein@.yahoo.com (Mike Von Stein) wrote in message news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...
> I have a situation where I need about 50 client machines that are
> collecting data to synchronize with a network server on our local 100
> Mbps LAN. Am running SQL Server Enterprise 2000 on the back end.
> Have experimented with using MSDE on the client machines and using
> merge replication with a push subscription to the server. Everything
> seems to work good on a single client, but I'm wondering:
> - How does this scale? Is it realistic to think I can do this with 50
> machines?
> - Locking implications. Since this is an automated process, The
> ability to have real-time inserts needs to be always available
> Typically happens 1 - 2 times per minute. (Updates can be handled
> through standard error handling since a human operator is involved.)
> - As time goes by and table sizes increase would this slow down, even
> if the primary activity on the table is the addition of records?
> Thanks in advance.
> Mike
|||I meant "selected" in the sense of "chosen".
MSDE can be a subscriber to a transactional publication, or a publisher for
merge or snapshot publications. On further reflection I guess this is why
you have selected merge.
I have worked on a topology that used over 60 merge subscribers to a single
publisher, so it is highly scalable.
I have heard about people using merge with over 100 subscribers with no real
problems.
Achieving real time replication with merge is a problem. Set your
pollinginterval to something low - perhaps 10s or so.
"Mike Von Stein" <mvonstein@.yahoo.com> wrote in message
news:c92d1754.0405080525.16417da3@.posting.google.c om...
> Hilary-
> Thanks for the info. Not sure exactly what you mean by "selected
> merge"? Like horizontal selection? You're right. Actually, I don't
> need bi-directional replication in this case but, to my knowledge,
> MSDE (which is running on the client) doesn't support transactional
> and I thought snapshot would be inefficient.
> Thanks again,
> Mike
>
> mvonstein@.yahoo.com (Mike Von Stein) wrote in message
news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...[vbcol=seagreen]
|||Mike,
as you know either way works, but I'd still choose to use use a central
publisher and multiple subscribers, as the metadata and alerts etc are then
in a central place and maintenance is simpler. For merge, the distinction
between publisher and subscriber is not too relevant if you don't have
conflicts.
Cheers,
Paul
|||Paul-
Okay, I guess I was thinking since the clients would be the primary
information generators, they would be the "Publishers", but I guess
the names shouldn't be taken literally in this case. I think I see
the benefits you are suggesting.
One question though. How does this impact future schema changes?
Would you have to drop all subscriptions remotely at the clients and
recreate? (That's a maintenance concern, since there are so many.)
We're kind of in a "formative" phase here and I'm expecting to have to
do some tweaks...
Thanks,
Mike
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:<#of5O$cNEHA.3328@.TK2MSFTNGP10.phx.gbl>...
> Mike,
> as you know either way works, but I'd still choose to use use a central
> publisher and multiple subscribers, as the metadata and alerts etc are then
> in a central place and maintenance is simpler. For merge, the distinction
> between publisher and subscriber is not too relevant if you don't have
> conflicts.
> Cheers,
> Paul
|||Hilary-
The performance info is interesting. Yes, that is why I was talking
about Merge, but maybe I should look at reversing the terminology like
Paul in this thread suggested. Then maybe I could use transactional
with MSDE?
One concern, though, is the whole reason we are doing this is to
buffer the system to handle things such as planned/unplanned,
server/network downtime, etc. (The clients have to be available 24/7,
but not necessarily the server, if that makes sense...) Read in BOL,
that transactional was for a constant connection. In general, this
would be more like a 99.9% constant connection... So not sure what to
think about that...
Thanks,
Mike
"Hilary Cotter" <hilaryk@.att.net> wrote in message news:<O1Ly#gXNEHA.2500@.TK2MSFTNGP12.phx.gbl>...[vbcol=seagreen]
> I meant "selected" in the sense of "chosen".
> MSDE can be a subscriber to a transactional publication, or a publisher for
> merge or snapshot publications. On further reflection I guess this is why
> you have selected merge.
> I have worked on a topology that used over 60 merge subscribers to a single
> publisher, so it is highly scalable.
> I have heard about people using merge with over 100 subscribers with no real
> problems.
> Achieving real time replication with merge is a problem. Set your
> pollinginterval to something low - perhaps 10s or so.
> "Mike Von Stein" <mvonstein@.yahoo.com> wrote in message
> news:c92d1754.0405080525.16417da3@.posting.google.c om...
> news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...
|||Transaction does not support bi-directional replication through the wizards. You can configure it for bi-directional replication using the replication stored procedures, or you could use queued replication (but it is tuned for less than 10 subscribers whi
ch rules it out in this case) or immediately updating susbcribers (only if your subscribers/publisher are always well connected).
Transactional does support the subscribers going offline, however you are updating the subscribers, so your best option in this case is merge.
Merge also supports having the publisher and susbcribers going offline.
The caveat in this is the more frequently your publisher/subscribers goes off line the greater the chance of having conflicts.
-- Mike Von Stein wrote: --
Hilary-
The performance info is interesting. Yes, that is why I was talking
about Merge, but maybe I should look at reversing the terminology like
Paul in this thread suggested. Then maybe I could use transactional
with MSDE?
One concern, though, is the whole reason we are doing this is to
buffer the system to handle things such as planned/unplanned,
server/network downtime, etc. (The clients have to be available 24/7,
but not necessarily the server, if that makes sense...) Read in BOL,
that transactional was for a constant connection. In general, this
would be more like a 99.9% constant connection... So not sure what to
think about that...
Thanks,
Mike
"Hilary Cotter" <hilaryk@.att.net> wrote in message news:<O1Ly#gXNEHA.2500@.TK2MSFTNGP12.phx.gbl>...[vbcol=seagreen]
> I meant "selected" in the sense of "chosen".
> merge or snapshot publications. On further reflection I guess this is why
> you have selected merge.
> publisher, so it is highly scalable.
> problems.
> pollinginterval to something low - perhaps 10s or so.
> news:c92d1754.0405080525.16417da3@.posting.google.c om...
> news:<c92d1754.0405070936.fcab9ad@.posting.google.c om>...
Labels:
100mbps,
arecollecting,
client,
database,
lan,
local,
machines,
microsoft,
mysql,
network,
oracle,
performance,
publishers,
replication,
server,
situation,
sql,
subscriber,
synchronize
Wednesday, March 7, 2012
Replication newbie, help please...
Dear all,
I have a web application that uses sql2005 database. And a local windows
application that uses exactly same sql2005 database structure. I want to
synchronize databases. When new record added from web I want them into my
local db. When my local db changes I want them to go my server database.
Is this "replication" concept for this kind operation. there are many
resources on the net but I could not figure out how.
Any sample documentation, link on tghe web, sample project, anything is
wellcome. but I need to synchronize 2 databases in different locations.
Best regards.
Have a look in BOL for setting up merge replication. The exact setup depends
on how the web application and the local windows application can connect -
over tcp/ip (trusted?) or if not https?
Rgds,
Paul Ibison
I have a web application that uses sql2005 database. And a local windows
application that uses exactly same sql2005 database structure. I want to
synchronize databases. When new record added from web I want them into my
local db. When my local db changes I want them to go my server database.
Is this "replication" concept for this kind operation. there are many
resources on the net but I could not figure out how.
Any sample documentation, link on tghe web, sample project, anything is
wellcome. but I need to synchronize 2 databases in different locations.
Best regards.
Have a look in BOL for setting up merge replication. The exact setup depends
on how the web application and the local windows application can connect -
over tcp/ip (trusted?) or if not https?
Rgds,
Paul Ibison
Labels:
application,
database,
dear,
local,
microsoft,
mysql,
newbie,
oracle,
replication,
server,
sql,
sql2005,
structure,
web,
windowsapplication
Tuesday, February 21, 2012
Replication in Local System-HOW?
Hi,
I'm new to Replication and before i start doing it in the LIVE environment,i
need to learn it first and test the same on my Local machine.I'm aware
that,if the Registration is done as "LOCAL",the Repliaction will not
work.But,unfortunately,the registration on my machine is Local.Can some one
suggest as how should i start playing with Replication and have some hands-on
with it. Kindly help me.
Thanks,
shyam
Hi Shyam
I think you're referring to the message that Enterprise Manager pops up when
you try to use the Replication dialogs, right?
If so, all you need to do is unregister the instances in Enterprise Manager
& re-register it using the computer name, rather than "local" or " . ".. It
should work from there.
I use Replication regularly on default instances, whilst logged onto the
local machine this way...
Regards,
Greg Linwood
SQL Server MVP
"Shyam" <Shyam@.discussions.microsoft.com> wrote in message
news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> Hi,
> I'm new to Replication and before i start doing it in the LIVE
> environment,i
> need to learn it first and test the same on my Local machine.I'm aware
> that,if the Registration is done as "LOCAL",the Repliaction will not
> work.But,unfortunately,the registration on my machine is Local.Can some
> one
> suggest as how should i start playing with Replication and have some
> hands-on
> with it. Kindly help me.
> Thanks,
> shyam
|||Hi Greg,
Thanks for the tip.Missed that idea,will give a try on this and get back if
i have any clarifications..
Regards,
Shyam
"Greg Linwood" wrote:
> Hi Shyam
> I think you're referring to the message that Enterprise Manager pops up when
> you try to use the Replication dialogs, right?
> If so, all you need to do is unregister the instances in Enterprise Manager
> & re-register it using the computer name, rather than "local" or " . ".. It
> should work from there.
> I use Replication regularly on default instances, whilst logged onto the
> local machine this way...
> Regards,
> Greg Linwood
> SQL Server MVP
> "Shyam" <Shyam@.discussions.microsoft.com> wrote in message
> news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
>
>
I'm new to Replication and before i start doing it in the LIVE environment,i
need to learn it first and test the same on my Local machine.I'm aware
that,if the Registration is done as "LOCAL",the Repliaction will not
work.But,unfortunately,the registration on my machine is Local.Can some one
suggest as how should i start playing with Replication and have some hands-on
with it. Kindly help me.
Thanks,
shyam
Hi Shyam
I think you're referring to the message that Enterprise Manager pops up when
you try to use the Replication dialogs, right?
If so, all you need to do is unregister the instances in Enterprise Manager
& re-register it using the computer name, rather than "local" or " . ".. It
should work from there.
I use Replication regularly on default instances, whilst logged onto the
local machine this way...
Regards,
Greg Linwood
SQL Server MVP
"Shyam" <Shyam@.discussions.microsoft.com> wrote in message
news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> Hi,
> I'm new to Replication and before i start doing it in the LIVE
> environment,i
> need to learn it first and test the same on my Local machine.I'm aware
> that,if the Registration is done as "LOCAL",the Repliaction will not
> work.But,unfortunately,the registration on my machine is Local.Can some
> one
> suggest as how should i start playing with Replication and have some
> hands-on
> with it. Kindly help me.
> Thanks,
> shyam
|||Hi Greg,
Thanks for the tip.Missed that idea,will give a try on this and get back if
i have any clarifications..
Regards,
Shyam
"Greg Linwood" wrote:
> Hi Shyam
> I think you're referring to the message that Enterprise Manager pops up when
> you try to use the Replication dialogs, right?
> If so, all you need to do is unregister the instances in Enterprise Manager
> & re-register it using the computer name, rather than "local" or " . ".. It
> should work from there.
> I use Replication regularly on default instances, whilst logged onto the
> local machine this way...
> Regards,
> Greg Linwood
> SQL Server MVP
> "Shyam" <Shyam@.discussions.microsoft.com> wrote in message
> news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
>
>
Labels:
database,
environment,
ineed,
learn,
live,
local,
microsoft,
mysql,
oracle,
replication,
server,
sql,
system-how
Replication in Local System-HOW?
Hi,
I'm new to Replication and before i start doing it in the LIVE environment,i
need to learn it first and test the same on my Local machine.I'm aware
that,if the Registration is done as "LOCAL",the Repliaction will not
work.But,unfortunately,the registration on my machine is Local.Can some one
suggest as how should i start playing with Replication and have some hands-o
n
with it. Kindly help me.
Thanks,
shyamHi Shyam
I think you're referring to the message that Enterprise Manager pops up when
you try to use the Replication dialogs, right?
If so, all you need to do is unregister the instances in Enterprise Manager
& re-register it using the computer name, rather than "local" or " . ".. It
should work from there.
I use Replication regularly on default instances, whilst logged onto the
local machine this way...
Regards,
Greg Linwood
SQL Server MVP
"Shyam" <Shyam@.discussions.microsoft.com> wrote in message
news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> Hi,
> I'm new to Replication and before i start doing it in the LIVE
> environment,i
> need to learn it first and test the same on my Local machine.I'm aware
> that,if the Registration is done as "LOCAL",the Repliaction will not
> work.But,unfortunately,the registration on my machine is Local.Can some
> one
> suggest as how should i start playing with Replication and have some
> hands-on
> with it. Kindly help me.
> Thanks,
> shyam|||Hi Greg,
Thanks for the tip.Missed that idea,will give a try on this and get back if
i have any clarifications..
Regards,
Shyam
"Greg Linwood" wrote:
> Hi Shyam
> I think you're referring to the message that Enterprise Manager pops up wh
en
> you try to use the Replication dialogs, right?
> If so, all you need to do is unregister the instances in Enterprise Manage
r
> & re-register it using the computer name, rather than "local" or " . ".. I
t
> should work from there.
> I use Replication regularly on default instances, whilst logged onto the
> local machine this way...
> Regards,
> Greg Linwood
> SQL Server MVP
> "Shyam" <Shyam@.discussions.microsoft.com> wrote in message
> news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
>
>
I'm new to Replication and before i start doing it in the LIVE environment,i
need to learn it first and test the same on my Local machine.I'm aware
that,if the Registration is done as "LOCAL",the Repliaction will not
work.But,unfortunately,the registration on my machine is Local.Can some one
suggest as how should i start playing with Replication and have some hands-o
n
with it. Kindly help me.
Thanks,
shyamHi Shyam
I think you're referring to the message that Enterprise Manager pops up when
you try to use the Replication dialogs, right?
If so, all you need to do is unregister the instances in Enterprise Manager
& re-register it using the computer name, rather than "local" or " . ".. It
should work from there.
I use Replication regularly on default instances, whilst logged onto the
local machine this way...
Regards,
Greg Linwood
SQL Server MVP
"Shyam" <Shyam@.discussions.microsoft.com> wrote in message
news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> Hi,
> I'm new to Replication and before i start doing it in the LIVE
> environment,i
> need to learn it first and test the same on my Local machine.I'm aware
> that,if the Registration is done as "LOCAL",the Repliaction will not
> work.But,unfortunately,the registration on my machine is Local.Can some
> one
> suggest as how should i start playing with Replication and have some
> hands-on
> with it. Kindly help me.
> Thanks,
> shyam|||Hi Greg,
Thanks for the tip.Missed that idea,will give a try on this and get back if
i have any clarifications..
Regards,
Shyam
"Greg Linwood" wrote:
> Hi Shyam
> I think you're referring to the message that Enterprise Manager pops up wh
en
> you try to use the Replication dialogs, right?
> If so, all you need to do is unregister the instances in Enterprise Manage
r
> & re-register it using the computer name, rather than "local" or " . ".. I
t
> should work from there.
> I use Replication regularly on default instances, whilst logged onto the
> local machine this way...
> Regards,
> Greg Linwood
> SQL Server MVP
> "Shyam" <Shyam@.discussions.microsoft.com> wrote in message
> news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
>
>
Labels:
database,
environment,
ineed,
learn,
live,
local,
microsoft,
mysql,
oracle,
replication,
server,
sql,
system-how
Replication in Local System-HOW?
Hi,
I'm new to Replication and before i start doing it in the LIVE environment,i
need to learn it first and test the same on my Local machine.I'm aware
that,if the Registration is done as "LOCAL",the Repliaction will not
work.But,unfortunately,the registration on my machine is Local.Can some one
suggest as how should i start playing with Replication and have some hands-on
with it. Kindly help me.
Thanks,
shyamHi Shyam
I think you're referring to the message that Enterprise Manager pops up when
you try to use the Replication dialogs, right?
If so, all you need to do is unregister the instances in Enterprise Manager
& re-register it using the computer name, rather than "local" or " . ".. It
should work from there.
I use Replication regularly on default instances, whilst logged onto the
local machine this way...
Regards,
Greg Linwood
SQL Server MVP
"Shyam" <Shyam@.discussions.microsoft.com> wrote in message
news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> Hi,
> I'm new to Replication and before i start doing it in the LIVE
> environment,i
> need to learn it first and test the same on my Local machine.I'm aware
> that,if the Registration is done as "LOCAL",the Repliaction will not
> work.But,unfortunately,the registration on my machine is Local.Can some
> one
> suggest as how should i start playing with Replication and have some
> hands-on
> with it. Kindly help me.
> Thanks,
> shyam|||Hi Greg,
Thanks for the tip.Missed that idea,will give a try on this and get back if
i have any clarifications.. :)
Regards,
Shyam
"Greg Linwood" wrote:
> Hi Shyam
> I think you're referring to the message that Enterprise Manager pops up when
> you try to use the Replication dialogs, right?
> If so, all you need to do is unregister the instances in Enterprise Manager
> & re-register it using the computer name, rather than "local" or " . ".. It
> should work from there.
> I use Replication regularly on default instances, whilst logged onto the
> local machine this way...
> Regards,
> Greg Linwood
> SQL Server MVP
> "Shyam" <Shyam@.discussions.microsoft.com> wrote in message
> news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> > Hi,
> >
> > I'm new to Replication and before i start doing it in the LIVE
> > environment,i
> > need to learn it first and test the same on my Local machine.I'm aware
> > that,if the Registration is done as "LOCAL",the Repliaction will not
> > work.But,unfortunately,the registration on my machine is Local.Can some
> > one
> > suggest as how should i start playing with Replication and have some
> > hands-on
> > with it. Kindly help me.
> >
> > Thanks,
> > shyam
>
>
I'm new to Replication and before i start doing it in the LIVE environment,i
need to learn it first and test the same on my Local machine.I'm aware
that,if the Registration is done as "LOCAL",the Repliaction will not
work.But,unfortunately,the registration on my machine is Local.Can some one
suggest as how should i start playing with Replication and have some hands-on
with it. Kindly help me.
Thanks,
shyamHi Shyam
I think you're referring to the message that Enterprise Manager pops up when
you try to use the Replication dialogs, right?
If so, all you need to do is unregister the instances in Enterprise Manager
& re-register it using the computer name, rather than "local" or " . ".. It
should work from there.
I use Replication regularly on default instances, whilst logged onto the
local machine this way...
Regards,
Greg Linwood
SQL Server MVP
"Shyam" <Shyam@.discussions.microsoft.com> wrote in message
news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> Hi,
> I'm new to Replication and before i start doing it in the LIVE
> environment,i
> need to learn it first and test the same on my Local machine.I'm aware
> that,if the Registration is done as "LOCAL",the Repliaction will not
> work.But,unfortunately,the registration on my machine is Local.Can some
> one
> suggest as how should i start playing with Replication and have some
> hands-on
> with it. Kindly help me.
> Thanks,
> shyam|||Hi Greg,
Thanks for the tip.Missed that idea,will give a try on this and get back if
i have any clarifications.. :)
Regards,
Shyam
"Greg Linwood" wrote:
> Hi Shyam
> I think you're referring to the message that Enterprise Manager pops up when
> you try to use the Replication dialogs, right?
> If so, all you need to do is unregister the instances in Enterprise Manager
> & re-register it using the computer name, rather than "local" or " . ".. It
> should work from there.
> I use Replication regularly on default instances, whilst logged onto the
> local machine this way...
> Regards,
> Greg Linwood
> SQL Server MVP
> "Shyam" <Shyam@.discussions.microsoft.com> wrote in message
> news:1FADD217-846F-4332-BC5D-4E020BC0DDB2@.microsoft.com...
> > Hi,
> >
> > I'm new to Replication and before i start doing it in the LIVE
> > environment,i
> > need to learn it first and test the same on my Local machine.I'm aware
> > that,if the Registration is done as "LOCAL",the Repliaction will not
> > work.But,unfortunately,the registration on my machine is Local.Can some
> > one
> > suggest as how should i start playing with Replication and have some
> > hands-on
> > with it. Kindly help me.
> >
> > Thanks,
> > shyam
>
>
Labels:
database,
environment,
learn,
live,
local,
microsoft,
mysql,
oracle,
replication,
server,
sql,
system-how
Subscribe to:
Posts (Atom)