Have you tried sp_removedbreplication?
I'm assuming the database has been restored from another copy where it was
replicated, for the replication metadata to have got in ther in the first
place.
Here's a link for removedbreplication (from BOL 2005, but applies to 2000 as
well)
http://msdn2.microsoft.com/en-us/library/ms188734.aspx
you won't lose any objects. It just removes replication information which
will hopefully stop your t-log growing.
It doesn't drop any objects.
|||I thought you said it wasn't replicated? Now you're telling me it's your
publisher? You should make your mind up.
Running sp_removedbreplication will NOT remove any of your user objects. It
ONLY removes replication metadata. You can run it with a clause, e.g. 'tran',
'merge' etc. if you only want to remove transactional- or merge- replication
metadata.
I think you need to reassure yourself what is actually going on with your
database, i.e. is it being replicated or not. 'Cos the signals you're sending
out are somewhat mixed.
"Susanne Wenzel" wrote:
> Am Tue, 28 Nov 2006 00:54:01 -0800 schrieb thomarse:
>
> Are you sure about that? I've looked it up again in BOL and it says there
> it deletes all replication objects in a database. I would assume that means
> that all replication tables and stored procedures for replication will be
> removed. As the said database is our publisher that wouldn't come too
> good..
> Greetings
> Susanne
>
Wednesday, March 21, 2012
DBCC Opentran - possible causes for results
Labels:
assuming,
causes,
copy,
database,
dbcc,
microsoft,
mysql,
opentran,
oracle,
replication,
restored,
server,
sp_removedbreplicationim,
sql,
wasreplicated
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment