• Chad Crawford (5/2/2016)


    TomThomson (4/30/2016)


    Serializable is probably OTT since repeatable read may be adequate (maybe that depends on what sort of updating is going on, I haven't thought it through) but I suspect it isn't going to deliver high performance; nor is snapshot isolation, the temp database is probably going to grow too much when a vast collection of export chunks have to be mutually compatible and snapshot isolation is used to ensure that by building them all in one enormous transaction.

    Repeatable Read would have less overhead, but it would still have problems with Phantom Reads which could occur if the database is not quiesced and more than one table is read. For example, you could catch a row in table B that is paired with a row in table A that you didn’t pick up during its export. You could ignore any rows that are newer than the time you started the export, but you would need some way of identifying which rows those are – if Grant needs a truly generic solution and can’t enforce any schema, that would be challenging.

    Edit: Ah - I just realized that I made an assumption that Grant never stated. I assumed this was for multiple tables, not just a single one. You're right - I think I did make it overly complicated.

    It is multiple tables.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning