1. Redmond Protocols Plugfest 2016 Jos de Bruijn, Borko Novakovic SQL In-Memory OLTP Senior Program Manager

2. Agenda Overview and Value Proposition In-Memory OLTP Architecture and Features Recent Enhancements Azure DB Offering

3. Analysis Services In-Memory In-Memory Analytics ColumnStore (NCCI) PowerPivot In-Memory for Excel The journey to complete in-memory PowerPivot In-Memory for Excel 2012 SQL Server 2008 R2 SQL Server +In-Memory Analytics ColumnStore (CCI) In-Memory OLTP Analysis Services In-Memory PowerPivot In-Memory for Excel 2014 SQL Server +Real-Time Operational Analytics In-Memory OLTP Analysis Services In-Memory (10x faster) PowerPivot In-Memory for Excel Azure SQL DB and Azure SQL DW 2016 SQL Server

4. SQL In-Memory Technologies Over 100x query speed and significant data compression with In-Memory ColumnStore Up to 30x faster transaction processing with In-Memory OLTP Faster Analytics Faster Transactions + IN-MEMORY OLTP IN-MEMORY DW + Using the same tables In 2016 and Azure DB SQL Real-Time Analytics

5. Hardware Trends Multi-Core Explosion 32 cores per socket and beyond on H/w roadmap Multiple levels of cache: latencies from caches and memory a problem Individual cores not getting dramatically faster Memory sizes growing More affordable to keep working set in memory Storage hierarchy changing dramatically (PCIe) SSDs are mainstream NVRAMs on the horizon

6. Database Design For Next-Gen H/W Special-purpose DB “Engines” designed for particular scenarios Give 100x performance over general purpose DBs Careful layout of data structures in memory Eliminate redundant code paths Techniques specialized to particular scenarios: Analytics & DW: batch execution of queries over compressed data, exploiting duplication of data over large sets, hyper optimized inner loops OLTP: eliminating concurrency control overhead, compiled code, very efficient end-to-end stack

7. Customer demand for ever higher concurrency and lower latency, at a lower cost Hardware trends demand architectural changes on RDBMS to meet those demands In-memory OLTP is: High performance, Memory-optimized OLTP engine, Integrated into SQL Server and Architected for modern hardware Why In-Memory OLTP 7

8. SQL Server In-Memory OLTP In-Memory OLTP Optimized for OLTP workloads Memory-optimized data structures for efficient data access Lock/Latch free access for linear scaling Native Compilation of T-SQL Modules for efficient execution Fully integrated into SQL Server No new license or product Familiar tools Integrated Security and High Availability No/Limited Application Changes Available in SQL Server and Azure SQL DB Performance numbers Up to 30X performance improvement compared with traditional tables and stored procs Actual gain depends on app pattern; typical gains: 2X-10X Perf numbers in testing (4S server): 10M rows ingested per second 1GB/s of log generation 260K transactions per second for order processing workload (most transactions are mixed read/write) bwin.party experiences with ASP.NET session state Consolidate 18 servers -> 1 in production 1M requests/sec in testing

9. High throughput OLTP with low latency requirements E.g., financial trading, gaming Shock-absorber and data load (high data ingestion rate) Memory-optimized table as “buffer”, with offload to clustered columnstore Remove mid-tier caching Session state and relational cache E.g., ASP.NET session state Tempdb replacement Memory-optimized table-valued parameters (TVPs) Memory-only (SCHEMA_ONLY) tables to replace temp tables ETL Use SCHEMA_ONLY staging tables In-Memory OLTP Scenarios

10. In-Memory OLTP Perf Gain Demo

11. Architecture and Features

12. In-Memory OLTP Architectural Pillars SQL Server Integration Same manageability, administration & development experience Integrated queries & transactions Integrated HA and backup/restore Main-Memory Optimized Direct pointers to rows Indexes exist only in memory No buffer pool No write-ahead logging Stream-based storage Non-Blocking Execution Multi-version optimistic concurrency control, full ACID support Lock-free data structures No locks, latches or spinlocks, No I/O in transaction T-SQL Compiled to Native Machine Code T-SQL compiled to machine code leveraging VC compiler Procedure and its queries, becomes a C function Aggressive compile-time optimizations Architectural Pillars Results Hybrid engine and integrated experience In-memory cache speed with capabilities of a database Transactions execute to completion without blocking Queries & business logic run at native- code speed Principl es Performance- critical data fits in memory Conflicts are Rare Push decisions to compilation time Built-In

13. Create Table DDL 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 INDEX [ICustomerID-Since] NONCLUSTERED (CustomerID, CustomerSince) ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA); This table is memory optimized This table is durable. Non-durable tables: DURABILITY=SCHEMA_ONLY Indexes may be specified inline NONCLUSTERED indexes are supported Hash Index BUCKET_COUNT Use 2x # of unique index key values Multi-Column indexes are supported

14. Create Table Type DDL CREATE TYPE [Sales].[SalesOrderDetailType_inmem] AS TABLE( [OrderQty] [smallint] NOT NULL, [ProductID] [int] NOT NULL, [SpecialOfferID] [int] NOT NULL, INDEX [IX_ProductID] NONCLUSTERED HASH ([ProductID]) WITH ( BUCKET_COUNT = 8) ) WITH ( MEMORY_OPTIMIZED = ON )

15. Create Procedure DDL CREATE PROCEDURE [dbo].[InsertOrder] @id INT, @date DATETIME WITH NATIVE_COMPILATION, SCHEMABINDING AS BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english') -- insert T-SQL here END This proc is natively compiled Native procs must be schema-bound Atomic blocks Create a transaction if there is none Otherwise, create a savepoint

16. Create Function DDL CREATE FUNCTION [dbo].[ufnGetAccountingEndDate_native]() RETURNS [datetime] WITH NATIVE_COMPILATION, SCHEMABINDING AS BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL=SNAPSHOT, LANGUAGE=N'us_english') RETURN DATEADD(millisecond, -2, CONVERT(datetime, '20160701', 112)); END

17. Durability and Availability Full durability is default Every commit results in write to transaction log Delayed durability and non-durable are available Delayed durability: flush to disk is async for low latency; limited data loss possible Non-durable tables: exist only in memory; for transient data and relational cache High-availability and disaster recovery fully integrated AlwaysOn AGs, readable secondaries, FCI, log shipping fully supported Backup/restore fully integrated Checkpoint is incremental for performance reasons

18. Recent Improvements

19. Throughput: Sustained log generation rate 1GB/s Numerous improvements under the hood Persisted Main Memory for Tail of the Log Parallel plans and parallel scan of memory-optimized tables and indexes Heap scan Performance improvements

20. Programmability improvements Tables Collations: Full collations support in index key columns All code pages supported for (var)char columns Constraints FOREIGN KEY CHECK UNIQUE constraints and indexes LOB types: [n]varchar(max) and varbinary(max) Row size >8060 bytes NULLable index key columns DML triggers on memory-optimized tables (AFTER) Row-Level Security Always Encrypted Temporal Tables (history lives on-disk) Native Compilation Full collations support in native modules Query surface area {LEFT|RIGHT} OUTER JOIN Disjunction (OR, NOT) UNION [ALL] SELECT DISTINCT Subqueries (EXISTS, IN, scalar) Nested Stored procedures (EXECUTE) Natively Compiled Scalar UDFs Access from both native and interop Improves perf of scalar UDFs in traditional workload if no table access is required Natively Compiled Inline TVFs EXECUTE AS CALLER Query Store

21. Manageability improvements Improved SSMS experience Lightweight Performance Analysis in SSMS Generate migration checklists to evaluate all tables/procedures for migration ALTER support for procedures and tables Full ALTER TABLE/PROCEDURE support Index management through ALTER TABLE … ADD/ALTER/DROP INDEX Limitation: ALTER TABLE offline for now; ALTER of 10GB table takes 1.5 minutes No ALTER between disk-based and memory-optimized TDE (Transparent Data Encryption) All on-disk data files are now encrypted once TDE is enabled Stats improvements: auto-update and sampled stats Statistics management is not on par with disk-based tables

22. In-Memory OLTP - Remaining Unsupported Features Tables DDL triggers and Transactional DDL Data types: XML, Spatial, CLR types, datetimeoffset, rowversion, sql_variant ALTER TABLE ONLINE; sp_rename Cross-container transaction limitations: snapshot/snapshot, serializable/serializable; SAVEPOINT Online Migration of disk-based tables to memory-optimized Interop: cross-database queries, MERGE INTO, locking hints Native Compilation CASE, MERGE, JOIN in UPDATE/DELETE; VIEWs Natively Compiled Table-Valued Functions Automatic and statement-level recompile Access to disk-based tables Must be schema-bound; no dynamic T-SQL Parallelism; limitations in query operators (hash join/agg, merge join) Management: replication; DB snapshot; CDC; compression; remove filegroup

23. In-Memory OLTP in Azure SQL Database

24. In-Memory OLTP for Azure SQL DB In Public Preview for new Premium databases No need to manage filegroup or resource pool In-Memory storage size: P1 – 1GB; P2 – 2GB; P4 – 4GB; P6 – 8GB; P11 – 14GB Full In-Memory OLTP Surface Area Memory-optimized tables and table types Natively compiled stored procedures and scalar UDFs New features are released to Azure SQL DB as soon as they are completed Planned for GA (H2 2016): Existing databases Basic/Standard support Elastic pools

25. Resources Samples Perf demo SQL 2014 Sample Azure DB Sample Documentation Blog on In-Memory OLTP in SQL 2016 MSDN Documentation for In-Memory OLTP Azure DB documentation for In-Memory What’s new in SQL2016 Migrating apps In-Memory OLTP Common Workloads and Migration Considerations Migrating to In-Memory OLTP Guidelines for using Indexes Related videos Microsoft Virtual Academy talks Recent investments in In-Memory OLTP

26. Redmond Protocols Plugfest 2016 Questions or Comments? jodebrui@microsoft.com

27. Redmond Protocols Plugfest 2016 Thank You!