Question

Our most frequently used database is relatively small (5GB), and as a consequence, our 16GB memory dedicated SQL Server 2012 database server chooses to cache all used tables in memory (Buffer Cache Hit Ratio is 100% constantly). Some people in our team want to move to SQL Server 2014 to increase performance with In-Memory Tables, however I'm not convinced that doing such will increase performance since our tables are already in memory.

Is there more to the new In-Memory Tables in SQL Server 2014, or in my scenario there is indeed little to gain?

Was it helpful?

Solution

Some people in our team want to move to SQL Server 2014 to increase performance with In-Memory Tables ...

That entirely depends on:

  1. If more performance is needed
  2. What the current bottleneck is

however I'm not convinced that doing such will increase performance since our tables are already in memory.

You should be suspect that it may or may not improve performance, however the reason isn't because the data is already in memory. It is mainly due to being lock and latch free and less code execution with native compilation.

Thus, if your bottleneck isn't around locks or latches... the actual gain you receive will be minimal to none. This can be exacerbated if the actual bottleneck is the client.

There is a great article about use cases for IMOLTP, and while we are at it you may want to look at 2016 and the uses of IMOLTP for advanced real time analytics.

Is there more to the new In-Memory Tables in SQL Server 2014, or in my scenario there is indeed little to gain?

In-Memory objects (in this case, tables) are not just pinning data into memory. They have entirely different memory structures and are lock and latch free.

There are additional differences in how the data is stored, how it affects database startup, etc.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top