Собственная компиляция таблиц и хранимых процедур
В In-Memory OLTP введено понятие компиляции в собственном коде. SQL Server имеет возможность компиляции в собственном коде хранимых процедур, которые обращаются к оптимизированным для памяти таблицам. SQL Server может также скомпилировать в собственном коде оптимизированные для памяти таблицы. Собственная компиляция обеспечивает более быстрый доступ к данным и более эффективное выполнение запросов, чем интерпретируемый (традиционный) Transact-SQL. Компиляция таблиц и хранимых процедур в собственном коде создает библиотеки DLL.
Кроме того, поддерживается компиляция в собственном коде оптимизированных для памяти табличных типов. Дополнительные сведения см. в статье Memory-Optimized Table Variables.
Компиляцией в собственном коде называется процесс преобразования программных конструкций в машинный код, состоящий из процессорных инструкций, без необходимости их дальнейшей компиляции или интерпретации.
In-Memory OLTP компилирует оптимизированные для памяти таблицы при их создании и скомпилированные в собственном коде хранимые процедуры при их загрузке в собственные библиотеки DLL. Кроме того, библиотеки DLL компилируются повторно после перезапуска базы данных или сервера. Сведения, необходимые для воссоздания библиотек DLL хранятся в метаданных базы данных. Библиотеки DLL не являются частью базы данных, хотя они и связаны с ней. Например, DLL-библиотеки не входят в резервные копии базы данных.
Примечание
Оптимизированные для памяти таблицы во время перезапуска сервера компилируются повторно. Чтобы ускорить восстановление данных, процедуры, скомпилированные в собственном коде, не компилируются повторно во время перезагрузки сервера, а компилируются во время первого выполнения. В результате этой отложенной компиляции скомпилированные в собственном коде хранимые процедуры отображаются только при вызове sys.dm_os_loaded_modules (Transact-SQL) после первого выполнения.
Обслуживание библиотек DLL базы данных In-Memory OLTP
Следующий запрос отображает все библиотеки DLL таблиц и хранимых процедур, загруженных на данный момент в память сервера:
SELECT name, description FROM sys.dm_os_loaded_modules
where description = 'XTP Native DLL'
Администраторам базы данных не нужно хранить файлы, созданные при компиляции в собственном коде. SQL Server автоматически удаляет созданные файлы, которые больше не нужны. Например, созданные файлы будут стерты при удалении таблицы и хранимой процедуры или при удалении базы данных.
Примечание
Если компиляция была прервана или завершилась ошибкой, то некоторые сформированные файлы не будут удалены. Эти файлы оставляются специально для целей поддержки и будут удалены при удалении базы данных.
Примечание
Во время запуска базы данных SQL Server компилирует библиотеки DLL для всех таблиц, необходимых для восстановления базы данных. Если таблица была удалена непосредственно до перезапуска базы данных, остатки таблицы все еще могут оставаться в файлах контрольных точек или журнале транзакций для того, чтобы библиотеки DLL для таблицы можно было перекомпилировать во время запуска базы данных. После перезагрузки компьютера библиотека DLL будет выгружена и удалена в процессе обычной очистки.
Компиляция таблиц в собственном коде
Создание оптимизированной для памяти таблицы с помощью инструкции CREATE TABLE приводит к тому, что табличные данные записываются в метаданные базы данных, а в памяти создаются структуры таблиц и индексов. Таблица также будет скомпилирована в библиотеке DLL.
Рассмотрим следующий пример скрипта, который создает базу данных и оптимизированную для памяти таблицу:
use master
go
create database db1
go
alter database db1 add filegroup db1_mod contains memory_optimized_data
go
-- adapt filename as needed
alter database db1 add file (name='db1_mod', filename='c:\data\db1_mod') to filegroup db1_mod
go
use db1
go
create table dbo.t1
(c1 int not null primary key nonclustered,
c2 INT)
with (memory_optimized=on)
go
-- retrieve the path of the DLL for table t1
select name, description FROM sys.dm_os_loaded_modules
where name like '%xtp_t_' + cast(db_id() as varchar(10)) + '_' + cast(object_id('dbo.t1') as varchar(10)) + '.dll'
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
exec 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\MicrosoftSQL Server\MSSQL12. MSSQLSERVER\MSSQL\Binn\Xtp.
Чтобы ограничить доступ к компилятору, SQL Server использует списки управления доступом (ACL), ограничивающие доступ к двоичным файлам. Все двоичные файлы SQL Server защищены от изменения и несанкционированного доступа через списки управления доступом. Списки управления доступом собственного компилятора также ограничивают использование компилятора; только учетная запись службы SQL Server и администраторы имеют разрешения на чтение и выполнение для файлов собственного компилятора.
Файлы, созданные компиляцией в собственном коде
Файлы, создаваемые при компиляции таблицы хранимой процедуры, включают DLL и промежуточные файлы, в том числе файлы со следующими расширениями: C, OBJ, XML и PDB. Созданные файлы сохраняются во вложенной папке папки данных по умолчанию. Вложенная папка называется Xtp. При установке экземпляра по умолчанию с папкой данных по умолчанию созданные файлы помещаются в папку C:\Program Files\MicrosoftSQL Server\MSSQL12. MSSQLSERVER\MSSQL\DATA\Xtp.
SQL Server предотвращает изменение создаваемых библиотек DLL тремя способами.
Если таблица или хранимая процедура компилируется в DLL, эта DLL немедленно загружается в память и связывается с процессом sqlserver.exe. Библиотеку DLL нельзя изменить, если она связана с процессом.
При перезапуске базы данных перекомпилируются все таблицы и хранимые процедуры (удаленные и воссозданные) на основе метаданных базы данных. При этом удаляются все изменения, внесенные в созданный файл вредоносным агентом.
Созданные файлы считаются частью пользовательских данных и имеют те же ограничения безопасности через списки ACL, что и файлы базы данных: только учетная запись службы SQL Server и системные администраторы имеют доступ к этим файлам.
Взаимодействие с пользователем для управления этими файлами не требуется. SQL Server создает и удаляет файлы по мере необходимости.
См. также:
Таблицы, оптимизированные для памяти
Скомпилированные в собственном коде хранимые процедуры