Hello
I have an issue on Deleting rows on Publisher.
I want to keep a 2 months old transaction data both on my Publisher
and on the Subscribers as well,
so eatch night a process is run on the publisher that deletes 2 months
old data, so actually eatch night
I have a deletion of 1 days data (the 61st day).
Now the problem is that the next day, in the morning synchronisation,
eatch of my subscriber gets about 100.000 or even more deletions and
that makes synchronization slow.Although i have filters on my
replication,somehow deletions are send to all subscribers!!!
Now I am looking for solutions!!!
One thought of mine is to delete 2 months old transactions from eatch
subscriber, but because some subscribers share data then I belive that
if a deletion occured in a subscriber then when it synchronises the
deletion is passed to the publisher and then this deletion again is
going to be transfered to other subscribers when they try to
syncronise after.Am I right? So the issue will still be an issue.
Any Ideas of how to delete records in my case?
Please help!
You could replicate the execution of a stored procedure which does the
delete, and this way only the stored proc will be executed on the subscriber.
Rgds,
Paul Ibison
|||Thanks for the quick answer ... can u please be more specific.
How can I do this?
And if the deletion ocurs on the sunscriber wont that be transfer to
the publisher and then to other subscribers
that share data?
Thanks
|||In sp_addarticle there is the option to use @.type = 'proc exec' and this
option also exists on the article properties when using the gui to replicate
a stored procedure using transactional replication. Note that this applies
only when running the stored proc on the publisher so you'd have to remove
the rows in this direction only.
Rgds,
Paul Ibison
|||I am using Merge Replication does this applies to Merge Replication as
well ?
|||No - the replication of the execution of stored procedures is a transactional
attribute.
Rgds,
Paul Ibison
|||Any Ideas about Merge Replication ?
Because I am using merge replication and my system is live, I cannot
change to other type of replication,
i am searching for a solution, something i can implement fast.
Thanks
|||There's nothing obvious because what you need is some way of bypassing the
normal functioning of merge. i suppose you could disable the merge triggers
then send down a delete command using sp_addscriptexec to remove the rows
then reenable the triggers. However then you'll still have the replication
metadata hanging around for these rows until it gets cleaned up. Also if
there are any concurrent updates to these rows then there'll be problems
because the merge agent will be looking for missing rows when it
synchrionizes.
There might be some way of modifying a column on the rows so they fall
outside of a filter you place on the article and are therefore not
replicated. Then you could manually remove them on the publisher and via a
script on the subscriber - this is what I'd investigate.
Rgds,
Paul Ibison
"savvaschr@.nodalsoft.com.cy" wrote:
> Any Ideas about Merge Replication ?
> Because I am using merge replication and my system is live, I cannot
> change to other type of replication,
> i am searching for a solution, something i can implement fast.
> Thanks
>
|||Thanks for your time and Answers,
Finaly I found the answer.
You can specify at the publisher the @.delete_tracking variable of
sp_addmergearticle to 'false'
By doing this the Publisher deletes records and does not send them for
synchronisation.
So in my case, I delete 2 months old rows from my transactions table
at the Publisher, those deletions
are not send in the Synchronisation, and then I delete individually 2
month old transactions from my subscribers.
In this way my synchronisation is faster because Subscribers dont have
to process 100.000 deletions or more
every morning that they Synchronise.
Regards
Savvas
Thursday, March 29, 2012
Deleting Rows from Publisher and from Subscriber
Labels:
database,
deleting,
helloi,
microsoft,
mysql,
old,
oracle,
publisher,
publisherand,
rows,
server,
sql,
subscriber,
subscribers,
transaction
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment