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

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

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.

Memory optimized tables and indexes 1/16/2019 10: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.

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 = 1000000), [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

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

Creating Memory Optimized Tables 1/16/2019 10: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.

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

Memory-optimized Indexes 1/16/2019 10: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.

Accessing memory optimized tables 1/16/2019 10: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.

Create Procedure DDL CREATE PROCEDURE [dbo].[InsertOrder] @id INT, @date 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

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

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.

Accessing Memory Optimized Tables 1/16/2019 10: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.

Tools for Analysis and Migration

Analysis and Migration Tools

Limitations on In-Memory OLTP in SQL 2014 1/16/2019 10: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.

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

Resources Limitations and workarounds Overview of all In-Memory OLTP posts on the SQL Server blog http://blogs.technet.com/b/dataplatforminsider/archive/2013/10/15/the-411-on-the-microsoft-sql-server-2014-in-memory-oltp-blog-series.aspx SQL 2014 CTP2 http://technet.microsoft.com/en-US/evalcenter/dn205290?WT.mc_id=Blog_SQL_InMem_CTP2 Getting started with In-Memory OLTP http://blogs.technet.com/b/dataplatforminsider/archive/2013/06/26/getting-started-with-sql-server-2014-in-memory-oltp.aspx In-Memory OLTP Sample, based on AdventureWorks https://msftdbprodsamples.codeplex.com/releases/view/114491?WT.mc_id=Blog_SQL_InMem_CTP2 Analysis and Migration tools http://technet.microsoft.com/en-us/library/dn205133(v=sql.120).aspx http://technet.microsoft.com/en-us/library/dn284308(v=sql.120).aspx http://technet.microsoft.com/en-us/library/dn358355(v=sql.120).aspx Transaction isolation with In-Memory OLTP Choosing isolation level: http://msdn.microsoft.com/en-us/library/dn133187(v=sql.120).aspx Implement retry logic: http://msdn.microsoft.com/en-us/library/dn169141(v=sql.120).aspx Books Online documentation for In-Memory OLTP http://technet.microsoft.com/en-us/library/dn133186(v=sql.120).aspx Limitations and workarounds http://msdn.microsoft.com/en-us/library/dn247639(v=sql.120).aspx