Row Level Versioning

  • Good intro.

    MVCC (multi-version concurrency) is a major addition to SQL Server.

    I encourage everyone to fully understanding the differences between Read Committed Snapshot, and SnapShot Isolation. Miss-use of SnapShot Isolation can lead to excessive, and usually unexpected tempdb usage.

    Here are some references:


    The more you are prepared, the less you need it.

  • I am using SQL server 2005. I just tried executing your example given here. Though i don't commit the transaction 'a' i am getting the updated value '2' when i run select query. what could be the reason?

    And also you are saying that the tempdb database is used for row level versioning stuff. But i could not see the 'test' table (which i created) in tempdb database. I am thinking that the 'test' table will be created in tempdb too. what do you say? Or else where does it stores versioning data?

  • Very nice article. it is very clear..

    Tempdb will go like anything because of row versioning also.. so is there anyway to remove old row versioning data from tempdb or sql server itself will remove old row versioning data automatically or it can be done manually. if so, how it should be implemented?

    please clarify this....



  • Thank you. The old data will be cleared automatically. You do not have to worry about that. Just keep in mind that the more transactions you have (update, insert and delete) the more tempdb will be used. Along with the normal tempDB usage.


  • Thanks Roy. Thanks a lot....



  • I just did the same way as roy suggested. I turned ON row-level versioning. But it was not working the way he said. Do i need to restart my instance to take the effect of database option change(row level versioning)?

  • Did you run the select statement on the same query window or on a different SID?


  • I just ran the sample script provided in the article. But i am not seeing the effect of row-versioning. I have enabled LLOW_SNAPSHOT_ISOLATION & READ_COMMITTED_SNAPSHOT also.

    Do i need to restart my instance to take effect.

  • Even i get the result reflecting with new value before the commit tran is issued.

    I had ran all the select & update with same SID.

    Also, if th above doesnt make any sense. DO i need to recycle my sql sever instance to take effect. ?????

  • The select should be run on a different SID. If you run it on the same SID, you will see the updated non committed value.


  • Thanks for article Roy.

    i am considering turning on these features on an application we have at my current company, but had a question.

    If i alter my database with;





    Do I need to alter all my existing stored procedures that make use of the



    also, the hint with (NOLOCK), should those also be removed?


  • Yes, you will need to remove those hints that you have given. It will defeat the purpose.


  • I also got incorrect results. I could never get the other machine (or the local machine, for that matter) to show me the 2 once I had run transaction b.

  • Huonglien Nguyen (3/6/2009)

    I followed through the steps but eventhough after I executed "Commit tran a" the select * on dbo.test still showed me the old data: 1212121 and if I executed "Commit tran b" the select statement showed value 5. So I actually never saw the value 2 at all. Do you have any idea? Thanks.

    I got the same results. The article seems very good and I have a much better understanding of SQL Server's row level versioning capabilities, but I got the same results here. Will continue reading for any insight into why this happens.


Viewing 14 posts - 31 through 43 (of 43 total)

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