Snapshot Agent

  • Comments posted to this topic are about the item Snapshot Agent

  • Interesting question, thanks.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • Good One, thanks.

    ---------------------------------------------------
    "Thare are only 10 types of people in the world:
    Those who understand binary, and those who don't."

  • This was removed by the editor as SPAM

  • Thank you Koen, Mascot and Stewart

  • Interesting question.

    I could have this wrong :ermm:, but:

    The statement in the article referenced may apply only to the initial snapshot generation on the publisher (ie to generation of the schema snapshot) for some configurations of merge replication; no locks are needed on published tables because the schema snapshot contains no bcp data describing table content. When during subscriber initialisation a snapshot for a subscriber in the same partition has not yet been generated, and the publication allows subscribers to initiate snapshots (which avoids the slow process of initialising the subscriber using remote select statements) a partition snapshot has to be generated to contain the BCP data for the published tables, and may require locks on the published tables (it can and presumably will use READPAST hints to avoid lock clashes that would make it wait, but that doesn't stop it taking locks). So I think the answer to the question is wrong for the case where some of the publication's tables use parametrized row filters and the publication allows subscribers to initialise snapshots.

    I don't really understand this stuff - haven't read enough about merge replication. I could have it completely mixed up.

    Tom

  • (2/17/2014)


    Interesting question.

    I could have this wrong , but:

    The statement in the article referenced may apply only to the initial snapshot generation on the publisher (ie to generation of the schema snapshot) for some configurations of merge replication; no locks are needed on published tables because the schema snapshot contains no bcp data describing table content. When during subscriber initialisation a snapshot for a subscriber in the same partition has not yet been generated, and the publication allows subscribers to initiate snapshots (which avoids the slow process of initialising the subscriber using remote select statements) a partition snapshot has to be generated to contain the BCP data for the published tables, and may require locks on the published tables (it can and presumably will use READPAST hints to avoid lock clashes that would make it wait, but that doesn't stop it taking locks). So I think the answer to the question is wrong for the case where some of the publication's tables use parametrized row filters and the publication allows subscribers to initialise snapshots.

    I don't really understand this stuff - haven't read enough about merge replication. I could have it completely mixed up.

    Tom

    + 1

  • Hard one this was.

  • I'd like to add a another link. This one cleared the questions I had about locks.

    http://technet.microsoft.com/en-us/library/ms151740.aspx

    Tom

  • Thanks for the question.



    Everything is awesome!

  • Thanks for the question

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Thanks for the question, Jagadish!

  • nice question..

  • Not even a Shared lock, huh?

    Todd Carrier
    MCITP - Database Administrator (SQL 2008)
    MCSE: Data Platform (SQL 2012)

Viewing 15 posts - 1 through 15 (of 17 total)

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