1. In-Memory OLTP for Database Developers
Jos de Bruijn | Senior Program Manager

2. Agenda Memory-optimized tables and indexes
Accessing memory-optimized tables
Tools for Analysis and Migration

3. TechReady 16
1/16/2019
In-Memory OLTP Recap
SQL Server 2014 adds in-memory technology to boost performance of OLTP workloads
Memory optimized table and index structures
Native compilation of business logic in stored procedures
Latch- and lock-free data structures
Fully integrated into SQL Server
Talking points:
* Main target scenario is high throughput OLTP; other scenarios include ETL, read scale-up (many concurrent transactions reading same data), and burst insert/update (i.e., batches of updates, interfering with read workload)
Memory optimized data structures
Novel data structures – no Btree and no PINTABLE
Use new structures such as hash indexes
Tables reside in memory
Indexes exist only in memory
Tables are still fully durable – there is a copy of the data on disk for crash recovery purposes
Native compilation
T-SQL Stored procedures are compiled to native code as DLLs
Allows more efficient query execution by reducing the CPU cycles required for each operation
Latch- and lock-free data structures
Table structures are multi-versioned. This is built right into the data structures, no tempdb usage
Data structures are latch free – row updates are realized by inserting new row versions
No locks, thus no blocking. Transactional consistency is guaranteed through multi-versioning and conflict detection
Integration in SQL Server
Use the same familiar T-SQL syntax for creating memory optimized tables and natively compiled stored procedures
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

4. Memory optimized tables and indexes
1/16/ :18 PM
Memory optimized tables and indexes
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

5. Create Table DDL Hash Index Indexes are specified inline
BUCKET_COUNT 1-2X nr of unique index key values
CREATE TABLE [Customer](
[CustomerID] INT NOT NULL
PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = ),
[Name] NVARCHAR(250) NOT NULL,
[CustomerSince] DATETIME NULL
INDEX [ICustomerSince] NONCLUSTERED )
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
Indexes are specified inline
NONCLUSTERED indexes are supported
Talking points:
* Hash indexes are good for point lookups; need bucket count
Range indexes are in the plan; you can think of a range index as a kind of nonclustered index, except that it is memory optimized and latch-free – no bucket-count required
Like hash indexes, range indexes will be inherently covering
This table is memory optimized
This table is durable

6. Memory Optimized Table Creation
CREATE TABLE DDL
Code generation and compilation
Table DLL produced
Table DLL loaded
Talking points:
This diagram shows what happens when a table is created
Tables are compiled for efficient access to table data – knowledge about indexes, columns, datatypes, etc, is baked into the DLL
DLL is loaded immediately after compilation
DLL is recompiled at server startup, so no risk of anyone tampering with the DLLs while the server is down

7. Creating Memory Optimized Tables
1/16/ :18 PM
Creating Memory Optimized Tables
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

8. Memory-Optimized Indexes
Exist only in memory
Rebuilt on database startup
Do not contain data rows
Indexes contain memory pointers to the data rows
No duplication of data
All indexes are covering
Hash Indexes
Need to specify bucket_count – usually 1-2X the number of unique index keys
Optimized for point-lookups
Do not support range lookups (search on inequality predicate) or ordered scans (for ORDER BY)
Nonclustered Indexes
No need to specify any options
Optimized for range lookups and ordered scans
Support point-lookups, but hash indexes are much faster

9. Memory-optimized Indexes
1/16/ :18 PM
Memory-optimized Indexes
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

10. Accessing memory optimized tables
1/16/ :18 PM
Accessing memory optimized tables
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

11. Create Procedure DDL
CREATE PROCEDURE DATETIME
WITH
NATIVE_COMPILATION,
SCHEMABINDING,
EXECUTE AS OWNER AS
BEGIN ATOMIC
(TRANSACTION
ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N'us_english')
-- insert T-SQL here
END
This proc is natively compiled
Native procs must be schema-bound
Execution context is required
Atomic blocks
Create a transaction if there is none
Otherwise, create a savepoint
Talking points:
* Hash indexes are good for point lookups; need bucket count
Range indexes are in the plan; you can think of a range index as a kind of nonclustered index, except that it is memory optimized and latch-free – no bucket-count required
Like hash indexes, range indexes will be inherently covering
Session settings are fixed at create time

12. Procedure Creation CREATE PROC DDL Query optimization
Code generation and compilation
Procedure DLL produced
Procedure DLL loaded
Talking points:
This diagram shows what happens when a table is created
Tables are compiled for more efficient access to table data – knowledge about indexes, columns, datatypes, etc, is baked into the DLL
DLL is loaded immediately after compilation
DLL is recompiled at server startup, so no risk of anyone tampering with the DLLs while the server is down

13. Accessing Memory Optimized Tables
TechReady 16
1/16/2019
Accessing Memory Optimized Tables
Interpreted T-SQL Access
Natively Compiled Stored Procs
Access both memory- and disk-based tables
Less performant
Virtually full T-SQL surface
When to use
Ad hoc queries
Reporting-style queries
Speeding up app migration
Access only memory optimized tables
Maximum performance
Limited T-SQL surface area
When to use
OLTP-style operations
Optimize performance critical business logic
Starting SQL “14”, SQL Server has both memory optimized and disk-based tables
The familiar interpreted T-SQL can be used to access both
Hekaton introduces natively compiled stored procedures for efficient access to memory optimized tables, and efficient business logic execution
Can access only memory optimized tables
Machine code in DLLs can access the table and index structures directly; machine code requires fewer CPU cycles to execute the queries than the SQL Server query execution engine, interpreting the query execution plan
Because most query operators and functions need to be re-implemented for native procs, we have limitations in the query surface area in native procs. For example, no OR, no subqueries, and we will have a limited number of built-in functions
While interpreted T-SQL is less performant, there is more flexibility:
1. can use ad hoc batches
2. no restrictions on T-SQL surface area
3. can access both memory optimized and disk-based tables in the same query
With interop there is still the benefit of latch-free data structures
Interop limitations – No Cursors (except for static readonly cursors, API cursors), table sample, MERGE with memory optimized table as target
You can start with interop, and over time move to natively compiled stored procedures.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

14. Accessing Memory Optimized Tables
1/16/ :18 PM
Accessing Memory Optimized Tables
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

15. Tools for Analysis and Migration

16. Analysis and Migration Tools

17. Limitations on In-Memory OLTP in SQL 2014
1/16/ :18 PM
Limitations on In-Memory OLTP in SQL 2014
Tables
Triggers: no DDL/DML triggers
Data types: no LOBs, no XML and no CLR data types
Constraints: no FOREIGN KEY and no CHECK constraints
No schema changes (ALTER TABLE) – need to drop/recreate table
No add/remove index – need to drop/recreate table
Natively Compiled Stored Procedures
No outer join, no OR, no subqueries, no CASE
Limited built-in functions [core math, date/time, and string functions are available]
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

18. Recap Memory optimized tables and indexes
Are natively compiled on create
New memory-optimized indexes
Hash indexes for point lookups
Nonclustered indexes for ordered scans and range searches
Accessing memory optimized tables
Natively compiled stored procedures – best performance, but T-SQL limitations
Interpreted T-SQL access – full T-SQL surface area, and joins with disk-based tables
Analysis and Migration Tools
Identify tables and procedures to migrate
Memory Optimization Advisor identifies migration blockers, and aids migration
Native Compilation Advisor identifies migration blockers

19. Resources Limitations and workarounds
Overview of all In-Memory OLTP posts on the SQL Server blog
SQL 2014 CTP2
Getting started with In-Memory OLTP
In-Memory OLTP Sample, based on AdventureWorks
Analysis and Migration tools
Transaction isolation with In-Memory OLTP
Choosing isolation level:
Implement retry logic:
Books Online documentation for In-Memory OLTP
Limitations and workarounds