SQL Server In-Memory OLTP: What Every SQL Professional Should Know 6/4/2018 12:26 AM Decks and demos at http://aka.ms/bobwardms Latch free since 2007 SQL Server In-Memory OLTP: What Every SQL Professional Should Know http://aka.ms/bobsql bobward@microsoft.com @bobwardms, #bobsql Bob Ward Principal Architect Microsoft, Data Group, Tiger Team © Microsoft Corporation. All rights reserved.

How do I use this? The What and Why How does this work? Let’s Do This 6/4/2018 12:26 AM Based on SQL Server 2016 Let’s Do This The What and Why How do I use this? How does this work? © Microsoft Corporation. All rights reserved.

The What and Why ἑκατόν 6/4/2018 12:26 AM © Microsoft Corporation. All rights reserved.

The Research behind the concept OLTP Through the Looking Glass, and What We Found There by Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, Michael Stonebraker , SIGMOD 2008 TPC-C hand-coded on top of the SHORE storage engine 2/17/2008

The Path to In-Memory OLTP Project Verde 2007 “Early” Hekaton 2009/2010 Hekaton becomes In-Memory OLTP SQL Server 2014 In-Memory OLTP Unleashed SQL Server 2016

Why In-Memory OLTP? Keep SQL Server relevant in a world of high-speed hardware with dense cores, fast I/O, and inexpensive massive memory The need for high-speed OLTP transactions at microsecond speed Reduce the number of instructions to execute a transaction Find areas of latency for a transaction and reduce its footprint Use multi-version optimistic concurrency and “lock free” algorithms Use DLLs and native compiled procs XTP = eXtreme Transaction Processing HK = Hekaton

Demo: Just Show Us! See In-Memory OLTP in action 6/4/2018 12:26 AM Use the instructions in readme.md in demo1_just_show_us © Microsoft Corporation. All rights reserved.

What is it Really? Memory-Optimized Tables Memory Optimized FILEGROUP 6/4/2018 12:26 AM Memory-Optimized Tables What is it Really? “Feels” like normal disk-based tables but in memory Internally completely different Hash or non-clustered index choices (at least one required) Memory Optimized FILEGROUP Checkpoint Files Engine within an Engine SQLSERVR.EXE Query Processor HK Runtime Natively Compiled T-SQL Stored Procedure Storage Engine HK Compile Dynamic Linked Library (DLL) HA HK Engine Max performance Latch and lock free SQLOS © Microsoft Corporation. All rights reserved.

How is this different? Memory I/O Concurrency 6/4/2018 12:26 AM How is this different? Can be controlled with Resource Governor Memory All data stored in memory separate from Buffer Pool No “paging” to disk like Buffer Pool under memory pressure Table data uses different internal structure (no database pages) I/O Transaction logging only at COMMIT Separate checkpoint processing only used to speed startup None required for SCHEMA_ONLY tables Concurrency No locking or latching required Optimistic (conflict error handling may be required) Versioning used (but not stored in tempdb) All data loaded into memory at database startup © Microsoft Corporation. All rights reserved.

6/4/2018 12:26 AM How do I use it? © Microsoft Corporation. All rights reserved.

6/4/2018 12:26 AM The Process Create a Memory Optimized FILEGROUP Decide on an index strategy Create a Memory-Optimized Table Create a natively compiled stored procedure Start running transactions Tune and manage © Microsoft Corporation. All rights reserved.

Decisions Take a look at NVDIMM 6/4/2018 12:26 AM Do I have enough Memory? Estimating Table, Index, Versioning, and Growth. Read here Hash or Non-clustered index? Hash = unique row lookup Non-clustered = range lookups (also called range index) Durability SCHEMA_ONLY = Does not persist server restarts; No I/O (even log) SCHEMA_AND_DATA = Persists server restarts Use Natively Compiled Stored Procedures? Ultimate speed vs some limits Limited diagnostics by default Physical File Placement Transaction Log - Transactions only as fast as commit speed FILEGROUP – One or multiple folders across drives for faster startup Take a look at NVDIMM © Microsoft Corporation. All rights reserved.

Migrating Existing Data 6/4/2018 12:26 AM Migrating Existing Data Transaction Performance Analysis Report Memory Optimization Advisor Native Compilation Advisor Analyze based on DMVs Recommend changes Find incompatibilities Migrate schema, data, and procs © Microsoft Corporation. All rights reserved.

In-Memory OLTP Scenarios 6/4/2018 12:26 AM In-Memory OLTP Scenarios High-throughput and low-latency transaction processing Data Ingestion and IoT Caching and Session State Tired of Tempdb? Staging tables for ETL © Microsoft Corporation. All rights reserved.

Demo: Tempdb vs Memory-Optimized Tables

Management Considerations 6/4/2018 12:26 AM Management Considerations Locks the table Maintain indexes Used to maintain bucketcount for hash indexes Natively Compled Procedures are SCHEMABOUND ALTER memory optimized tables Auto Update statistics supported (requires db compat level = 130) Natively Compiled Stored Procedures not recompiled on auto status update Maintaining Statistics Need to reduce space? Delete rows or drop tables Bind to your own RG resource pool with sp_xtp_bind_db_resource_pool Managing Memory Usage © Microsoft Corporation. All rights reserved.

In-Memory OLTP Capabilities 6/4/2018 12:26 AM In-Memory OLTP Capabilities Supported on Always On Availability Groups Supports ColumnStore Indexes for HTAP applications Supported in Azure SQL Database Cross container transactions (disk and in-memory in one transaction) Table variables supported SQL surface area expanded in SQL Server 2016. Complete support here LOB data types (ex. Varchar(max)) supported BACKUP/RESTORE complete functionality Memory only limited by the OS (24TB in Windows Server 2016) © Microsoft Corporation. All rights reserved.

6/4/2018 12:26 AM How does it work? © Microsoft Corporation. All rights reserved.

Architecture 101 The Hekaton Engine 6/4/2018 12:26 AM Architecture 101 The Hekaton Engine A pool of threads for garbage collection, checkpoint I/O and Log flush Compilation of schema and Natively Compiled Procedure DLLs Engine runtime that is agnostic to table and row formats The HK Engine code is lock, latch, and spinlock free Multi-Version Optimistic Concurrency Pessimistic = locks Immutable Rows never change: UPDATE = DELETE + INSERT Versions UPDATE and DELETE create versions Timestamps in rows for visibility and transactions correctness Optimistic Assume no conflicts Snapshots + conflict detection Guarantee correct transaction isolation at commit NOT in tempdb Errors may occur © Microsoft Corporation. All rights reserved.

The Path of In-Memory OLTP Transactions “Normal” INSERT In-Memory OLTP INSERT Maintain index in memory Insert ROW into memory Release latches and locks Update index pages ( more locks and latch ) Modify page Latch page Obtain locks INSERT LOG record Page Split Sys Tran = Log Flush Spinlocks No latch No spinlock No index logging Notice that log records are not even created until COMMIT. SCHEMA_ONLY no logging COMMIT Transaction = Insert HK Log Record and Flush COMMIT Transaction = Log Record and Flush

CHECKPOINT and Memory Optimized Tables 6/4/2018 12:26 AM CHECKPOINT and Memory Optimized Tables Log truncation eligible at CHECKPOINT event Why CHECKPOINT? Speed up database startup. Otherwise we would have to keep around a huge tlog around. We only write data based on committed log records Independent of SQL recovery intervals or background tasks (1.5Gb log increase) All data written in pairs of data and delta files Preemptive tasks using WriteFile (async with FILE_FLAG_NO_BUFFERING) Data is always appended I/O is continuous but CHECKPOINT event is based on 1.5Gb log growth Instant File Initialization matters for PRECREATED files Data = INSERTs and UPDATEs Delta = filter for what rows in Data are actually deleted Periodically we will MERGE several Data/Delta pairs. No WAL protocol Typically 128Mb but can be 1Gb Typically 8Mb but can be 128Mb Read details from database Boot Page (DBINFO) Load ROOT file for system tables and file metadata Load ACTIVE DATA files filtered by DELTA streamed in parallel Redo COMMITED transactions greater than last CHECKPOINT LSN The Recovery Process = © Microsoft Corporation. All rights reserved.

The Case for In-Memory OLTP 6/4/2018 12:26 AM The Case for In-Memory OLTP Want a 30x boost in speed for OLTP? Transactions are truly lock, latch, and spinlock free Natively complied stored procedures for super speed Combine with Columnstore for true HTAP applications SQL Server 2016 is a major step up from 2014 © Microsoft Corporation. All rights reserved.

Resources SQL Server In-Memory OLTP Internals for SQL Server 2016 6/4/2018 12:26 AM Follow @jdebruijn Resources SQL Server In-Memory OLTP Internals for SQL Server 2016 In-Memory OLTP Videos: What it is and When/How to use it Explore In-Memory OLTP architectures and customer case studies In-Memory OLTP in Azure SQL Database Blog In-Memory OLTP (In-Memory Optimization) docs Inside In-Memory OLTP SQL 2016 PASS Summit talk Decks and demos at http://aka.ms/bobwardms © Microsoft Corporation. All rights reserved.

6/4/2018 12:26 AM © Microsoft Corporation. All rights reserved.