Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Avec seulement quelques exceptions, vous pouvez accéder à des tables optimisées en mémoire à l’aide de n’importe quelle Transact-SQL requête ou opération DML (SELECT, INSERT, UPDATE ou DELETE), des lots ad hoc et des modules SQL tels que des procédures stockées, des fonctions table, des déclencheurs et des vues.
L'Transact-SQL interprété fait référence à Transact-SQL lots ou procédures stockées autres qu’une procédure stockée compilée en mode natif. L'accès Transact-SQL aux tables optimisées en mémoire est désigné sous le nom d'accès interopérable.
Les tables optimisées en mémoire sont également accessibles à l’aide d’une procédure stockée compilée en mode natif. Les procédures stockées compilées en mode natif sont recommandées pour les opérations OLTP critiques sur les performances.
L’accès Transact-SQL interprété est recommandé pour les scénarios suivants :
Requêtes ad hoc et tâches administratives.
Requêtes de création de rapports, qui utilisent généralement des constructions non disponibles dans les procédures stockées compilées en mode natif (telles que les fonctions de fenêtre).
Pour migrer des parties critiques des performances de votre application vers des tables mémoire optimisées, avec des modifications minimales (ou aucune) du code d’application. Vous pouvez potentiellement constater des améliorations de performance dues à la migration de tables. Si vous migrez ensuite des procédures stockées vers des procédures stockées compilées en mode natif, vous pouvez constater une amélioration supplémentaire des performances.
Lorsqu’une instruction Transact-SQL n’est pas disponible pour les procédures stockées compilées en mode natif.
Les constructions de Transact-SQL suivantes ne sont pas prises en charge dans les procédures stockées Transact-SQL interprétées qui accèdent aux données d’une table optimisée pour la mémoire.
| Domaine | Non pris en charge |
|---|---|
| Accès aux tables | TRONQUER LA TABLE MERGE (table optimisée en mémoire utilisée comme cible) Curseurs dynamiques et de jeu de clés (ceux-ci se dégradent automatiquement en statiques). Accès à partir de modules CLR via la connexion de contexte. Référencement d’une table optimisée en mémoire à partir d’une vue indexée. |
| Base de données croisée | Requêtes entre plusieurs bases de données Transactions entre bases de données Serveurs liés |
Indicateurs de table
Pour plus d’informations sur les indicateurs de table, consultez la documentation. Indicateurs de table (Transact-SQL). L’isolation SNAPSHOT a été ajoutée pour prendre en charge In-Memory OLTP.
Les indicateurs de tableau suivants ne sont pas pris en charge lors de l’accès à une table optimisée en mémoire à l’aide de Transact-SQL interprété.
| HOLDLOCK | IGNORE_CONSTRAINTS | IGNORE_TRIGGERS | NOWAIT |
| PAGLOCK | READCOMMITTED | READCOMMITTEDLOCK | READPAST |
| READUNCOMMITTED | TOLET | SPATIAL_WINDOW_MAX_CELLS = entier | TABLOCK |
| TABLOCKXX | UPDLOCK | XLOCK |
Lorsque vous accédez à une table optimisée en mémoire à partir d’une transaction explicite ou implicite à l’aide d’un Transact-SQL interprété, vous devez inclure un indicateur de table de niveau d’isolation tel que SNAPSHOT, REPEATABLEREAD ou SERIALIZABLE, ou vous pouvez utiliser MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT. Pour plus d’informations, consultez Instructions pour les niveaux d’isolation des transactions avec des tables Memory-Optimized et des options ALTER DATABASE SET (Transact-SQL).
Remarque
Un indicateur de niveau d'isolation n'est pas nécessaire pour les tables optimisées en mémoire accédées par des requêtes exécutées en mode de validation automatique.
Voir aussi
prise en charge deTransact-SQL pour In-Memory OLTP
Migration vers In-Memory OLTP