Replication

  • Simple, straightforward, nice. Thanks, Steve!

  • Hugo Kornelis (1/23/2014)


    L' Eomot Inversé (1/23/2014)


    Interesting question. I thought it worked for all models, but ir's so long since I last looked at replication that I thought I might be wrong, so checked in MSDN. The page I checked was The Transaction Log, which seems to say that log records are retained until the data has been replicated only in full recovery model, which seems to me to imply that transactional replication will not work in either simple or bulk-logged model, so (thinking that MSDN was more likely to have that right than my memory) I picked that answer - the wrongest one of the three.

    Is that page wrong, or do the other recovery models have some method of delaying the discard of log records pending replication other than by setting log_reuse_wait to 6 in the affected records? Or perhaps in this question "replication works" means "snapshot replication works" (snapshot uses value 7, not value 6, to delay truncation)?

    When replication is used, the log is not reused even when you are in simple recovery. Once replication has catched up, it will be available for reuse. (In full recovery, log records will not be reused until both the log backup and replication have catched up).

    Yes, but how is release of the log records prevented? If the log_reuse_wait attribute in sys.databases is not set to 6 and there is no other value that indicates that transactional replication requires the log not to be truncated (value 7 is explicitly for snapshot creation, so not relevant to transactional replication except possibly while an initial snapshot is being created, and nothing else seems remotely relevant) it looks as if some method is used that doesn't use that attribute, so it seems that it can't be this attribute being nonzero that tells the system that it can't recover any virtual log files. Maybe simple and bulk logged recovery models set it to 1 when no VLF can be retrieved because of transactional replication?

    Tom

  • L' Eomot Inversé (1/24/2014)


    Yes, but how is release of the log records prevented?

    My guess is that the information on that page you used is incorrect. But I have never worked with a replicated database in simple recovery, and I am too lazy to set up a test scenario now.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Hugo Kornelis (1/24/2014)


    L' Eomot Inversé (1/24/2014)


    Yes, but how is release of the log records prevented?

    My guess is that the information on that page you used is incorrect. But I have never worked with a replicated database in simple recovery, and I am too lazy to set up a test scenario now.

    Sounds like a reasonable guess to me. So maybe in future I'll trust my memory and not check in BOL even when it's something I last looked at a long time ago.

    Tom

  • Good one! help to sharpen Replication skill... recalling old memories 🙂

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

  • Hugo Kornelis (1/24/2014)


    L' Eomot Inversé (1/24/2014)


    Yes, but how is release of the log records prevented?

    My guess is that the information on that page you used is incorrect. But I have never worked with a replicated database in simple recovery, and I am too lazy to set up a test scenario now.

    AFAIK, log reuse shows up as "replication" in Simple mode and then it's not cleared.

    www.sqlservercentral.com/Forums/Topic1142599-391-1.aspx

  • Easy one comparatively to last day. 🙂

Viewing 7 posts - 16 through 21 (of 21 total)

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