Compilação nativa de tabelas e procedimentos armazenados

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

O OLTP na memória apresenta o conceito de compilação nativa. O SQL Server pode compilar nativamente procedimentos armazenados que acessam tabelas com otimização de memória. O SQL Server também pode compilar nativamente tabelas com otimização de memória. A compilação nativa permite o acesso mais rápido a dados e a execução mais eficiente de consultas em comparação com o Transact-SQL interpretado (tradicional). A compilação nativa de tabelas e procedimentos armazenados gera DLLs.

A compilação nativa de tipos de tabelas com otimização de memória também tem suporte. Para obter mais informações, consulte Tabela temporária e variável de tabela mais rápidas usando a otimização de memória.

A compilação nativa refere-se ao processo de converter construções de programação em código nativo, que consiste em instruções de processador, dispensando compilação ou interpretação adicional.

OLTP em memória compila tabelas com otimização de memória quando elas são criadas e procedimentos armazenados compilados nativamente quando são carregados para DLLs nativos. Além disso, as DLLs são recompiladas após a reinicialização de um banco de dados ou servidor. As informações necessárias para recriar as DLLs são armazenadas nos metadados do banco de dados. As DLLs não fazem parte do banco de dados, embora elas estejam associadas ao banco de dados. Por exemplo, as DLLs não são incluídas nos backups de bancos de dados.

Manutenção das DLLs do OLTP na memória

A consulta a seguir mostra todas as DLLs de tabela e procedimento armazenado atualmente carregadas na memória do servidor.

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

Os administradores de banco de dados não precisam manter os arquivos gerados por um compilação nativa. O SQL Server remove automaticamente os arquivos gerados que não são mais necessários. Por exemplo, os arquivos gerados serão excluídos quando uma tabela e um procedimento armazenado forem excluídos, ou se um banco de dados for descartado.

Compilação nativa de tabelas

A criação de uma tabela com otimização de memória usando a instrução CREATE TABLE faz com que as informações da tabela sejam gravadas nos metadados do banco de dados, bem como nas estruturas de tabela e índice criadas na memória. A tabela também será compilada em uma DLL.

Considere o script de exemplo a seguir, que cria um banco de dados e uma tabela com otimização de memória:

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

A criação da tabela também cria a DLL de tabela e a carrega na memória. A consulta DMV imediatamente após a instrução CREATE TABLE recupera o caminho da DLL de tabela.

A DLL de tabela entende as estruturas de índice e o formato da linha da tabela. O SQL Server usa a DLL para percorrer índices, recuperar linhas, além de armazenar o conteúdo das linhas.

Compilação nativa de procedimentos armazenados

Os procedimentos armazenados que são marcados com NATIVE_COMPILATION são compilados nativamente. Isso significa que as instruções Transact-SQL no procedimento são todas compiladas em código nativo para a execução eficiente da lógica de negócios crítica para o desempenho.

Para obter mais informações sobre procedimentos armazenados nativamente compilados, consulte Natively Compiled Stored Procedures.

Considere o procedimento armazenado do exemplo a seguir, que insere linhas na tabela t1 do exemplo anterior:

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

A DLL para native_sp pode interagir diretamente com a DLL para t1, bem como com o mecanismo de armazenamento do OLTP na memória, para inserir as linhas o mais rápido possível.

O compilador do OLTP na memória aproveita o otimizador de consulta para criar um plano de execução eficiente para cada uma das consultas no procedimento armazenado. Observe que os procedimentos armazenados compilados nativamente serão recompilados automaticamente se os dados na tabela forem alterados. Para obter mais informações sobre como manter estatísticas e procedimentos armazenados com OLTP in-memory, consulte Estatísticas para tabelas com otimização de memória.

Considerações de segurança para compilação nativa

A compilação nativa de tabelas e procedimentos armazenados usa o compilador OLTP na memória. Esse compilador gera arquivos que são gravados no disco e carregados na memória. O SQL Server usa os mecanismos a seguir para limitar o acesso a esses arquivos.

Compilador nativo

O executável do compilador, além dos binários e arquivos de cabeçalho necessários para a compilação nativa, são instalados como parte da instância do SQL Server na pasta MSSQL\Binn\Xtp. Portanto, se a instância padrão for instalada em C:\Arquivos de Programas, os arquivos do compilador serão instalados em C:\Arquivos de Programas\MSSQL13.MSSQLSERVER\MSSQL\Binn\Xtp.

Para limitar o acesso ao compilador, o SQL Server usa ACLs (listas de controle de acesso) para restringir o acesso a arquivos binários. Todos os binários do SQL Server são protegidos contra modificações ou violação por meio de ACLs. As ACLs do compilador nativo também limitam o uso do compilador; somente os administradores do sistema e da conta do serviço SQL Server têm permissões de leitura e execução para arquivos do compilador nativo.

Arquivos gerados por uma compilação nativa

Os arquivos gerados quando uma tabela ou um procedimento armazenado é compilado são arquivos DLL e intermediários que incluem arquivos com as seguintes extensões: .c, .obj, .xml, e .pdb. Os arquivos gerados são salvos em uma subpasta da pasta de dados padrão. A subpasta é chamada Xtp. Ao instalar a instância padrão com a pasta de dados padrão, os arquivos gerados são colocados em C:\Arquivos de Programas\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\Xtp.

O SQL Server evita a violação das DLLs geradas de três maneiras:

• Quando uma tabela ou um procedimento armazenado é compilado em uma DLL, esta é carregada imediatamente na memória e vinculada ao processo do sqlserver.exe. Uma DLL não pode ser modificada enquanto está vinculada a um processo.

• Quando um banco de dados é reinicializado, todas as tabelas e procedimentos armazenados são recompilados (removidos e recriados) com base nos metadados do banco de dados. Isso removerá todas as alterações feitas em um arquivo gerado por um agente mal-intencionado.

• Os arquivos gerados são considerados parte dos dados do usuário e têm as mesmas restrições de segurança, por meio de ACLs, que os arquivos de banco de dados: somente os administradores do sistema e da conta do serviço SQL Server podem acessar estes arquivos.

Nenhuma interação do usuário é necessária para gerenciar esses arquivos. O SQL Server criará e removerá os arquivos conforme necessário.

Confira também

Tabelas com otimização de memória

Procedimentos armazenados compilados nativamente