Fonctionnalités SQL Server prises en charge
Cette rubrique décrit les fonctionnalités SQL Server qui ne sont pas prises en charge pour une utilisation avec des objets à mémoire optimisée.
fonctionnalités SQL Server prises en charge pour In-Memory OLTP
Les fonctionnalités SQL Server suivantes sont prises en charge sur une base de données qui contient des objets à mémoire optimisée, y compris un groupe de fichiers à mémoire optimisée.
Pour plus d'informations sur les types de données pris en charge, consultez Supported Data Types.
Options et opérations prises en charge sur les tables mémoire optimisées. Pour plus d’informations, consultez CREATE TABLE (Transact-SQL).
Options et opérations prises en charge sur les procédures stockées compilées en mode natif. Pour plus d’informations, consultez CREATE PROCEDURE (Transact-SQL).
Possibilité d’accéder à des tables optimisées en mémoire à l’aide de Transact-SQL interprété. Transact-SQL interprété fournit une surface équivalente à l’accès aux tables qui ne sont pas optimisées en mémoire à l’aide de procédures stockées qui ne sont pas compilées en mode natif et à l’aide de Transact-SQL. Pour plus d’informations, consultez Accès aux tables optimisées en mémoire à l’aide du Transact-SQL interprété.
Contrôle de version multiple et contrôle d'accès concurrentiel optimiste. Pour plus d’informations, consultez Transaction Isolation Levels.
Opérations de sauvegarde et de restauration d'une base de données qui contient un groupe de fichiers mémoire optimisé. Pour plus d’informations, consultez Sauvegarder et restaurer des bases de données SQL Server.
Affichages catalogue, vues de gestion dynamique et événements étendus pour la prise en charge. Pour plus d’informations, consultez Vues système, procédures stockées, DMV et types d’attente pour l’OLTP en mémoire.
SQL Server Objets de gestion. Pour plus d’informations, consultez Prise en charge d’objets SMO (SQL Server Management Objects) pour l’OLTP en mémoire.
SQL Server Management Studio. Pour plus d’informations, consultez Prise en charge de SQL Server Management Studio pour l’OLTP en mémoire.
SQL Server PowerShell. Pour plus d'informations, consultez Présentation de SQL Server PowerShell.
Importez et exportez des données en bloc à l'aide de l'utilitaire bcp. Pour plus d’informations, consultez Importer et exporter des données en bloc à l’aide de l’utilitaire bcp (SQL Server).
Récupération sur incident.
Plusieurs conteneurs dans un groupe de fichiers mémoire optimisé pour stocker des objets de l'OLTP en mémoire et réduire l'objectif de temps de récupération (RTO).
SQL Server blocs de journal des transactions calculent la somme de contrôle et valident.
Nouvel indicateur de table SNAPSHOT. Pour plus d’informations, consultez Indicateurs de table (Transact-SQL).
Niveau DB COMPAT.
Base de données partiellement autonome. L'authentification de la base de données autonome est prise en charge. Toutefois, tous les objets de l'OLTP en mémoire sont marqués comme étant des « relations contenant-contenu essentielles » dans la vue de gestion dynamique dm_db_uncontained_entities.
Service Broker, sous certaines conditions. Impossible d'accéder à une file d'attente à partir d'une procédure stockée compilée en mode natif. Impossible d'accéder à une file d'attente dans une base de données distante, dans une transaction qui accède à des tables à mémoire optimisée.
Clustering de basculement : dans le cadre de l’offre AlwaysOn SQL Server, les instances de cluster de basculement AlwaysOn tirent parti de la fonctionnalité WSFC (Clustering de basculement) Windows Server pour fournir une haute disponibilité locale par le biais de la redondance au niveau du serveur instance- un cluster de basculement instance (FCI). Pour plus d’informations, consultez Instances de cluster de basculement AlwaysOn (SQL Server).
Intégration à AlwaysOn : SQL Server fournit plusieurs options pour créer une haute disponibilité pour un serveur ou une base de données, y compris AlwaysOn. Pour plus d’informations, consultez Solutions à haute disponibilité (SQL Server).
Expédition des journaux : SQL Server La copie des journaux de transactions vous permet d’envoyer automatiquement des sauvegardes du journal des transactions à partir d’une base de données principale sur un serveur principal instance à une ou plusieurs bases de données secondaires sur des instances de serveur secondaire distinctes. Pour plus d’informations, consultez À propos de la copie des journaux de transaction (SQL Server).
La réplication transactionnelle vers des tables mémoire optimisées sur les abonnés est prise en charge avec certaines restrictions. Pour plus d’informations, consultez Abonnés à la réplication de tables optimisées en mémoire.
Resource Governor : SQL Server Resource Governor est une fonctionnalité que vous pouvez utiliser pour gérer SQL Server charge de travail et la consommation de ressources système. Le gouverneur des ressources vous permet de spécifier des limites sur la quantité d’UC,d’E/S physiques et de mémoire utilisables par les requêtes d’application entrantes. Pour plus d'informations, consultez Managing Memory for In-Memory OLTP et Resource Governor.
OLTP en mémoire est limité au niveau des pages de codes prises en charge pour les colonnes (var)char dans les tables mémoire optimisées et les classements pris en charge utilisés dans des index et des procédures stockées compilées en mode natif. Pour plus d'informations, consultez Collations and Code Pages.
Prise en charge de BACPAC.
SQL Server Fonctionnalités non prises en charge pour l’OLTP en mémoire
Les fonctionnalités SQL Server suivantes ne sont pas prises en charge sur une base de données qui contient des objets à mémoire optimisée (notamment des groupes de fichiers à mémoire optimisée).
| Fonctionnalités non prises en charge | Description de la fonctionnalité |
|---|---|
| Compression de données pour les tables à mémoire optimisée. | Vous pouvez utiliser la fonctionnalité de compression de données pour compresser les données dans une base de données et réduire la taille de la base de données. Pour plus d’informations, consultez Compression de données. |
| Partitionnement des tables et des index HASH mémoire optimisés. | Les données des tables et des index partitionnés sont divisées en unités qui peuvent être réparties sur plusieurs groupes de fichiers d'une base de données. Pour plus d’informations, consultez Tables et index partitionnés. |
| Chiffrement transparent des données (TDE) sur le groupe de fichiers mémoire optimisé d'une base de données. | Le chiffrement transparent des données (TDE, Transparent Data Encryption) effectue le chiffrement et le déchiffrement des E/S en temps réel des fichiers de données et des fichiers journaux. Pour plus d’informations, consultez Transparent Data Encryption (TDE). Le chiffrement transparent des données (TDE) peut être activé sur une base de données contenant des objets de l'OLTP en mémoire. Les enregistrements de journal de l'OLTP en mémoire sont chiffrés si le chiffrement transparent des données (TDE) est activé. Les fichiers de point de contrôle des tables durables ne sont pas chiffrés, même si le chiffrement transparent des données (TDE) est activé sur la base de données. |
| Réplication | Les configurations de réplication autres que la réplication transactionnelle vers des tables mémoire optimisées sur les abonnés sont incompatibles avec des tables ou des vues qui référencent des tables mémoire optimisées. La réplication à l’aide de sync_mode='instantané de base de données' n’est pas prise en charge s’il existe un groupe de fichiers à mémoire optimisée. Pour plus d’informations, consultez Abonnés à la réplication de tables optimisées en mémoire. |
| MARS (Multiple Active Result Sets) | Multiple Active Result Sets (MARS) n'est pas pris en charge avec les tables mémoire optimisées. Cette erreur peut également indiquer l'utilisation d'un serveur lié. Un serveur lié peut utiliser MARS. Les serveurs liés ne sont pas pris en charge avec les tables mémoire optimisées. À la place, connectez-vous directement au serveur et à la base de données qui héberge les tables mémoire optimisées. |
| Mise en miroir | La mise en miroir de bases de données est une solution permettant d'accroître la disponibilité d'une base de données SQL Server. Pour plus d’informations, consultez Mise en miroir de bases de données (SQL Server). |
| Reconstruire le journal | La reconstruction du journal, via un attachement ou ALTER DATABASE, n'est pas prise en charge pour les bases de données avec un groupe de fichiers MEMORY_OPTIMIZED_DATA. |
| Serveur lié | Pour plus d’informations, consultez Serveurs liés (moteur de base de données). |
| Journalisation en bloc | Quel que soit le mode de récupération de la base de données, toutes les opérations sur les tables à mémoire optimisée durables sont toujours entièrement journalisées. |
| Journalisation minimale | La journalisation minimale n'est pas prise en charge pour les tables à mémoire optimisée. Pour plus d’informations sur la journalisation minimale, consultez Journal des transactions (SQL Server) et Prérequis pour la journalisation minimale dans l’importation en bloc. |
| Suivi des modifications | Le suivi des modifications peut être activé sur une base de données avec des objets de l'OLTP en mémoire. Toutefois, les modifications apportées aux tables à mémoire optimisée ne sont pas suivies. |
| déclencheurs DDL | Les déclencheurs DDL aux niveaux de la base de données et du serveur ne sont pas pris en charge avec les tables de l'OLTP en mémoire et les procédures stockées compilées en mode natif. |
| Capture de données modifiées (CDC) | La capture de données modifiées ne doit pas être activée sur une base de données qui possède des objets de l'OLTP en mémoire, car elle empêche certaines opérations telles que DROP. |
| Relation contenant-contenu de base de données | La relation contenant-contenu de la base de données n'est pas prise en charge dans une base de données contenant des procédures stockées compilées en mode natif et des tables optimisées en mémoire. Pour plus d’informations, consultez Bases de données autonomes. |
| Connexions contextuelles | L'accès aux tables optimisées en mémoire à l'aide de la connexion contextuelle depuis des procédures stockées CLR n'est pas pris en charge. |
| Curseurs | Curseurs de jeu de clés et dynamiques sur les requêtes qui accèdent aux tables à mémoire optimisée. Ces requêtes sont dégradées en requêtes statiques en lecture seule. |
| TABLESTAMP | TABLESTAMP n'est pas pris en charge. Pour plus d’informations, consultez FROM (Transact-SQL). |
| AUTO_CLOSE | AUTO_CLOSE n'est pas pris en charge. Pour plus d'informations, consultez Set the AUTO_CLOSE Database Option to OFF. |
| Instantanés de base de données | Les instantanés de base de données ne sont pas pris en charge. Pour plus d’informations, consultez Instantanés de base de données (SQL Server). |
| DDL transactionnel | La DLL transactionnelle n'est pas prise en charge avec l'OLTP en mémoire. |
| Notifications d'événements | Les notifications d'événements ne sont pas prises en charge. Pour plus d'informations, voir Event Notifications. |
| Mode fibre | Le mode fibre n'est pas pris en charge avec l'OLTP en mémoire. |
| Gestion basée sur des stratégies (PBM). | Les modes Prévention et Journal uniquement de PBM ne sont pas pris en charge. L'existence de ces stratégies sur le serveur peut empêcher l'exécution des déclencheurs DDL de l'OLTP en mémoire. Les modes À la demande et Selon la planification sont pris en charge. |
| Déployer/Extraire DACFX | Le déploiement et l'extraction d'infrastructure DAC ne sont pas pris en charge avec l'OLTP en mémoire. |
À quelques exceptions, les transactions de bases de données croisées ne sont pas prises en charge. Le tableau suivant décrit les cas sont pris en charge, et les restrictions correspondantes. (Voir aussi Requêtes de bases de données croisées.)
| Bases de données | Autorisé | Description |
|---|---|---|
| Bases de données utilisateur, model et msdb | Non | Les requêtes et transactions de bases de données croisées ne sont pas prises en charge. Les requêtes et les transactions qui accèdent aux tables mémoire optimisées ou aux procédures stockées compilées en mode natif ne peuvent pas accéder à d'autres bases de données, à l'exception de la base de données système master (accès en lecture seule) et de tempdb. |
| Base de données Resource et tempdb | Oui | Il n'y a pas de restrictions appliquées aux transactions de bases de données croisées qui, à part une base de données en mode mono-utilisateur, utilisent uniquement la base de données Resource et tempdb. |
| master | en lecture seule | La validation des transactions de bases de données croisées qui impliquent l'OLTP en mémoire et la base de données master échoue si ces transactions incluent des écritures dans la base de données master. Les transactions de bases de données croisées qui n'impliquent que des lectures de la base de données master et utilisent uniquement une base de données mono-utilisateur sont autorisées. |