Either through EM or using sp_dropsubscription. Whole system locks up. I've
even tried to drop it on a per article basis. First few table/articles went
fine, but when went to drop an article for a very large table, whole system
locked up again.
--Thanks,
Kristy
try sp_dropsubscription from QA. You might want to stop your distribution,
merge, log reader agents to be able to do this. Then start them up one by
one.
How many subscribers do you have? are they push or pull? Are you running
them continuously or staggering them. If you have a large number >50 (or
perhaps even >20) use pull, and stagger your schedules, perhaps every 7 or
11 minutes.
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
"Kristy" <pleasereplyby@.posting.com> wrote in message
news:uAVjjbIMFHA.3832@.TK2MSFTNGP12.phx.gbl...
> Either through EM or using sp_dropsubscription. Whole system locks up.
I've
> even tried to drop it on a per article basis. First few table/articles
went
> fine, but when went to drop an article for a very large table, whole
system
> locked up again.
> --Thanks,
> Kristy
>
|||I have run the sp_dropsubscriptions from QA and it locks up. I have also run
it from QA and have been trying to select on a pure article basis. The first
15 articles went fine, but the 16th locked everything up again. This
particular table is massive, so I didn't know if this had anything to do
with it.
We have 1 publisher and 1 subscriber. distributor is currently on publisher.
THe subscriber is really just a hot backup for the publisher since we don't
have clustering. If something were to happen to pub and we couldn't bring
back up then we would switch to sub.
It is currently a push subscription, but we will be using the pull with a
new subscription. the immediate_sync is 1 (which I think means immediate)
and sync_method = 3 (which I have no idea what that means.) The agents have
not been running for 2 days as we are dropping this subscription and
starting over with a remote distributor and pull subscription. I have even
backed up the distribution database, truncated the ms_repltransactions and
ms_replcommands tables and then shrink the distribution database files.
Previously the dist db had grown to about 60 GB with the combined file size.
Now its about 4 MBs.
I have searched all over online and through the repl book and can't find
anything. I don't know what else to do!!!!
Many thanks for your help,
Kristy
we are using tran repl and I have stopped the agents 2 days ago.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%232YjarIMFHA.3080@.TK2MSFTNGP10.phx.gbl...
> try sp_dropsubscription from QA. You might want to stop your distribution,
> merge, log reader agents to be able to do this. Then start them up one by
> one.
> How many subscribers do you have? are they push or pull? Are you running
> them continuously or staggering them. If you have a large number >50 (or
> perhaps even >20) use pull, and stagger your schedules, perhaps every 7 or
> 11 minutes.
> --
> 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
> "Kristy" <pleasereplyby@.posting.com> wrote in message
> news:uAVjjbIMFHA.3832@.TK2MSFTNGP12.phx.gbl...
> I've
> went
> system
>
|||I figured it out. The previous DBA had a job that put an UPDLOCK, HOLDLOCK
on the table I was trying to drop from replication. I can probably do a drop
all now instead of a per article basis.
--K
"Kristy" <pleasereplyby@.posting.com> wrote in message
news:%23a98n9IMFHA.3988@.tk2msftngp13.phx.gbl...
> I have run the sp_dropsubscriptions from QA and it locks up. I have also
run
> it from QA and have been trying to select on a pure article basis. The
first
> 15 articles went fine, but the 16th locked everything up again. This
> particular table is massive, so I didn't know if this had anything to do
> with it.
> We have 1 publisher and 1 subscriber. distributor is currently on
publisher.
> THe subscriber is really just a hot backup for the publisher since we
don't
> have clustering. If something were to happen to pub and we couldn't bring
> back up then we would switch to sub.
> It is currently a push subscription, but we will be using the pull with a
> new subscription. the immediate_sync is 1 (which I think means immediate)
> and sync_method = 3 (which I have no idea what that means.) The agents
have
> not been running for 2 days as we are dropping this subscription and
> starting over with a remote distributor and pull subscription. I have even
> backed up the distribution database, truncated the ms_repltransactions and
> ms_replcommands tables and then shrink the distribution database files.
> Previously the dist db had grown to about 60 GB with the combined file
size.[vbcol=seagreen]
> Now its about 4 MBs.
> I have searched all over online and through the repl book and can't find
> anything. I don't know what else to do!!!!
> Many thanks for your help,
> Kristy
> we are using tran repl and I have stopped the agents 2 days ago.
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%232YjarIMFHA.3080@.TK2MSFTNGP10.phx.gbl...
distribution,[vbcol=seagreen]
by[vbcol=seagreen]
or
>
No comments:
Post a Comment