Applications hitting a wall today with SQL Server Locking/Latching Scale-up Throughput or latency SLA Applications which do not use SQL Server today Key/Value pair where desire relational characteristics Scenarios where previously might not have implemented database in the critical path Common Patterns o High Data Input Rate – “Shock Absorber” o Read Performance and Scale o Compute Heavy Data Processing o Latency critical OLTP o Session State

Implementation Scenario Pattern Characteristics and Challenge Main Benefits of In-Memory OLTP High Data Insert Rate  Primarily append-only store  Inability to ingest write workload  Eliminate contention  Minimize IO logging Read Performance and Scale  High performance read operations  Unable to meet scale-up requirements  Eliminate contention  Efficient data retrieval  Minimize code execution time  CPU efficiency for scale

Implementation Scenario Pattern Characteristics and ChallengeMain Benefits of In-Memory OLTP Compute Heavy Data Processing  Insert/Update/Delete workload  Heavy computation inside database  Read and write contention  Eliminate contention  Minimize code execution time  Efficient data processing Low Latency  Require low latency business transactions  High concurrency exacerbates latency  Eliminate contention  Minimize code execution time  Efficient data retrieval Session State Management  Heavy insert, update, point lookups  User scale under load from multiple stateless web servers  Eliminate contention  Efficient data retrieval  IO reduction/removal

Client Connectivity Query Execution Data Access (Buffer Pool) Transaction Logging Client Connectivity Procedure Execution Data Access (Memory) Transaction Logging No Improvement Same Latency Potentially Less Volume for Durable I/O Eliminated for Non-Durable Traditional Execution StackIn-Memory OLTP Execution Stack Gains 2X to 30X Improvement *Including concurrency gains

SELECT TOP (5) b.name AS TableName, a.database_id, a.singleton_lookup_count, a.range_scan_count FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) AS a INNER JOIN sys.objects b on a.object_id = b.object_id WHERE b.type <> 'S‘ AND (a.singleton_lookup_count > 0 OR a.range_scan_count > 0) ORDER BY a.singleton_lookup_count DESC GO Manual Analysis if MDW is too heavy SELECT TOP (5)a.database_id, so.object_id, so.name AS TableName, a.page_la tch_wait_count, a.page_latch_wait_in_ms, a.page_lock_wait_count, a.page_lock_wait_in_ms FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) a INNER JOIN sys.objects AS so ON a.object_id = so.object_id WHEREso.type = 'U' AND a.page_io_latch_wait_coun t > 0 ORDER BY a.page_latch_wait_count DESC SELECT TOP (10) sp.database_id, so.name AS StoredProcName, sp.total_worker_time, sp.execution_count, sp.total_logical_reads, sp.total_logical_writes, sp.total_logical_reads FROM sys.dm_exec_procedure_stats AS sp INNER JOIN sys.objects AS so ON (sp.object_id = so.object_id) WHEREso.type = 'P' AND sp.database_id = DB_ID() ORD ER BY sp.total_worker_time DESC; T-SQL latch

ostress.exe -S. –E -dAdventureWorks2012 -Q"EXEC =, order_count=100000" – n

Identify bottlenecks in tables Address unsupported constructs and migrate data Perform minimal changes for interpreted access Identify performance critical transaction code Address surface area limitations and migrate code Taking an Iterative Approach to Migration

Memory Size = Table Size + SUM(Index Size) Table Size = Row Size * Row Count Row Size = SUM(Column Sizes) + Row Header Size Row Header Size = * Index Count Column Size = Dependent on column type and associated padding/overhead Hash Index Size = Bucket_Count * 8 bytes Nonclustered Index Size = Row Count * (Key Size + 8) bytes Details available in Books Online

OperationNonclusteredNonclustered Hash Specify Bucket CountNot RequiredRequired Index Scan, retrieve all table rowsSupported Index seek on equality predicate(s) (=) Supported*Performs better than Nonclustered. Predicate must include all columns in hash key, otherwise will result in scan Index seek on inequality predicates (>, =), BETWEEN Performs better than Nonclustered Hash* Will result in scan Retrieve rows in a sort-order matching the index definition SupportedNot Supported Retrieve rows in a sort-order matching the reverse of the index definition Not Supported * Predicate does not need to include all key columns but must include at least leading key columns, otherwise will result in scan

Lack of parallelism can be problematic for some queries Consider trade-off between faster execution (native) vs. parallel operation Joins between memory-optimized table and columnstore can be problematic Statistics creation and updates can be problematic for large tables Requirement of FULLSCAN can take a long time If query has many attributes individual column create stats can have an impact Consider impact of no auto-update statistics For InterOp queries: determining how often and when can affect plans For native procedures: Do data load, execute statistics update, create native compiled procedure A few difficult scenarios to convert to native compiled queries Disjunction (NOT/OR) Outer Join

Interpreted T-SQL Access – Access both memory- and disk-based tables – Less performant – Virtually full T-SQL surface When to use – Ad hoc queries – Surface area not available in native – Compilation at runtime can impact plan (positively) Natively Compiled Procs ‒ Access only memory- optimized tables ‒ Maximum performance ‒ Limited T-SQL surface area When to use ‒ Well defined OLTP-style operations ‒ Optimize performance critical business logic ‒ Query plan unlikely to change based on statistics

Review