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.
S’applique à :
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
Les tables optimisées en mémoire sont créées à l’aide CREATE TABLE de (Transact-SQL).
Les tables à mémoire optimisée sont entièrement durables par défaut et, tout comme les transactions sur les tables traditionnelles basées sur disque, les transactions sur les tables à mémoire optimisée sont entièrement atomiques, cohérentes, isolées et durables (ACID). Les tables à mémoire optimisée et les procédures stockées compilées en mode natif ne prennent en charge qu’un sous-ensemble de fonctionnalités Transact-SQL.
À compter de SQL Server 2016 et dans Azure SQL Database, il n’existe aucune limite relative aux classements ni pages de codes qui sont spécifiques à OLTP en mémoire.
Le stockage principal des tables à mémoire optimisée est la mémoire principale. Les lignes de la table sont lues et écrites dans la mémoire. Une deuxième copie des données de la table est conservée sur le disque, mais uniquement pour la durabilité. Consultez Création et gestion du stockage des objets mémoire optimisés Pour plus d’informations sur les tables durables. Les données des tables à mémoire optimisée ne sont lues à partir du disque que lors de la récupération de la base de données (par exemple, après le redémarrage d’un serveur).
Pour des gains de performance encore accrus, l'OLTP en mémoire prend en charge les tables durables avec des transactions à durabilité retardée. Les transactions durables différées sont enregistrées sur le disque peu de temps après la validation de la transaction et le retour du contrôle au client. En échange de performances accrues, les transactions validées qui ne sont pas conservées sur le disque sont perdues en cas de panne du serveur ou de basculement.
Outre les tables optimisées pour la mémoire durable par défaut, SQL Server prend également en charge les tables optimisées pour la mémoire non durable, qui ne sont pas journalisées et dont les données ne sont pas conservées sur le disque. Cela signifie que les transactions sur ces tables ne nécessitent pas d’E/S de disque, mais que les données sont perdues en cas de panne du serveur ou de basculement.
L’OLTP en mémoire est intégré à SQL Server pour offrir une expérience transparente dans tous les domaines, tels que le développement, le déploiement, la gestion et la prise en charge. Une base de données peut contenir des objets en mémoire et sur disque.
Les lignes des tables optimisées en mémoire sont versionnées. Cela signifie que chaque ligne de la table a potentiellement plusieurs versions. Toutes les versions de ligne sont conservées dans la même structure de données de la table. Le contrôle de version de ligne est utilisé pour autoriser les lectures et les écritures simultanées sur la même ligne. Pour plus d’informations sur les lectures et les écritures simultanées sur la même ligne, consultez Transactions with Memory-Optimized Tables(Transactions avec des tables optimisées en mémoire).
La figure suivante illustre la gestion de plusieurs versions. Elle représente une table de trois lignes ayant chacune plusieurs versions.
La table a trois lignes : r1, r2 et r3. r1 a trois versions, r2 a deux versions, et r3 a quatre versions. Les différentes versions d’une même ligne n’occupent pas nécessairement des emplacements de mémoire consécutifs. Les différentes versions de ligne peuvent être dispersées dans l'ensemble de la structure de données de la table.
La structure de données des tables optimisées en mémoire peut être considérée comme une collection de versions de ligne. Les lignes d'une table sur disque sont organisées dans des pages et des extensions, et les lignes individuelles sont traitées sur la base du numéro et du décalage de la page, les versions de ligne dans les tables optimisées en mémoire sont traitées à l'aide de pointeurs de mémoire à huit octets.
Les données des tables optimisées en mémoire sont accessibles de deux manières :
Via des procédures stockées compilées en mode natif.
Par le biais de Transact-SQL interprété, en dehors d’une procédure stockée compilée en natif. Ces instructions Transact-SQL peuvent être dans des procédures stockées interprétées ou des instructions Transact-SQL ad hoc.
Accès aux données dans des tables optimisées en mémoire
Les tables optimisées en mémoire sont plus efficacement accessibles à partir des procédures stockées compilées en mode natif (Procédures stockées compilées en mode natif). Les tables optimisées en mémoire peuvent également être accessibles via le Transact-SQL (traditionnel) interprété. Le terme Transact-SQL interprété fait référence à l’accès aux tables optimisées en mémoire sans procédure stockée compilée en mode natif. Parmi les exemples d’accès interprété à Transact-SQL figurent l’accès à une table optimisée en mémoire à partir d’un déclencheur DML, d’un lot Transact-SQL ad hoc, d’une vue ou d’une fonction table.
Le tableau suivant résume l’accès natif et l’accès en Transact-SQL interprété pour différents objets.
| Fonctionnalité | Accès à l'aide d'une procédure stockée compilée en mode natif | Accès Transact-SQL interprété | Accès au CLR |
|---|---|---|---|
| Table mémoire optimisée | Oui | Oui | N°1 |
| Type de table optimisé pour la mémoire | Oui | Oui | Non |
| Procédure stockée compilée en mode natif | L’imbrication de procédures stockées compilées en mode natif est désormais prise en charge. Vous pouvez utiliser la syntaxe EXECUTE à l’intérieur des procédures stockées, à condition que la procédure référencée soit également compilée en mode natif. | Oui | Non* |
1Vous ne pouvez pas accéder à une table optimisée en mémoire ou à une procédure stockée compilée en mode natif à partir de la connexion contextuelle (connexion à partir de SQL Server lors de l’exécution d’un module CLR). Cependant, vous pouvez créer et ouvrir une autre connexion à partir de laquelle vous accédez aux tables optimisées en mémoire et aux procédures stockées compilées en mode natif.
Les données sensibles des tables optimisées en mémoire peuvent être protégées à l’aide de Always Encrypted. Les limites suivantes s'appliquent :
- Quand vous utilisez Always Encrypted avec des enclaves sécurisées, l’utilisation de clés compatibles avec les enclaves pour les colonnes de tables optimisées en mémoire n’est pas prise en charge. Cela signifie que le chiffrement sur place ne peut pas être utilisé et que le chiffrement initial est effectué sur le client.
- Always Encrypted n’est pris en charge pour aucune colonne d’une table optimisée en mémoire lorsque la table est référencée dans un module compilé en mode natif.
Performances et extensibilité
Les facteurs suivants affectent les gains de performances qui peuvent être obtenus avec In-Memory OLTP :
Communication: Une application utilisant de nombreux appels de procédure stockée courts peut voir un gain de performances plus faible par rapport à une application avec moins d’appels et plus de fonctionnalités implémentées dans chaque procédure stockée.
Exécution Transact-SQL : l’OLTP en mémoire offre des performances optimales si vous utilisez des procédures stockées compilées en mode natif plutôt que des procédures stockées interprétées ou l’exécution de requêtes. Il peut être avantageux d’accéder aux tables optimisées en mémoire à partir de ces procédures stockées.
Comparaison entre l’analyse de plage et la recherche de points : Les index non cluster optimisés en mémoire prennent en charge les analyses de plage et les analyses triées. Pour les recherches de points, les index de hachage optimisés en mémoire offrent de meilleures performances que les index non cluster optimisés en mémoire. Les index non cluster optimisés en mémoire offrent de meilleures performances que les index sur disque.
- À partir de SQL Server 2016, le plan de requête pour une table optimisée en mémoire peut analyser la table en parallèle. Les requêtes analytiques sont donc plus performantes.
- Les index de hachage peuvent également être analysés en parallèle à partir de SQL Server 2016.
- Les index non cluster peuvent également être analysés en parallèle à partir de SQL Server 2016.
Opérations d’indexation : Les opérations d’index ne sont pas journalisées et n’existent qu’en mémoire.
Concurrence : Les applications dont les performances sont affectées par la concurrence au niveau du moteur, comme la contention sur les verrous légers (latches) ou le blocage, s’améliorent considérablement lorsque l’application migre vers OLTP en mémoire.
Le tableau suivant répertorie les problèmes de performance et d'extensibilité couramment rencontrés dans les bases de données relationnelles et indique comment l'OLTP peut améliorer les performances.
| Problème | Impact sur In-Memory OLTP |
|---|---|
| Performances Utilisation élevée des ressources (processeur, E/S, réseau ou mémoire). |
CPU
Les procédures stockées compilées en mode natif peuvent réduire considérablement l’utilisation du processeur, car elles nécessitent moins d’instructions pour exécuter une instruction Transact-SQL par rapport aux procédures stockées interprétées. In-Memory OLTP peut aider à réduire les investissements matériels dans les charges de travail réparties, car un serveur peut potentiellement offrir un débit équivalent à celui de plusieurs serveurs. E/S Si vous rencontrez un goulot d'étranglement des E/S lors du traitement des pages de données ou d'index, In-Memory OLTP peut réduire ce goulot d'étranglement. De plus, la création de points de contrôle des objets OLTP en mémoire est continue et n’entraîne pas de hausse soudaine des opérations d’E/S. Toutefois, si le jeu de données actif des tables essentielles aux performances ne tient pas en mémoire, In-Memory OLTP n’est pas adapté, car les données doivent résider en mémoire. Si vous rencontrez un goulot d’étranglement d’E/S lors de la journalisation, In-Memory OLTP peut réduire ce goulot d’étranglement, car il effectue moins d’opérations de journalisation. Si une ou plusieurs tables optimisées en mémoire sont configurées en tant que tables non durables, supprimez la journalisation des données. Mémoire In-Memory OLTP n’offre aucun avantage en termes de performances. In-Memory OLTP peut exercer une pression supplémentaire sur la mémoire, car les objets doivent être résidents en mémoire. Network (Réseau) In-Memory OLTP n’offre aucun avantage en termes de performances. Les données doivent être communiquées de la couche Données à la couche Application. |
| Évolutivité La plupart des problèmes de mise à l’échelle dans les applications SQL Server sont dus à des problèmes de concurrence, tels que la contention au niveau des verrous, des loquets et des spinlocks. |
Contention de verrous internes Un scénario typique est une contention sur la dernière page d’un index lors de l’insertion simultanée de lignes selon l’ordre des clés. Étant donné In-Memory OLTP n’accepte pas de verrous lors de l’accès aux données, les problèmes d’évolutivité liés aux conflits de verrou sont entièrement éliminés. Contention sur verrou tournant Étant donné In-Memory OLTP n’accepte pas de verrous lors de l’accès aux données, les problèmes d’évolutivité liés aux conflits de spinlock sont entièrement supprimés. Contention liée au verrouillage Si votre application de base de données rencontre des problèmes de blocage entre les opérations de lecture et d'écriture, l'OLTP en mémoire les supprime, car il utilise une nouvelle forme de contrôle d'accès concurrentiel optimiste pour implémenter tous les niveaux d'isolation des transactions. In-Memory OLTP n’utilise pas TempDB pour stocker les versions de ligne. Si le problème de mise à l'échelle est provoqué par un conflit entre deux opérations d'écriture, telles que deux transactions simultanées tentant de mettre à jour la même ligne, l'OLTP en mémoire laisse une transaction aboutir et fait échouer l'autre. La transaction ayant échoué doit être soumise à nouveau, explicitement ou implicitement, en réessayant la transaction. Dans les deux cas, vous devez apporter des modifications à l'application. Si votre application connaît des conflits fréquents entre deux opérations d’écriture, l’intérêt du verrouillage optimiste s’en trouve réduit. L’application n’est pas adaptée à In-Memory OLTP. La plupart des applications OLTP n’ont pas de conflits d’écriture, sauf si le conflit est le résultat d’une escalade de verrouillage. |
Sécurité au niveau des lignes dans les tables optimisées en mémoire
La sécurité au niveau des lignes est prise en charge dans les tables optimisées en mémoire. L’application de stratégies de sécurité au niveau des lignes aux tables optimisées en mémoire est essentiellement la même que pour les tables sur disque, à ceci près que les fonctions table inline utilisées comme prédicats de sécurité doivent être compilées nativement (créées à l’aide de l’option WITH NATIVE_COMPILATION). Pour plus d’informations, consultez la section Compatibilité entre fonctionnalités dans la rubrique Sécurité au niveau des lignes .
Diverses fonctions de sécurité intégrées essentielles à la sécurité au niveau des lignes sont disponibles pour les tables optimisées en mémoire. Pour plus d’informations, consultez Fonctions intégrées dans les modules compilés en mode natif.
EXECUTE AS CALLER - Tous les modules natifs prennent désormais en charge et utilisent EXECUTE AS CALLER par défaut, même si l’indicateur n’est pas spécifié. Cela est dû au fait qu’il est prévu que toutes les fonctions de prédicat de sécurité au niveau des lignes utilisent EXECUTE AS CALLER afin que la fonction et toutes les fonctions intégrées utilisées dans celui-ci soient évaluées dans le contexte de l’utilisateur appelant.
EXECUTE AS CALLER subit une légère baisse de performances (d’environ 10 %) causée par les vérifications des autorisations effectuées sur l’appelant. Si le module spécifie explicitement EXECUTE AS OWNER ou EXECUTE AS SELF, on évite ces vérifications d’autorisation ainsi que le surcoût en performances qui y est associé. Cependant, l’utilisation de l’une ou l’autre de ces options avec les fonctions intégrées mentionnées entraîne une baisse plus élevée des performances en raison de la commutation de contexte nécessaire.
Scénarios
Pour découvrir une brève description des scénarios types dans lesquels l’OLTP en mémoire peut contribuer à améliorer les performances, consultez OLTP en mémoire.