Database Reference
In-Depth Information
Baselines
You should already be planning on establishing a performance baseline of your system by gathering various metrics
using Performance Monitor, the dynamic management objects, Extended Events, and all the other tools at your
disposal. Once you have the baseline, you can make determinations if your workload is likely to benefit from the
reduced locking and increased speed of the in-memory tables.
Correct Workload
This technology is called in-memory OLTP tables for a reason. If you are dealing with a system that is primarily
read focused, has only nightly or intermittent loads, or has a very low level of online transaction processing as its
workload, the in-memory tables and natively compiled procedures are unlikely to be a major benefit for you. If you're
dealing with a lot of latency in your system, the in-memory tables could be a good solution. Microsoft has outlined
several other potentially beneficial workloads that you could consider using in-memory tables and natively compiled
Memory Optimization Advisor
To quickly and easily determine whether a table is a good candidate for moving to in-memory storage, Microsoft
has supplied a new tool within SSMS. If you use the Object Explorer to navigate to a particular table, you can
right-click that table and select Memory Optimization Advisor from the context menu. That will open a wizard. If I
select the
Person.Address
table that I manually migrated earlier, the initial check will find all the columns that are not
supported within the in-memory table. That will stop the wizard, and no other options are available. The output looks
like Figure
23-12
.
