Replication Error after Upgrade (7.0-2000)

Scenario: 3 servers - one Subscriber, one Distributor, one Publisher. Transactional replication; immediate updating subscribers disallowed. Each article in its own publication... independent agents.
Subscriber & Publisher = SQL 7.0
Distributor recently upgraded to 2000, SP3a.
Issue: new publications created at publisher fail to initialize snapshot agent properly. Error: "Another snapshot agent for the publication is running". Agent then fails after total retries (default is 10... does not matter what I set it to).
All existing publications work fine; all existing subscriptions work fine.
So what's the deal?
It appears that once you upgrade the Distributor(s), you have to upgrade the Publisher(s) immediately thereafter if you wish to create new publications. I have not seen that documented however... anyone know?
Thanks!
X
This is documented somewhat. Check out
http://msdn.microsoft.com/library/de...grade_45ir.asp
It doesn't say do this immediately though.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Xfonhe" <Xfonhe@.discussions.microsoft.com> wrote in message
news:D8EF5EEF-A0D7-4F69-B519-FD970A02F509@.microsoft.com...
> Scenario: 3 servers - one Subscriber, one Distributor, one Publisher.
Transactional replication; immediate updating subscribers disallowed. Each
article in its own publication... independent agents.
> Subscriber & Publisher = SQL 7.0
> Distributor recently upgraded to 2000, SP3a.
> Issue: new publications created at publisher fail to initialize snapshot
agent properly. Error: "Another snapshot agent for the publication is
running". Agent then fails after total retries (default is 10... does not
matter what I set it to).
> All existing publications work fine; all existing subscriptions work fine.
> So what's the deal?
> It appears that once you upgrade the Distributor(s), you have to upgrade
the Publisher(s) immediately thereafter if you wish to create new
publications. I have not seen that documented however... anyone know?
> Thanks!
> X
|||Thanks for the response Hilary.
I read that article; it doesn't specify that publishers MUST be upgraded to 2000 once the Distributor has been upgraded. That's the issue here: we have an upgraded Distributor, but we cannot upgrade the Publisher for some time. In the meantime, we need to
create new publications. We are unable to do so however, due to the error I outlined. It APPEARS that once you upgrade your Distributor, you have to upgrade your Publisher before you can create new publications. That doesn't seem right, but I have yet to
find evidence of its validity.
FWIW: one of the DBAs here reported the same error after applying SPs/hotfixes on the Distributor w/o applying same to Publisher.
"Hilary Cotter" wrote:

> This is documented somewhat. Check out
> http://msdn.microsoft.com/library/de...grade_45ir.asp
> It doesn't say do this immediately though.
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Xfonhe" <Xfonhe@.discussions.microsoft.com> wrote in message
> news:D8EF5EEF-A0D7-4F69-B519-FD970A02F509@.microsoft.com...
> Transactional replication; immediate updating subscribers disallowed. Each
> article in its own publication... independent agents.
> agent properly. Error: "Another snapshot agent for the publication is
> running". Agent then fails after total retries (default is 10... does not
> matter what I set it to).
> the Publisher(s) immediately thereafter if you wish to create new
> publications. I have not seen that documented however... anyone know?
>
>
|||FYI: the following URL shows the configuration I outlined as a 'valid replication topology' http://msdn.microsoft.com/library/de...limpl_4joy.asp
However, it doe not indicate that new publications created on the 7.0 Publisher w/ 2k Distributor and 7.0 Subscriber(s) will fail. On the contrary - it leads one to believe that the new publications will be in 70 compatability mode, as the replication top
ology defaults to the lowest level in a mixed environment.
Odd then, that I get this error. (btw, we have recycled the servers)
"Hilary Cotter" wrote:

> This is documented somewhat. Check out
> http://msdn.microsoft.com/library/de...grade_45ir.asp
> It doesn't say do this immediately though.
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Xfonhe" <Xfonhe@.discussions.microsoft.com> wrote in message
> news:D8EF5EEF-A0D7-4F69-B519-FD970A02F509@.microsoft.com...
> Transactional replication; immediate updating subscribers disallowed. Each
> article in its own publication... independent agents.
> agent properly. Error: "Another snapshot agent for the publication is
> running". Agent then fails after total retries (default is 10... does not
> matter what I set it to).
> the Publisher(s) immediately thereafter if you wish to create new
> publications. I have not seen that documented however... anyone know?
>
>
|||Let me try to repro this tonight.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Xfonhe" <Xfonhe@.discussions.microsoft.com> wrote in message
news:9034767C-3D75-4C7B-B975-510CC8AFDFDD@.microsoft.com...
> Thanks for the response Hilary.
> I read that article; it doesn't specify that publishers MUST be upgraded
to 2000 once the Distributor has been upgraded. That's the issue here: we
have an upgraded Distributor, but we cannot upgrade the Publisher for some
time. In the meantime, we need to create new publications. We are unable to
do so however, due to the error I outlined. It APPEARS that once you upgrade
your Distributor, you have to upgrade your Publisher before you can create
new publications. That doesn't seem right, but I have yet to find evidence
of its validity.
> FWIW: one of the DBAs here reported the same error after applying
SPs/hotfixes on the Distributor w/o applying same to Publisher.[vbcol=seagreen]
> "Hilary Cotter" wrote:
http://msdn.microsoft.com/library/de...grade_45ir.asp[vbcol=seagreen]
Each[vbcol=seagreen]
snapshot[vbcol=seagreen]
not[vbcol=seagreen]
fine.[vbcol=seagreen]
upgrade[vbcol=seagreen]
|||Were you able to reproduce the error?
Many thanks!!
X
"Hilary Cotter" wrote:

> Let me try to repro this tonight.
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Xfonhe" <Xfonhe@.discussions.microsoft.com> wrote in message
> news:9034767C-3D75-4C7B-B975-510CC8AFDFDD@.microsoft.com...
> to 2000 once the Distributor has been upgraded. That's the issue here: we
> have an upgraded Distributor, but we cannot upgrade the Publisher for some
> time. In the meantime, we need to create new publications. We are unable to
> do so however, due to the error I outlined. It APPEARS that once you upgrade
> your Distributor, you have to upgrade your Publisher before you can create
> new publications. That doesn't seem right, but I have yet to find evidence
> of its validity.
> SPs/hotfixes on the Distributor w/o applying same to Publisher.
> http://msdn.microsoft.com/library/de...grade_45ir.asp
> Each
> snapshot
> not
> fine.
> upgrade
>
>
|||No, I was unable to get the error. What error did you get, and what service
packs were you running?
Where you using an Administrative Link password?
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Xfonhe" <Xfonhe@.discussions.microsoft.com> wrote in message
news:C359EA3E-0ED4-417C-B1A9-F4F015253BD0@.microsoft.com...[vbcol=seagreen]
> Were you able to reproduce the error?
> Many thanks!!
> X
>
> "Hilary Cotter" wrote:
upgraded[vbcol=seagreen]
we[vbcol=seagreen]
some[vbcol=seagreen]
to[vbcol=seagreen]
upgrade[vbcol=seagreen]
create[vbcol=seagreen]
evidence[vbcol=seagreen]
http://msdn.microsoft.com/library/de...grade_45ir.asp[vbcol=seagreen]
Publisher.[vbcol=seagreen]
disallowed.[vbcol=seagreen]
is[vbcol=seagreen]
does[vbcol=seagreen]
work[vbcol=seagreen]
know?[vbcol=seagreen]
sql

Replication design

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

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

replication cause blocking or deadlock?

Hi all,
I have a question about the replication that induce any blocking or deadlock in SQL? the scenario is server A will have merge
replication with server B on database D1 with table T1, concurrently with a transactional replication with server B on database D2
with T2 (push subscription). Since i found the merge replication is running ok, but when the distribution agent running for
trasaactional replication, a blocking is occur. Any idea of this issues? thanks
Hi,
Thanks for your post.
From your descriptions, I understood that your SQL Agent will raise a
blocking while your merge replication and transactional replication happens
at the same time . Have I understood you? Correct me if I was wrong.
First of all, please know that replication issues tend to be very complex
and hard to troubleshoot in newsgroups. If you need further assistance, I
recommend that you open a Support incident with Microsoft Product Support
Services (PSS) so that a dedicated Support Professional can work with you
in a more timely and efficient manner. If you need any help in this regard,
please let me know.
For a complete list of Microsoft Product Support Services phone numbers,
please go to the following address on the World Wide Web:
http://support.microsoft.com/directory/overview.asp
For now, If you'd still like to continue working via the newsgroup, I want
to set your expectations that the issue might take a long time to narrow
down. During the course of troubleshooting, we may redirect you to PSS if
required.
Generally speaking, blocking or deadlocking occurs when the users on the
system were not freeing up resources, perhaps because they were holding
long running transactions. The user transactions were getting locks on
resources (rows, pages, and/or tables) that the snapshot agent needed
access to and the snapshot agent could not continue without those locks,
and vice versa. The snapshot agent was chosen as a deadlock victim. When
you tried the snapshot agent on a less busy system it was being blocked
instead of deadlocked but this still resulted in the snapshot agent failing
as it now timed out.
So here are some suggestions prevent from the deadlock
1. Running the snapshot agent during a time when few or no users are on the
system. This will reduce but not eliminate the change of a deadlock or
blocking. You can change the QueryTimeout to something higher than the
default of 300 seconds also.
2. Running the snapshot agent with the concurrent snapshot option. This
will reduce but not eliminate the change of a deadlock or blocking. The
StartQueueTimeout can be set to 0 when using this option for an indefinite
wait.
3. Manually synchronizing the subscription during a time when no users are
on the system. You ended up putting the publication database into single
user mode then executing the snapshot agent. This prevented both
deadlocking and blocking.
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||HI Mingqing Cheng,
thanks for your reply, actually the snapshot agent is ok when running but when i start to synchronizing manually, the blocking
occur. It is quite strange that the merge replication is work on Table T1 and transactional replication is work on another table T2
will induce the Blocking.
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message news:2eX0rUDrEHA.752@.cpmsftngxa06.phx.gbl...
> Hi,
> Thanks for your post.
> From your descriptions, I understood that your SQL Agent will raise a
> blocking while your merge replication and transactional replication happens
> at the same time . Have I understood you? Correct me if I was wrong.
> First of all, please know that replication issues tend to be very complex
> and hard to troubleshoot in newsgroups. If you need further assistance, I
> recommend that you open a Support incident with Microsoft Product Support
> Services (PSS) so that a dedicated Support Professional can work with you
> in a more timely and efficient manner. If you need any help in this regard,
> please let me know.
> For a complete list of Microsoft Product Support Services phone numbers,
> please go to the following address on the World Wide Web:
> http://support.microsoft.com/directory/overview.asp
> For now, If you'd still like to continue working via the newsgroup, I want
> to set your expectations that the issue might take a long time to narrow
> down. During the course of troubleshooting, we may redirect you to PSS if
> required.
> Generally speaking, blocking or deadlocking occurs when the users on the
> system were not freeing up resources, perhaps because they were holding
> long running transactions. The user transactions were getting locks on
> resources (rows, pages, and/or tables) that the snapshot agent needed
> access to and the snapshot agent could not continue without those locks,
> and vice versa. The snapshot agent was chosen as a deadlock victim. When
> you tried the snapshot agent on a less busy system it was being blocked
> instead of deadlocked but this still resulted in the snapshot agent failing
> as it now timed out.
> So here are some suggestions prevent from the deadlock
> 1. Running the snapshot agent during a time when few or no users are on the
> system. This will reduce but not eliminate the change of a deadlock or
> blocking. You can change the QueryTimeout to something higher than the
> default of 300 seconds also.
> 2. Running the snapshot agent with the concurrent snapshot option. This
> will reduce but not eliminate the change of a deadlock or blocking. The
> StartQueueTimeout can be set to 0 when using this option for an indefinite
> wait.
> 3. Manually synchronizing the subscription during a time when no users are
> on the system. You ended up putting the publication database into single
> user mode then executing the snapshot agent. This prevented both
> deadlocking and blocking.
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Cweb,
Thanks for your further explaination!
To get a better picture of the problem we would like to reproduct the
issue on our end. To expedite the process, please provide us the detailed
reproduce steps, which, I believe, will make us closer and quicker to the
resolution.
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||HI Mingqing Cheng,
thanks for ur help, the problem seems resolved. Just know that the distribution agent running on transactional replication
scheduled with continuously, when i ask the colleague change it to run hourly, then the blocking seems disappeared. I don't know the
agent schedule will induce the blocking? Anyway, thanks for ur help
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message news:wy6GdYTrEHA.1344@.cpmsftngxa06.phx.gbl...
> Hi Cweb,
> Thanks for your further explaination!
> To get a better picture of the problem we would like to reproduct the
> issue on our end. To expedite the process, please provide us the detailed
> reproduce steps, which, I believe, will make us closer and quicker to the
> resolution.
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi CWeb,
Thanks for your prompt updates letting me know the status of this issue.
Running agent hourly may have opportunity to release the resource so that
the block was also released or reduce the conflict of resource scrambling,
however, I am afraid it is just a workaround but we still cannot define the
root cause.
Anyway, it's great to hear it works fine for you and if you would love to
find the root cause of it, help me reproduce it on my side with your
scripts. Moreover, you could re-open this thread or make a new one whenever
you would like to further help on this issue. We are here to be of
assistance!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

Replication between branches

Good Morning,
I have a dude with a new SQL implementation.
The scenario is a Central office with an SQL server and 10 branch offices
with sql server too. I need to replicate branches data Base with the central
sql.
All the branches could see the same DB.
It is possible to implement with SQL standard?
Or I need the Enterprise edition?
Thanks
Yes - Standard Edition is fine. You might also want to take a look here:
http://www.replicationanswers.com/CentralSubscriberArticle.asp
It might be that this is not the correct implementation - depends on other
factors eg can the branches change each other's data or is it completely
segregated?
Paul Ibison
|||Paul,
The Data can be changed by all the branches.
"Paul Ibison" wrote:

> Yes - Standard Edition is fine. You might also want to take a look here:
> http://www.replicationanswers.com/CentralSubscriberArticle.asp
> It might be that this is not the correct implementation - depends on other
> factors eg can the branches change each other's data or is it completely
> segregated?
> Paul Ibison
>

replication

wot should be the ans of the below scenario..
You are the administrator of a SQL Server 2000 computer. You want to set up snapshot replication on the server. The server will serve as Publisher and Distributor for a minimum of 40/50 Subscribers. Currently, you want to publish 3GB/4GB of data, but the data is expected to grow over time. Subscribers will receive a new snapshot each month. You want to minimize the workload on the Publisher/Distributor. Which two actions should you take to configure snapshot replication? (Each correct answer presents part of the solution. Choose two)
a. Store the snapshot in the default folder on the Publisher/Distributor.
b. Store the snapshot in an alternative folder on the Publisher/Distributor.
c. Store the snapshot in a shared folder on a file server.
d. Create pull subscriptions.
e. Create push subscriptions.I would store the snapshot on a file server
and create pull subscriptions
--
Dandy Weyn, Belgium
MCSE, MCSA, MCDBA, MCT
http://www.dandyman.net
Check my SQL Server resource pages (currently under construction)
http://www.dandyman.net/sql
"rahul" <anonymous@.discussions.microsoft.com> wrote in message
news:A26AAAD3-6275-4C3D-90D9-F97CEB0FE429@.microsoft.com...
> wot should be the ans of the below scenario...
> You are the administrator of a SQL Server 2000 computer. You want to set
up snapshot replication on the server. The server will serve as Publisher
and Distributor for a minimum of 40/50 Subscribers. Currently, you want to
publish 3GB/4GB of data, but the data is expected to grow over time.
Subscribers will receive a new snapshot each month. You want to minimize the
workload on the Publisher/Distributor. Which two actions should you take to
configure snapshot replication? (Each correct answer presents part of the
solution. Choose two)
>
> a. Store the snapshot in the default folder on the Publisher/Distributor.
> b. Store the snapshot in an alternative folder on the
Publisher/Distributor.
> c. Store the snapshot in a shared folder on a file server.
> d. Create pull subscriptions.
> e. Create push subscriptions.
>|||Although I am not a replication expert, I would choose c and d.
Pull subscriptions ( by default) cause the distribution process to run at
the subscriber ( and not the publisher) which offloads work from the
publisher... ( As a side note, SQL 2000 allows a push subscription to have
the subscriber do his own work as well, it is called remote activation..)
Storing the snapshot files somewhere OTHER than the publisher/distributor
simply means that the publisher does NOT have to do IO during the initial
sync with the subscriber..
Hope this help.s
"rahul" <anonymous@.discussions.microsoft.com> wrote in message
news:A26AAAD3-6275-4C3D-90D9-F97CEB0FE429@.microsoft.com...
> wot should be the ans of the below scenario...
> You are the administrator of a SQL Server 2000 computer. You want to set
up snapshot replication on the server. The server will serve as Publisher
and Distributor for a minimum of 40/50 Subscribers. Currently, you want to
publish 3GB/4GB of data, but the data is expected to grow over time.
Subscribers will receive a new snapshot each month. You want to minimize the
workload on the Publisher/Distributor. Which two actions should you take to
configure snapshot replication? (Each correct answer presents part of the
solution. Choose two)
>
> a. Store the snapshot in the default folder on the Publisher/Distributor.
> b. Store the snapshot in an alternative folder on the
Publisher/Distributor.
> c. Store the snapshot in a shared folder on a file server.
> d. Create pull subscriptions.
> e. Create push subscriptions.
>

replication

wot should be the ans of the below scenario...
You are the administrator of a SQL Server 2000 computer. You want to set up
snapshot replication on the server. The server will serve as Publisher and D
istributor for a minimum of 40/50 Subscribers. Currently, you want to publis
h 3GB/4GB of data, but the
data is expected to grow over time. Subscribers will receive a new snapshot
each month. You want to minimize the workload on the Publisher/Distributor.
Which two actions should you take to configure snapshot replication? (Each c
orrect answer presents part
of the solution. Choose two)
a. Store the snapshot in the default folder on the Publisher/Distributor.
b. Store the snapshot in an alternative folder on the Publisher/Distributor.
c. Store the snapshot in a shared folder on a file server.
d. Create pull subscriptions.
e. Create push subscriptions.I would store the snapshot on a file server
and create pull subscriptions
Dandy Weyn, Belgium
MCSE, MCSA, MCDBA, MCT
http://www.dandyman.net
Check my SQL Server resource pages (currently under construction)
http://www.dandyman.net/sql
"rahul" <anonymous@.discussions.microsoft.com> wrote in message
news:A26AAAD3-6275-4C3D-90D9-F97CEB0FE429@.microsoft.com...

quote:

---

> wot should be the ans of the below scenario...
> You are the administrator of a SQL Server 2000 computer. You want to set

---

up snapshot replication on the server. The server will serve as Publisher
and Distributor for a minimum of 40/50 Subscribers. Currently, you want to
publish 3GB/4GB of data, but the data is expected to grow over time.
Subscribers will receive a new snapshot each month. You want to minimize the
workload on the Publisher/Distributor. Which two actions should you take to
configure snapshot replication? (Each correct answer presents part of the
solution. Choose two)

quote:

---

>
> a. Store the snapshot in the default folder on the Publisher/Distributor.
> b. Store the snapshot in an alternative folder on the

---

Publisher/Distributor.

quote:

---

> c. Store the snapshot in a shared folder on a file server.
> d. Create pull subscriptions.
> e. Create push subscriptions.
>

---

|||Although I am not a replication expert, I would choose c and d.
Pull subscriptions ( by default) cause the distribution process to run at
the subscriber ( and not the publisher) which offloads work from the
publisher... ( As a side note, SQL 2000 allows a push subscription to have
the subscriber do his own work as well, it is called remote activation..)
Storing the snapshot files somewhere OTHER than the publisher/distributor
simply means that the publisher does NOT have to do IO during the initial
sync with the subscriber..
Hope this help.s
"rahul" <anonymous@.discussions.microsoft.com> wrote in message
news:A26AAAD3-6275-4C3D-90D9-F97CEB0FE429@.microsoft.com...

quote:

---

> wot should be the ans of the below scenario...
> You are the administrator of a SQL Server 2000 computer. You want to set

---

up snapshot replication on the server. The server will serve as Publisher
and Distributor for a minimum of 40/50 Subscribers. Currently, you want to
publish 3GB/4GB of data, but the data is expected to grow over time.
Subscribers will receive a new snapshot each month. You want to minimize the
workload on the Publisher/Distributor. Which two actions should you take to
configure snapshot replication? (Each correct answer presents part of the
solution. Choose two)

quote:

---

>
> a. Store the snapshot in the default folder on the Publisher/Distributor.
> b. Store the snapshot in an alternative folder on the

---

Publisher/Distributor.

quote:

---

> c. Store the snapshot in a shared folder on a file server.
> d. Create pull subscriptions.
> e. Create push subscriptions.
>

---