1)Have Transactional replication and wanted to know what was the maximum
transaction retention property for distribution database is
2Also i was looking at the properties and it says that the subscription
could expire or get dropped if not synchronised within 72 hours. So my
question here is under what condition would it expire and when would it get
dropped
Thanks
Please see my reply to your other post.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Showing posts with label distribution. Show all posts
Showing posts with label distribution. Show all posts
Monday, March 19, 2012
Wednesday, March 7, 2012
Maximum Articles for Transaction Replication SQL 2000 and SQl 2005
Hello,
We are planing to implement transaction replication for 800 DB on SQL 2000
custer (as a publisher) and have seperate servers for Distribution and
Subscriber.
What is the maximum nnumber of articles I can have per DB.
What are the capacity limitations for this type of setup other than hardware
What other areas i need to make sure are in place before this is implemented.
Appreciate any comments
Please advise...
Thanks
Is that 800 databases or 1 db with 800 articles?
800 articles is no problem, I am replicating 850 with no problems, however
all in 1 db.
The problem you will have is on the distributor, you will define 800
publications, and 800 subscriptions - if only replicating to 1 server.
On distributor you will see a seperate exe for each replication agent. And
with trans you will have 1 Log Reader, 1 Snapshot, and 1 Distribution Agent
for each pub. Each exe will try to capture anywhere from 2 to 5Mb of RAM. You
do the math.
Best to test solution before implementation. And only replicate what you
absolutely need...
Good luck - post results if you implement in prod.
ChrisB MCDBA
MSSQLConsulting.com
"KetanB" wrote:
> Hello,
> We are planing to implement transaction replication for 800 DB on SQL 2000
> custer (as a publisher) and have seperate servers for Distribution and
> Subscriber.
> What is the maximum nnumber of articles I can have per DB.
> What are the capacity limitations for this type of setup other than hardware
> What other areas i need to make sure are in place before this is implemented.
> Appreciate any comments
> Please advise...
> Thanks
We are planing to implement transaction replication for 800 DB on SQL 2000
custer (as a publisher) and have seperate servers for Distribution and
Subscriber.
What is the maximum nnumber of articles I can have per DB.
What are the capacity limitations for this type of setup other than hardware
What other areas i need to make sure are in place before this is implemented.
Appreciate any comments
Please advise...
Thanks
Is that 800 databases or 1 db with 800 articles?
800 articles is no problem, I am replicating 850 with no problems, however
all in 1 db.
The problem you will have is on the distributor, you will define 800
publications, and 800 subscriptions - if only replicating to 1 server.
On distributor you will see a seperate exe for each replication agent. And
with trans you will have 1 Log Reader, 1 Snapshot, and 1 Distribution Agent
for each pub. Each exe will try to capture anywhere from 2 to 5Mb of RAM. You
do the math.
Best to test solution before implementation. And only replicate what you
absolutely need...
Good luck - post results if you implement in prod.
ChrisB MCDBA
MSSQLConsulting.com
"KetanB" wrote:
> Hello,
> We are planing to implement transaction replication for 800 DB on SQL 2000
> custer (as a publisher) and have seperate servers for Distribution and
> Subscriber.
> What is the maximum nnumber of articles I can have per DB.
> What are the capacity limitations for this type of setup other than hardware
> What other areas i need to make sure are in place before this is implemented.
> Appreciate any comments
> Please advise...
> Thanks
Labels:
2000custer,
articles,
database,
distribution,
implement,
maximum,
microsoft,
mysql,
oracle,
planing,
publisher,
replication,
seperate,
server,
servers,
sql,
transaction
Subscribe to:
Posts (Atom)