Post reply

in-memory rowstore

  • March 2, 2017 at 4:29 am

    #322175

    Hi

    we're looking to implement change tracking on a production database.

    Looking at the documentation I see that the Syscommittab table is a In-memory Rowstore.

    I'm trying to understand exactly what an in-memory rowstore is.  I can't find any documentation.

    Questions that occur are.......

    Is the data in the table sometimes written to disk?
    Does sql try to keep the entire table in memory at all times
    What happens when the system reboots.

    Answers or links to good documentation really appreciated. 🙂

    Alex

  • March 2, 2017 at 5:13 am

    #1931136

    Google: "In-memory OLTP" It's a feature added in SQL 2014, way too large to cover in a single forum post.
    Also consider getting https://www.simple-talk.com/books/sql-books/sql-server-internals-in-memory-oltp/

    It's not a simple feature

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • March 2, 2017 at 6:24 am

    #1931149

    I came across that but it doesn't apply.  The change tracking is on a 2008 sql server

    I think the syscommit table is an in-memory rowstore from this article

    https://troubleshootingsql.com/tag/change-tracking-cleanup/

    Which says

    Change tracking information is stored for all tables (enabled for Change Tracking) in a database in an in-memory rowstore (syscommittable). This in-memory rowstore is flushed every checkpoint to the on-disk table (syscommittab). Rows from the syscommittab internal table are removed during every checkpoint.

    Am I barking up the wrong tree and making a mountain out of a molehill. Is this something I should understand? What is the in-memory rowstore structure it refers to?

  • March 2, 2017 at 6:30 am

    #1931152

    If it's 2008, then it'll be something internal that you can't affect and can't change, and can't use for your own tables. Probably just an optimisation to avoid constant writes to disk.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 4 posts - 1 through 3 (of 3 total)

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