Replication Problems / questions

  • I have 15 or so servers replicating to a central location. Generally running very well.

    3 issue's

    I ran some deletes at a publisher that apparently don't exist on the subscriber so now the replication is broken.

    "Row not found at subscriber"

    I have resolved this in the past by recreating the replication from that server, there has to be a better way.

    I think the problem relates to my second issue.

    The DB at the publisher(s) was created and running for sometime prior to enabling replication. I wanted to move all data, but do not want to destroy the data already in the subscriber, from other servers.

    Is there an easy way to have it move ALL data when creating the replication without having it recreate the db at the subscriber. (ie snapshot seems to wipe out the existing db, or am I wrong).

    Third problem.

    I am going to be setting up historical deletes at the publishers, that I do NOT want replicated. I want the central repository to retain the history forever, but don't need it remotely after n days / years ...

    Note - while I don't really want to lose any data at the central repository, it is really not important if it misses an update or 2 from any of the publishers.

    Sorry for the multiple questions, but I think there is a common thread somewhere.

    Thanks Much

    KlK, MCSE


    KlK

  • Lot of stuff there! On the row not found, you can add a switch to tell the agent to 'skip' errors. Not the best solution, but often good enough. Historical deletes are interesting, I'll have to think about that.

    Andy

    http://qa.sqlservercentral.com/columnists/awarren/

  • Thanks Andy, but where is this switch I poked around and couldn't find it.

    For this app it probably would be a major issue.

    This is for a DB history tool I have been slowly putting together. I hope to get a couple of more features in it, clean it up a little and maybe release it here or ??

    Provides some basic history of DB dasd etc, I have a couple of neat features that will be a ways off, but I do have them sort working already. But the basic part is pretty close, and with replication it is pretty cool.

    KlK, MCSE


    KlK

  • Andy I did find the switch, seems to be working now.

    Thanks

    KlK, MCSE


    KlK

  • Cool. If/when you come up with more, post it or write up an article - I'd like to see how it works out.

    Andy

    http://qa.sqlservercentral.com/columnists/awarren/

  • Andy, in researching another problem, but I've been meaning to find / respond.

    I solved the issue of having deletes at the remote site, not be applied to the central site.

    I went in and basically commented out the SPs used on the "Pull" subscriber that handle the deletes.

    So we suffer the network overhead of shipping them to the central site, where they get ignore. Not elegant, but it works !!

    KlK, MCSE


    KlK

  • As far as the "delete" errors go...you can create a custom Agent Profile for the Distribution Agent. On the -SkipErrors property you can put 20598. This error is "The row was not found at the Subscriber when applying the replicated command." OR you could just use the "continue on data consistancy errors" profile that's already defined. To change the profile, right-click on the Dist. Agent and pick "Agent Profile...". This profile skips a few other errors though.

    Once you have the profile changed (you must restart the dist. agent), replication will continue even if the row was deleted.

    -Dan


    -Dan

  • I have 74 subscribers to one publisher, and is very common that I have those kind of problems, since some months ago (before I started) they lost the data with a hard disk problem, and there are still some inconsistency.

    What I do is check what row is missing in the publisher (The error message also shows the call to the Sp with the primary keys) and inserted into the subscriber/s.

  • Well this note was for Andy,

    The issue is deleting historical data at the publishers, but not at the subscriber.

    The process is creating historical data at each server to allow us to track growth, and dasd usage. I have added the version information so out inventory becomes self maintaining. And am working on Job schedules and a couple of other little things.

    But I don't want all of this data piling up on the various servers, just here on the central repository. I have an SP that deletes data over say a week old on the remote (publishers), I do NOT want them applied at the central site maintaing the history.

    So the solution is to go into the Delete SPs used at the subscriber(central site) to process the delete, and comment everything out. The transaction is replicated to the central site, and the SP executed, it just doesn't do anything.

    KlK, MCSE


    KlK

  • I know you can skip selected errors in SQL 2K, i.e. "On the -SkipErrors property you can put 20598.", but is there anything similar I can do for SQL 7? I need to have transactional replication continue even when there are data collision errors. I can make this work in 2000, but 7 is a mystery (-SkipErrors is not an available profile parameter). Any clues? I realize I can write my own stored procedures on the subscriber end to deal with this, but I'd really rather not. I'd like to keep the 7 and 2K deployments as similar as possible. Thanks for any ideas.


    Have Fun!
    Ronzo

  • I have the same issue..As I implement SKIPERRORS everythings fine except I have missing records on SUbscriber.

    I have an application on Publisher site..Everyday importing some new records which comes from the departments when import operation completes we start syncronizing Transactional Replication to 1 subscriber.

    When we look at subscriber db there are lots of missing records. If we do the import operation again at publisher (2nd or 3th time) then the records are able to apear on subscriber...

     

    Any help will be usefull

    Regards

    Hakan

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply