Database Reference
In-Depth Information
The situation is far more complicated in the case of memory-optimized tables and natively-compiled code. It is
easy to generate a new version of the DLL that knows about new data column; however, that is not enough. The DLL
needs to handle different versions of rows and different data formats depending on the presence of column data.
While this is technically possible, it adds extra logic to the DLL, which leads to additional processing instructions,
which slows data access. Moreover, the logic to support multiple data formats would remain in the code forever,
degrading performance even further with each table alteration.
The only way to address this problem is to convert all existing data rows into the new format. This is a very
complex and time-consuming operation that requires exclusive access to a table for its duration. Such a condition
would introduce the concept of locking in the in-memory OLTP engine, which violates its design goals and, therefore,
table alteration is not supported in in-memory OLTP.
■
technically speaking, the requirement of locking could be avoided if the alteration runs in a
SINGLE_USER
database mode. however, if the database can be switched to a
SINGLE_USER
mode, you can work around the restriction
by creating another table with the new structure, copying the data there, dropping the old table and renaming the new
table afterwards. Keep in mind, however, that the server should have enough memory to accommodate data from both
tables during this process.
Note
To reduce the overhead of T-SQL interpretation even further, the in-memory OLTP engine allows you to perform
native compilation of the stored procedures. Those stored procedures are compiled in the same way as table-related
DLLs and are also loaded to SQL Server process memory. We will discuss natively-compiled stored procedures in
greater detail later in the chapter.
Native compilation utilizes both the SQL Server and in-memory OLTP engines. As a first step, SQL Server parses
the T-SQL code and, in the case of stored procedures, it generates an execution plan using Query Optimizer. At the
end of this stage, SQL Server generates a structure called
MAT (Mixed Abstract Tree)
, which represents metadata,
imperative logic, expressions, and query plans.
As a next step, in-memory OLTP transforms MAT to another structure called
PIT (Pure Imperative Tree),
which is
used to generate source code that is compiled and linked into the DLL.
Figure
33-1
illustrates the process of native compilation in SQL Server.
