Compilation en mode natif de tables et de procédures stockées
S’applique à :
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
L'OLTP en mémoire introduit le concept de compilation native. SQL Server peut compiler en mode natif des procédures stockées qui accèdent aux tables optimisées en mémoire. SQL Server est également en mesure de compiler en mode natif des tables optimisées en mémoire. La compilation native permet un accès aux données plus rapide et une exécution de requête plus efficace que Transact-SQL interprétée (traditionnelle). La compilation en mode natif de tables et de procédures stockées produit des DLL.
La compilation en mode natif des types de table optimisée en mémoire est également prise en charge. Pour plus d’informations, consultez Table temporaire et variable de table plus rapides à l’aide de l’optimisation de la mémoire.
La compilation native fait référence au processus de conversion des constructions de programmation en code natif, constitué d'instructions de processeur, sans recourir à une compilation ou une interprétation supplémentaire.
L'OLTP en mémoire compile les tables optimisées en mémoire quand elles sont créées, ainsi que les procédures stockées compilées en mode natif au moment de leur chargement dans des DLL natives. En outre, les DLL sont recompilées au redémarrage de la base de données ou du serveur. Les informations nécessaires pour recréer les DLL sont stockées dans les métadonnées de la base de données. Les DLL ne font pas partie de la base de données, bien qu'elles lui soient associées. Par exemple, les DLL ne sont pas incluses dans les sauvegardes de base de données.
Note
Les tables optimisées en mémoire sont recompilées lors d'un redémarrage du serveur. Pour accélérer la récupération de la base de données, les procédures stockées compilées en mode natif ne sont pas recompilées lors d'un redémarrage du serveur. Elles sont compilées au moment de la première exécution. À la suite de cette compilation différée, les procédures stockées compilées en mode natif s’affichent uniquement lors de l’appel de sys.dm_os_loaded_modules (Transact-SQL) après la première exécution.
Maintenance des DLL de l'OLTP en mémoire
La requête suivante affiche toutes les DLL de tables et de procédures stockées ayant été chargées en mémoire sur le serveur :
SELECT
mod1.name,
mod1.description
from
sys.dm_os_loaded_modules as mod1
where
mod1.description = 'XTP Native DLL';
Les administrateurs de base de données n'ont pas besoin de conserver les fichiers générés par la compilation native. SQL Server supprime automatiquement les fichiers générés qui ne sont plus nécessaires. Par exemple, les fichiers générés sont supprimés lorsque vous supprimez une table et une procédure stockée, ou si vous supprimez une base de données.
Note
Si la compilation échoue ou est interrompue, certains fichiers générés ne sont pas supprimés. Ces fichiers sont intentionnellement conservés pour la prise en charge et sont supprimés lorsque la base de données est supprimée.
Note
SQL Server compile les DLL de toutes les tables nécessaires à la récupération de la base de données. Si une table a été supprimée juste avant un redémarrage de la base de données, il peut y avoir des restes de la table dans les fichiers de point de contrôle ou dans le journal des transactions : la DLL de la table doit alors être recompilée lors du démarrage de la base de données. Après le redémarrage, la DLL est déchargée et les fichiers supprimés par le processus de nettoyage normal.
Compilation native des tables
La création d’une table optimisée en mémoire à l’aide de l’instruction CREATE TABLE entraîne l’écriture des informations de la table dans les métadonnées de la base de données et la création des structures de table et d’index en mémoire. La table sera également compilée dans une DLL.
Consultez l'exemple de script suivant, qui crée une base de données et une table optimisée en mémoire :
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
La création de la table crée également la DLL de table et charge la DLL dans la mémoire. Une requête DMV exécutée immédiatement après l'instruction CREATE TABLE récupère le chemin d'accès de la DLL de table.
La DLL de table comprend les structures d'index et le format de ligne de la table. SQL Server utilise la DLL pour parcourir les index, récupérer des lignes, ainsi que stocker le contenu des lignes.
Procédures stockées compilées en mode natif
Les procédures stockées qui sont identifiées par NATIVE_COMPILATION sont compilées en mode natif. Cela signifie que les instructions Transact-SQL de la procédure sont toutes compilées en code natif pour une exécution efficace de la logique métier critique pour les performances.
Pour plus d'informations sur les procédures stockées compilées en mode natif, consultez Natively Compiled Stored Procedures.
Prenons l'exemple de procédure stockée suivant, qui insère des lignes dans la table t1 de l'exemple précédent :
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
La DLL de native_sp peut interagir directement avec la DLL de t1, ainsi que le moteur de stockage de l'OLTP en mémoire, pour insérer les lignes le plus rapidement possible.
Le compilateur de l'OLTP en mémoire tire parti de l'optimiseur de requête pour créer un plan d'exécution efficace pour chacune des requêtes dans la procédure stockée. Notez que les procédures stockées compilées en mode natif ne sont pas automatiquement recompilées si les données de la table sont modifiées. Pour plus d’informations sur la gestion des statistiques et des procédures stockées avec l’OLTP en mémoire, consultez Statistiques pour les tables mémoire optimisées.
Considérations sur la sécurité à prendre en compte pour une compilation native
La compilation native des tables et des procédures stockées utilise le compilateur de l'OLTP en mémoire. Ce compilateur génère des fichiers qui sont écrits sur le disque et chargés en mémoire. SQL Server utilise les mécanismes suivants pour limiter l’accès à ces fichiers.
Compilateur natif
L’exécutable du compilateur, ainsi que les fichiers binaires et les fichiers d’en-tête requis pour la compilation native, sont installés dans le cadre de l’instance SQL Server sous le dossier MSSQL\Binn\Xtp. Par conséquent, si l’instance par défaut est installée sous C:\Program Files, les fichiers du compilateur sont installés dans C:\Program Files\Microsoft SQL Server\MSSQL13. MSSQLSERVER\MSSQL\Binn\Xtp.
Pour limiter l’accès au compilateur, SQL Server utilise des listes de contrôle d’accès (ACL) pour restreindre l’accès aux fichiers binaires. Tous les fichiers binaires SQL Server sont protégés contre la modification ou la falsification par le biais d’ACL. Les listes de contrôle d’accès du compilateur natif limitent également l’utilisation du compilateur ; Seuls les comptes de service SQL Server et les administrateurs système disposent d’autorisations de lecture et d’exécution pour les fichiers compilateur natifs.
Fichiers générés par une compilation native
Les fichiers créés lorsqu'une table ou une procédure stockée est compilée sont les fichiers DLL et les fichiers intermédiaires, notamment les fichiers portant les extensions suivantes : .c, .obj, .xml et .pdb. Les fichiers générés sont enregistrés dans un sous-dossier du dossier de données par défaut. Le sous-dossier est appelé Xtp. Lors de l’installation de l’instance par défaut avec le dossier de données par défaut, les fichiers générés sont placés dans C:\Program Files\Microsoft SQL Server\MSSQL13. MSSQLSERVER\MSSQL\DATA\Xtp.
SQL Server empêche la falsification des DLL générées de trois façons :
Lorsqu'une table ou une procédure stockée est compilée dans une DLL, cette DLL est immédiatement chargée en mémoire et liée au processus sqlserver.exe. Un fichier DLL ne peut pas être modifié lorsqu'il est lié à un processus.
Lorsqu'une base de données redémarre, toutes les tables et les procédures stockées sont recompilées (supprimées et recréés) en fonction des métadonnées de la base de données. Ceci entraîne la suppression des éventuelles modifications apportées à un fichier généré par un agent malveillant.
Les fichiers générés sont considérés comme faisant partie des données utilisateur et ont les mêmes restrictions de sécurité, via les listes de contrôle d’accès, que les fichiers de base de données : seul le compte de service SQL Server et les administrateurs système peuvent accéder à ces fichiers.
Aucune intervention de l'utilisateur n'est nécessaire pour gérer ces fichiers. SQL Server crée et supprime les fichiers si nécessaire.
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour