Compilação nativa de tabelas e procedimentos armazenados

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure

O processamento de transações online em memória (OLTP) utiliza compilação nativa para proporcionar acesso mais rápido aos dados e uma execução de consultas mais eficiente do que o Transact-SQL interpretado (tradicional). A compilação nativa de tabelas e procedimentos armazenados produz bibliotecas de ligação dinâmica (DLLs).

O Mecanismo de Banco de Dados do SQL Server pode compilar nativamente tabelas otimizadas para memória, procedimentos armazenados que acedem a tabelas otimizadas para memória e tipos de tabelas otimizadas para memória. Para obter mais informações, consulte Tabela temporária e variável de tabela mais rápidas, utilizando a otimização de memória.

O OLTP em memória compila tabelas otimizadas para memória quando as cria, e compila nativamente os procedimentos armazenados em DLLs nativas quando são carregadas. Além disso, as DLLs são recompiladas após um reinício da base de dados ou do servidor. A base de dados armazena a informação necessária para recriar as DLLs nos metadados. As DLLs não fazem parte da base de dados, embora estejam associadas à base de dados. Por exemplo, as DLLs não estão incluídas nas cópias de segurança da base de dados.

Manutenção de DLLs OLTP em memória

A consulta seguinte mostra todas as DLLs de tabelas e procedimentos armazenados 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 bases de dados não precisam de manter ficheiros gerados por compilação nativa. O Database Engine remove automaticamente os ficheiros gerados que já não são necessários. Por exemplo, os ficheiros gerados são eliminados quando uma tabela e um procedimento armazenado são eliminados, ou se uma base de dados é descartada.

O Database Engine compila DLLs para todas as tabelas necessárias para a recuperação da base de dados. Se uma tabela for descartada mesmo antes de um reinício da base de dados, podem existir vestígios da tabela nos ficheiros de checkpoint ou no registo de transações. Como resultado, a DLL da tabela pode ser recompilada durante o arranque da base de dados. Se este processo ocorrer após o reinício da base de dados, o processo normal de limpeza descarrega a DLL e remove os ficheiros.

Compilação nativa de tabelas

Quando cria uma tabela otimizada para memória usando a CREATE TABLE instrução, a informação da tabela é escrita nos metadados da base de dados, e as estruturas de tabela e índice são criadas na memória. A tabela é então compilada para uma DLL.

O script de exemplo seguinte cria uma base de dados e uma tabela otimizada para memória. Certifica-te de que defines o FILENAME caminho para onde está o teu DATA subdiretório.

USE master;
GO

CREATE DATABASE DbMemOpt3;
GO

ALTER DATABASE DbMemOpt3
ADD FILEGROUP DbMemOpt3_mod_memopt_1_fg
    CONTAINS MEMORY_OPTIMIZED_DATA;
GO

-- Change the FILENAME path to where your DATA subdirectory is located,
-- 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'
)
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

-- Retrieve the path of the DLL for table t1.
DECLARE @moduleName AS NVARCHAR (256);

SET @moduleName = ('%xtp_t_'
    + CAST (db_id() AS NVARCHAR (16))
    + '_' + CAST (object_id('dbo.t1') AS NVARCHAR (16))
    + '%.dll');

-- Search for the name: 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;
GO

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

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

A DLL da tabela compreende as estruturas de índice e o formato de linha da tabela. O Database Engine utiliza a DLL para percorrer índices, recuperar linhas e armazenar o conteúdo das linhas.

Compilação nativa de procedimentos armazenados

Marque os procedimentos armazenados com NATIVE_COMPILATION para os compilar nativamente. As instruções Transact-SQL no procedimento são todas compiladas para código nativo, para uma execução eficiente da lógica de negócio crítica em termos de desempenho.

Para mais informações sobre procedimentos armazenados compilados nativamente, consulte Guia de Processamento de Consultas para Tabelas Otimizadas para Memória.

O seguinte exemplo de procedimento armazenado 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 AS 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 dbo.t1;
GO

A DLL para native_sp pode interagir diretamente com a DLL de t1, e com o motor de armazenamento OLTP em memória, para inserir as linhas o mais rapidamente possível. O otimizador de consultas cria um plano de execução eficiente para cada uma das consultas no procedimento armazenado.

Procedimentos armazenados compilados nativamente não são automaticamente recompilados se os dados na tabela mudarem. Para mais informações sobre a manutenção de estatísticas e procedimentos armazenados com OLTP na memória, consulte Estatísticas para Tabelas Otimizadas para Memória.

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

A compilação nativa de tabelas e procedimentos armazenados utiliza o compilador OLTP em memória. O compilador produz ficheiros que são escritos no disco e carregados na memória. O Database Engine utiliza os seguintes mecanismos para limitar o acesso a estes ficheiros.

Compilador

O executável do compilador, binários e ficheiros de cabeçalho necessários para compilação nativa são instalados como parte da instância Database Engine, na pasta MSSQL\Binn\Xtp. Se instalar a instância padrão em C:\Program Files, os ficheiros do compilador estão em C:\Program Files\Microsoft SQL Server\MSSQL\<version>.MSSQLSERVER\MSSQL\Binn\Xtp.

Para limitar o acesso ao compilador, o Database Engine utiliza listas de controlo de acesso (ACLs) para restringir o acesso a ficheiros binários. As ACLs protegem todos os binários do Database Engine contra modificação ou adulteração. As ACLs do compilador nativo também limitam o uso do compilador; apenas a conta de serviço do Database Engine e os administradores de sistema têm permissões de leitura e execução para ficheiros nativos do compilador.

Ficheiros gerados por uma compilação nativa

Os ficheiros produzidos quando uma tabela ou procedimento armazenado é compilado incluem os ficheiros DLL e intermédios, incluindo ficheiros com as seguintes extensões: .c, .obj, .xml, e .pdb. Os ficheiros gerados são guardados na xtp subpasta da pasta de dados padrão definida como InstanceDefaultDataPath no SERVERPROPERTY. Um exemplo de caminho de ficheiro é: C:\Program Files\Microsoft SQL Server\MSSQL\<version>.MSSQLSERVER\MSSQL\DATA\Xtp.

O Database Engine previne a manipulação das DLLs geradas de três formas:

• Quando uma tabela ou procedimento armazenado é compilado para uma DLL, a DLL é imediatamente carregada na memória e ligada ao sqlserver.exe processo. Não podes modificar uma DLL enquanto está ligada a um processo.

• Quando uma base de dados reinicia, todas as tabelas e procedimentos armazenados são recompilados (ou seja, removidos e recriados) a partir dos metadados da base de dados, com os procedimentos armazenados compilados na primeira execução. A recompilação descarta quaisquer alterações feitas a um ficheiro gerado, como adulteração por um agente malicioso.

• Os ficheiros gerados são tratados como dados de utilizador e têm as mesmas restrições de segurança, via ACLs, que os ficheiros de base de dados. Apenas a conta de serviço do Database Engine e os administradores do sistema podem aceder a estes ficheiros.

Não precisas de gerir estes ficheiros. O Database Engine cria e remove os ficheiros conforme necessário.

Conteúdo relacionado

• Base de dados de exemplo para OLTP em memória
• Um Guia para o Processamento de Consultas para Tabelas Otimizadas para Memória