In-Memory Optimization and the Buffer Pool Extension in SQL Server 2014
- Overview of In-Memory OLTP
- In-Memory Optimization Requirements
- Limitations of In-Memory OLTP
- Using In-Memory OLTP
- Using Memory-Optimized Tables
- Logging, Checkpoint, and Recovery for In-Memory OLTP
- Managing Memory for In-Memory OLTP
- Backup and Recovery of Memory-Optimized Databases
- Migrating to In-Memory OLTP
- Dynamic Management Views for In-Memory OLTP
- The Buffer Pool Extension
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
With CPU speeds topping out and I/O rates maximized using solid state drives (SSDs), the next available strategy for increasing OLTP performance is through memory optimization. Databases, because of their size, typically reside on disk. Historically, main memory was significantly more expensive than disk, so typically the memory available for caching data was only a fraction of the size of the database. However, with the significantly reduced cost of system memory over the past 20 years, it’s become more financially feasible to install large amounts of memory in the server. It is now possible for most OLTP databases, or at least the most critical tables, to fit entirely into memory which reduces the performance impact of disk-based I/O, which in turn increases transaction speed performance.
To take maximum advantage of the performance improvements that can be achieved from having your critical OLTP tables memory resident, Microsoft developed the In-Memory Optimization feature for SQL Server. In-Memory Optimization, more commonly referred to as In-Memory OLTP, is the primary and most important new feature introduced in SQL Server 2014. This new feature (which you may sometimes hear referred to by its project code name Hekaton) is fully integrated into the SQL Server database engine.
Another feature introduced in SQL Server 2014 to take advantage of the lower costs and increased sizes of SSDs, is the Buffer Pool Extension feature. The Buffer Pool Extension feature provides the ability for SQL Server to use solid-state drives (SSD) as a non-volatile random access memory (NvRAM) to extend the size of the buffer pool. By offloading buffer cache I/Os from mechanical disk to SSDs, the Buffer Pool Extension feature can significantly improve I/O throughput because of the lower latency and better random I/O performance of SSDs.
These exciting new features for SQL Server are discussed in this chapter.
Overview of In-Memory OLTP
In-Memory OLTP allows OLTP workloads to achieve significant improvements in performance, and reduction in processing time. The In-Memory OLTP engine is completely integrated with the SQL Server database engine and can be accessed transparently via your SQL Server applications. However, the In-Memory OLTP components’ internal behavior and capabilities are different and distinct from the standard database engine components as shown in Figure 33.1
)
Figure 33.1 The SQL Server 2014 engine architecture with In-Memory OLTP.
Figure 33.1 shows that client applications connect to SQL Server the same way for memory-optimized tables or disk-based tables, whether it will be calling natively compiled stored procedures or interpreted Transact-SQL. Natively compiled stored procedures can only access memory-optimized tables, but interpreted T-SQL can access tables in either the buffer pool or memory-optimized tables using the interop capabilities. Notice also that memory-optimized tables do not share memory space with on-disk tables. Memory-optimized tables are stored completely differently than disk-based tables and these new data structures allow the data to be accessed and processed much more efficiently.
The main benefit of the SQL Server In-Memory OLTP architecture being integrated into the SQL Server engine is that you don’t have to refactor your entire system to split data between in-memory and conventional on-disk database access, nor move the entire database into memory. You can specify what is stored in-memory or on-disk on a table by table basis. This way you can move only your more active operational tables into memory while keeping other tables and historical data on disk and in some cases, this can be done in a way that’s transparent to your client applications.
In addition to integrating the In-Memory OLTP engine into the SQL Server engine, there were three other primary design goals:
- Optimize data storage for main memory—Data in in-memory tables is not stored on on-disk pages nor does it mimic the on-disk storage structure when loaded into memory, eliminating the complex buffer pool structure and code that manages it. Indexes also are not persisted on disk and instead are recreated on startup when the memory resident tables are loaded into memory.
- Eliminate latches and locks—All in-memory table and index structures are latch and lock free. Instead, SQL Server uses a new optimistic multiversion concurrency control mechanism to provide transaction consistency. The mechanism allows multiple sessions to work with the same data without locking/blocking and improves the stability of the system.
- Compile requests to native code—Standard T-SQL is an interpreter-based language that provides flexibility, but at the cost of increased CPU overhead. The In-Memory OLTP engine avoids this overhead by compiling statements and stored procedures into native machine code.
The new lock-free optimistic multiversion concurrency control mechanism, in conjunction with algorithms that have been optimized for memory-resident data, is one of the key points that differentiates the In-Memory OLTP engine from just pinning tables in memory with DBCC PINTABLE or from putting databases on SSDs. DBCC PINTABLE keeps a table in memory in SQL Server’s buffer pool, but it still uses the same relational engine with locks and latches, so lock and latch contention can still occur, so it doesn’t offer the scalability found in the In-Memory OLTP engine. The same is true for SSDs, which can provide higher I/O but also still use the same relational engine.
In contrast, the In-Memory OLTP engine makes an entirely new version of that row in memory and timestamps it when a row in a shared buffer is modified. The engine then analyzes and validates any updated rows before committing them. Since there are no locks or other wait states, the processing is faster and more scalable than when the traditional locking mechanism is used. However, this optimistic processing creates a lot of different row versions, leaving a number of discarded rows in memory. To handle the discarded row versions, SQL Server runs a new lock-free garbage collection process as part of the In-Memory OLTP engine which periodically cleans up all the unneeded rows.
In addition to the new lock-free design, the In-Memory OLTP engine includes a stored procedure compilation process that compiles T-SQL code into native Win64 code which reduces the number of instructions that the CPU must execute to process the query. The combination of the new query processing engine and the compiled stored procedures are the primary factors driving the high-performance of the In-Memory OLTP engine.
Despite all the promising capabilities of in-memory optimization, there are currently a number of limitations on the technology. This first release of In-Memory OLTP supports only a subset of SQL Server data types and features. Moving some of your tables into in-memory tables may require some changes to your SQL code and table schema. The features supported by In-Memory OLTP and the current limitations will be discussed in more detail later in this chapter.
In-Memory OLTP Concepts and Terminology
The concepts and terminology used to describe the components involved with In-Memory OLTP throughout this chapter include:
- Memory-optimized tables—Tables using the new data structures added as part of In-Memory OLTP. The primary store for memory-optimized tables is main memory, but a second copy in a different format is maintained on disk for durability purposes
- Disk-based tables—Tables that use the data structures that SQL Server has always used, with pages of 8K that need to be read from and written to disk as a unit. Each table also has its own data and index pages.
- Natively compiled stored procedures—The new object type supported by In-Memory OLTP that is compiled into native DLLs. Natively compiled stored procedures have the potential to increase performance even further than just using memory-optimized tables since there is no need for additional compilation and interpretation is reduced compared to standard interpreted Transact-SQL stored procedures. Natively compiled stored procedures can only reference memory-optimized tables.
- Cross-container transactions—Transactions that reference both memory-optimized tables and disk-based tables.
- Durable and nondurable tables—Memory-optimized tables by default are completely durable and offer full ACID support. Nondurable memory-optimized tables are supported by SQL Server but the contents of a nondurable table exist only in memory and are lost when the server restarts. The syntax DURABILITY=SCHEMA_ONLY is used to create nondurable tables.
- Interop—This term refers to interpreted T-SQL statements that reference memory-optimized tables. Interop simplifies migration of your applications to In-Memory OLTP.