SQL Server 2014 adds in-memory technology to boost performance of OLTP workloads

CREATE TABLE [Customer]( [CustomerID] INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = ), [Name] NVARCHAR(250) NOT NULL INDEX [IName] HASH WITH (BUCKET_COUNT = ), [CustomerSince] DATETIME NULL ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA); This table is memory optimized This table is durable Secondary Indexes are specified inline Hash Index

CREATE TABLE DDLCode generation and compilationTable DLL producedTable DLL loaded

Array of 8-byte Memory pointers Hash index with (bucket_count=8): Hash function f: Maps values to buckets Built into the system Hash mapping: f(Jane) f(John) f(Susan) f(Prague) f(Bogota), f(Beijing) Hash Collisions

50, ∞ JanePrague TimestampsNameChain ptrsCity Hash index on City Hash index on Name 90, ∞ Susan Bogota f(Jane) f(Susan) f(Prague) f(Bogota)

50, ∞ JanePrague TimestampsNameChain ptrsCity Hash index on City Hash index on Name T100: INSERT (John, Prague) 100, ∞ JohnPrague 90, ∞ Susan Bogota f(John) f(Prague)

90, ∞ Susan Bogota 50, ∞ JanePrague TimestampsNameChain ptrsCity Hash index on City Hash index on Name T150: DELETE (Susan, Bogota) 100, ∞ JohnPrague 90, 150

Susan Bogota 50, ∞ JanePrague TimestampsNameChain ptrsCity Hash index on City Hash index on Name T200: UPDATE (John, Prague) to (John, Beijing) 100, ∞ JohnPrague 200, ∞ JohnBeijing 100, 200 f(Beijing) f(John)

90, 150 Susan Bogota 50, ∞ JanePrague TimestampsNameChain ptrsCity Hash index on City Hash index on Name T250: Garbage collection 100, 200 JohnPrague 200, ∞ JohnBeijing f(John) f(Jane) f(Beijing) f(Prague)

CREATE PROCEDURE DATETIME WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER AS BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = '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 Execution context is required Session settings are fixed at create time

CREATE PROC DDLQuery optimizationCode generation and compilationProcedure DLL producedProcedure DLL loaded

Accessing Memory Optimized Tables Natively Compiled Procs – Access only memory optimized tables – Maximum performance – Limited T-SQL surface area When to use – OLTP-style operations – Optimize performance critical business logic Interpreted T-SQL Access – 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

TimeTransaction T1 (SNAPSHOT)Transaction T2 (SNAPSHOT) 1BEGIN 2 3UPDATE t SET c1=‘value2’ WHERE c2=123 4UPDATE t SET c1=‘value1’ WHERE c2=123 (write conflict) First writer wins

Disk-based tablesMemory-optimized tables Tab1TabnTab1Tabm Regular Tx contextMem-opt Tx context

Disk-basedMemory optimizedUsage recommendations READCOMMITTEDSNAPSHOT Baseline combination – most cases that use READCOMMITTED today READCOMMITTEDREPEATABLEREAD/ SERIALIZABLE Data migration Hekaton-only Interop REPEATABLEREAD/ SERIALIZABLE SNAPSHOT Memory-optimized table access is INSERT-only Useful for data migration and if no concurrent writes on memory-optimized tables (e.g., ETL) Disk-basedMemory optimized SNAPSHOT Any isolation level REPEATABLEREAD/ SERIALIZABLE REPEATABLEREAD/ SERIALIZABLE Supported isolation level combinations (V1) Unsupported isolation level combinations (V1)