Собственная компиляция таблиц и хранимых процедур

Область применения: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

В In-Memory OLTP введено понятие компиляции в собственном коде. SQL Server может скомпилировать хранимые процедуры, которые обращаются к оптимизированным для памяти таблицам. SQL Server также может самостоятельно компилировать оптимизированные для памяти таблицы. Встроенная компиляция позволяет ускорить доступ к данным и более эффективное выполнение запросов, чем интерпретировано (традиционное) Transact-SQL. Компиляция таблиц и хранимых процедур в собственном коде создает библиотеки DLL.

Кроме того, поддерживается компиляция в собственном коде оптимизированных для памяти табличных типов. Дополнительные сведения см. в разделе Улучшение производительности временной таблицы и табличной переменной с помощью оптимизации памяти.

Компиляцией в собственном коде называется процесс преобразования программных конструкций в машинный код, состоящий из процессорных инструкций, без необходимости их дальнейшей компиляции или интерпретации.

In-Memory OLTP компилирует оптимизированные для памяти таблицы при их создании и скомпилированные в собственном коде хранимые процедуры при их загрузке в собственные библиотеки DLL. Кроме того, библиотеки DLL компилируются повторно после перезапуска базы данных или сервера. Сведения, необходимые для воссоздания библиотек DLL хранятся в метаданных базы данных. Библиотеки DLL не являются частью базы данных, хотя они и связаны с ней. Например, DLL-библиотеки не входят в резервные копии базы данных.

Обслуживание библиотек DLL базы данных In-Memory OLTP

Следующий запрос отображает все библиотеки DLL таблиц и хранимых процедур, загруженных на данный момент в память сервера:

SELECT
		mod1.name,
		mod1.description
	from
		sys.dm_os_loaded_modules  as mod1
	where
		mod1.description = 'XTP Native DLL';

Администраторам базы данных не нужно хранить файлы, созданные при компиляции в собственном коде. SQL Server автоматически удаляет созданные файлы, которые больше не нужны. Например, созданные файлы будут стерты при удалении таблицы и хранимой процедуры или при удалении базы данных.

Компиляция таблиц в собственном коде

Создание оптимизированной для памяти таблицы с помощью инструкции CREATE TABLE приводит к тому, что табличные данные записываются в метаданные базы данных, а в памяти создаются структуры таблиц и индексов. Таблица также будет скомпилирована в библиотеке DLL.

Рассмотрим следующий пример скрипта, который создает базу данных и оптимизированную для памяти таблицу:

USE master;
GO

CREATE DATABASE DbMemopt3;
GO

ALTER DATABASE DbMemopt3
	add filegroup DbMemopt3_mod_memopt_1_fg
		contains memory_optimized_data
;
GO

-- You must edit the front portion of filename= path, to where your DATA\ subdirectory is,
-- keeping only the trailing portion '\DATA\DbMemopt3_mod_memopt_1_fn'!

ALTER DATABASE DbMemopt3
	add file
	(
		name     = 'DbMemopt3_mod_memopt_1_name',
		filename = 'C:\DATA\DbMemopt3_mod_memopt_1_fn'

		--filename = 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQLSVR2016ID\MSSQL\DATA\DbMemopt3_mod_memopt_1_fn'
	)
		to filegroup DbMemopt3_mod_memopt_1_fg
;
GO

USE DbMemopt3;
GO

CREATE TABLE dbo.t1
(
	c1 int not null primary key nonclustered,
	c2 int
)
	with (memory_optimized = on)
;
GO



-- You can safely rerun from here to the end.

-- Retrieve the path of the DLL for table t1.


DECLARE @moduleName  nvarchar(256);

SET @moduleName =
	(
		'%xtp_t_' +
		cast(db_id() as nvarchar(16)) +
		'_' +
		cast(object_id('dbo.t1') as nvarchar(16)) +
		'%.dll'
	)
;


-- SEARCHED FOR NAME EXAMPLE:  mod1.name LIKE '%xtp_t_8_565577053%.dll'
PRINT @moduleName;


SELECT
		mod1.name,
		mod1.description
	from
		sys.dm_os_loaded_modules  as mod1
	where
		mod1.name LIKE @moduleName
	order by
		mod1.name
;
-- ACTUAL NAME EXAMPLE:  mod1.name = 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQLSVR2016ID\MSSQL\DATA\xtp\8\xtp_t_8_565577053_184009305855461.dll'
GO

--   DROP DATABASE DbMemopt3;  -- Clean up.
GO

При создании таблицы также формируется и загружается в память библиотека DLL таблицы. Запрос динамического административного представления сразу после выполнения инструкции CREATE TABLE возвращает путь к библиотеке DLL таблицы.

Библиотека DLL таблицы понимает структуры индекса и формат строк таблицы. SQL Server использует библиотеку DLL для обхода индексов, извлечения строк, а также хранения содержимого строк.

Компиляция хранимых процедур в собственном коде

Хранимые процедуры, которые отмечены как NATIVE_COMPILATION, компилируются в собственном коде. Это означает, что инструкции Transact-SQL в процедуре все компилируются в машинный код для эффективного выполнения критически важной бизнес-логики.

Дополнительные сведения о скомпилированных в собственном коде хранимых процедурах см. в разделе Natively Compiled Stored Procedures.

Рассмотрим следующий пример хранимой процедуры, которая вставляет строки в таблицу t1 из предыдущего примера:

CREATE PROCEDURE dbo.native_sp
	with native_compilation,
	     schemabinding,
	     execute as owner
as
begin atomic
	with (transaction isolation level = snapshot,
	      language = N'us_english')

	DECLARE @i int = 1000000;

	WHILE @i > 0
	begin
		INSERT dbo.t1 values (@i, @i+1);
		SET @i -= 1;
	end
end;
GO

EXECUTE dbo.native_sp;
GO

-- Reset.

DELETE from dbo.t1;
GO

Библиотека DLL для native_sp может напрямую взаимодействовать с библиотекой DLL для t1, а также c подсистемой хранилища In-Memory OLTP, чтобы вставлять строки с максимально возможной скоростью.

Компилятор In-Memory OLTP использует оптимизатор запросов для создания эффективного плана выполнения для каждого из запросов в хранимой процедуре. Обратите внимание, что скомпилированные в собственном коде хранимые процедуры не перекомпилируются автоматически при изменении данных в таблице. Дополнительные сведения о сборе статистики и хранимых процедурах в In-Memory OLTP см. в разделе Статистика для таблиц, оптимизированных для памяти.

Вопросы безопасности для компиляции в собственном коде

Компиляция в собственном коде таблиц и хранимых процедур использует компилятор In-Memory OLTP. Этот компилятор создает файлы, которые записываются на диск и загружаются в память. SQL Server использует следующие механизмы для ограничения доступа к этим файлам.

Собственный компилятор

Исполняемый файл компилятора, а также двоичные файлы и файлы заголовков, необходимые для собственной компиляции, устанавливаются в составе экземпляра SQL Server в папке MSSQL\Binn\Xtp. Таким образом, если экземпляр по умолчанию установлен в C:\Program Files, файлы компилятора устанавливаются в C:\Program Files\Microsoft SQL Server\MSSQL13. MSSQLSERVER\MSSQL\Binn\Xtp.

Чтобы ограничить доступ к компилятору, SQL Server использует списки управления доступом (ACL) для ограничения доступа к двоичным файлам. Все двоичные файлы SQL Server защищены от изменения или изменения с помощью списков управления доступом. Списки ACL собственного компилятора также ограничивают использование компилятора; Только у учетной записи службы SQL Server и системных администраторов есть разрешения на чтение и выполнение для собственных файлов компилятора.

Файлы, созданные компиляцией в собственном коде

Файлы, создаваемые при компиляции таблицы хранимой процедуры, включают DLL и промежуточные файлы, в том числе файлы со следующими расширениями: C, OBJ, XML и PDB. Созданные файлы сохраняются во вложенной папке папки данных по умолчанию. Вложенная папка называется Xtp. При установке экземпляра по умолчанию с папкой данных по умолчанию созданные файлы помещаются в папку C:\Program Files\Microsoft SQL Server\MSSQL13. MSSQLSERVER\MSSQL\DATA\Xtp.

SQL Server предотвращает изменение созданных библиотек DLL тремя способами:

• Если таблица или хранимая процедура компилируется в DLL, эта DLL немедленно загружается в память и связывается с процессом sqlserver.exe. Библиотеку DLL нельзя изменить, если она связана с процессом.

• При перезапуске базы данных перекомпилируются все таблицы и хранимые процедуры (удаленные и воссозданные) на основе метаданных базы данных. При этом удаляются все изменения, внесенные в созданный файл вредоносным агентом.

• Созданные файлы считаются частью пользовательских данных и имеют те же ограничения безопасности, что и списки управления доступом, как файлы базы данных: только учетная запись службы SQL Server и системные администраторы могут получить доступ к этим файлам.

Взаимодействие с пользователем для управления этими файлами не требуется. SQL Server создаст и удалите файлы по мере необходимости.

См. также

Таблицы, оптимизированные для памяти

Скомпилированные в собственном коде хранимые процедуры