Partager via

Suppression du conteneur et du groupe de fichiers à mémoire optimisée

S’applique à : SQL Server 2025 (17.x) et versions ultérieures

Dans SQL Server 2022 (16.x) et les versions antérieures, si In-Memory OLTP est activé pour une base de données, le dernier conteneur à mémoire optimisée et le groupe de fichiers à mémoire optimisée ne peuvent pas être supprimés même si tous les objets OLTP In-Memory sont supprimés. Par conséquent, le moteur OLTP In-Memory continue à s’exécuter lorsqu’il n’est pas utilisé.

À compter de SQL Server 2025 (17.x), le moteur OLTP In-Memory peut être arrêté en supprimant complètement tous les conteneurs optimisés pour la mémoire et groupes de fichiers dans les bases de données sans objets OLTP In-Memory restants.

Pour supprimer les conteneurs et groupes de fichiers à mémoire optimisée et arrêter le moteur OLTP In-Memory :

  1. À titre d’étape de validation, connectez-vous à la base de données et exécutez la requête suivante pour vérifier que le moteur OLTP (XTP) In-Memory est déployé dans la base de données :

    SELECT deployment_state,
       deployment_state_desc
FROM sys.dm_db_xtp_undeploy_status;

    Si la colonne deployment_state est 1 ou 2, le moteur OLTP In-Memory est déployé et vous pouvez procéder aux étapes suivantes. Si la deployment_state colonne est 0, le moteur OLTP In-Memory n’est pas déployé dans la base de données active ou a déjà été arrêté et le reste de cet article ne s’applique pas.

  2. Supprimez tous les In-Memory objets OLTP dans la base de données, y compris les tables et les types de tables optimisés en mémoire, ainsi que les procédures stockées compilées en mode natif.

    Avertissement

    Cette étape peut entraîner une perte permanente de données dans les tables mémoire optimisées dans la base de données active. Avant de continuer, assurez-vous que les données ne sont pas nécessaires et effectuez une sauvegarde de la base de données.

    Pour rechercher In-Memory objets OLTP dans une base de données, exécutez les instructions T-SQL suivantes :

    USE [<database-name-placeholder>];

/* memory-optimized tables */
SELECT object_id,
       OBJECT_SCHEMA_NAME(object_id) AS schema_name,
       name AS table_name
FROM sys.tables
WHERE is_memory_optimized = 1;

/* natively compiled modules */
SELECT object_id,
       OBJECT_SCHEMA_NAME(object_id) AS schema_name,
       OBJECT_NAME(object_id) AS module_name
FROM sys.all_sql_modules
WHERE uses_native_compilation = 1;

/* memory-optimized table types */
SELECT SCHEMA_NAME(schema_id) AS type_schema_name,
       name AS type_name,
       OBJECT_NAME(type_table_object_id) AS type_table_name
FROM sys.table_types
WHERE is_memory_optimized = 1;

    Pour plus d’informations, consultez DROP TABLE, DROP PROCEDURE et DROP TYPE.

  3. Supprimez tous les conteneurs à mémoire optimisée à l’aide de l’instruction ALTER DATABASE ... REMOVE FILE . Pour plus d’informations, voir Options de fichiers et de groupes de fichiers d’ALTER DATABASE. Vous pouvez également supprimer des conteneurs à mémoire optimisée à l’aide de la page Fichiers de la boîte de dialogue Propriétés de la base de données de votre base de données dans SQL Server Management Studio (SSMS).

    La suppression du dernier conteneur à mémoire optimisée pour la base de données démarre la suppression du moteur OLTP In-Memory. Il s’agit d’une opération longue qui peut nécessiter des étapes supplémentaires. Pour plus d’informations, consultez Étapes pour terminer la dernière suppression de conteneur à mémoire optimisée plus loin dans cet article.

    Si vous annulez ou abandonnez une instruction de longue durée ALTER DATABASE ... REMOVE FILE lors de la suppression du dernier conteneur à mémoire optimisée, la suppression peut être partiellement terminée. Pour terminer la suppression, vous pouvez exécuter l’instruction ALTER DATABASE ... REMOVE FILE ultérieurement.

  4. Supprimez le groupe de fichiers à mémoire optimisée à l’aide de l’instruction ALTER DATABASE ... REMOVE FILEGROUP ou utilisez la page Groupes de fichiers dans la boîte de dialogue Propriétés de la base de données dans SSMS.

La suppression des conteneurs et du groupe de fichiers optimisés pour la mémoire a réussi, et le moteur OLTP In-Memory est arrêté lorsque la valeur dans la colonne deployment_state de sys.dm_db_xtp_undeploy_status est 0.

Remarque

La suppression de conteneurs optimisés pour la mémoire n'est pas prise en charge lorsque la base de données a des instantanés de bases de données. Supprimez tous les instantanés avant de supprimer des conteneurs à mémoire optimisée.

Étapes pour finaliser la suppression du dernier conteneur optimisé pour la mémoire

Si l’instruction ALTER DATABASE ... REMOVE FILE permettant de supprimer le dernier conteneur à mémoire optimisée ne se termine pas immédiatement, des étapes supplémentaires sont requises.

La vue DMV sys.dm_db_xtp_undeploy_status fournit l’état du processus de suppression du moteur OLTP In-Memory. Dans les étapes suivantes, utilisez cette requête pour déterminer l’état actuel et les actions requises :

SELECT deployment_state,
       deployment_state_desc,
       undeploy_lsn,
       start_of_log_lsn
FROM sys.dm_db_xtp_undeploy_status;

  1. Si la deployment_state valeur est 3 et que la valeur de la undeploy_lsn colonne est 0, exécutez la commande suivante :

    CHECKPOINT;

  2. Si la deployment_state valeur est 3 et que la valeur de la undeploy_lsn colonne est autre que 0, le processus de suppression du conteneur attend le numéro de séquence de journal (LSN) dans la start_of_log_lsn colonne pour avancer au-delà de la valeur LSN dans la undeploy_lsn colonne. Cela nécessite que le journal des transactions soit tronqué. Pour tronquer le journal :

    • Exécutez la commande suivante :

      CHECKPOINT;

      Pour avancer start_of_log_lsn au-delà undeploy_lsn, vous devrez peut-être exécuter cette commande plusieurs fois, en attendant une minute après chaque exécution de commande.

    • Si la base de données utilise le modèle de récupération Complet ou journalisé en bloc, alors outre l'exécution des commandes, vous devrez peut-être déterminer et résoudre la raison du délai de troncation du journal, qui est signalée dans la colonne de l’affichage CHECKPOINT dans la vue catalogue log_reuse_wait_desc.

      Si la valeur deployment_state reste 3 après l’exécution des CHECKPOINT commandes, exécutez l’instruction suivante :

      SELECT name,
       log_reuse_wait_desc
FROM sys.databases
WHERE database_id = DB_ID();

      Une fois que vous connaissez la raison du retard dans la troncation du journal, consultez Facteurs qui peuvent retarder la troncation du journal pour plus d’informations et déterminer l’action appropriée.

      Dans les bases de données actives, le journal des transactions est généralement tronqué après un certain temps sans aucune action utilisateur supplémentaire. Par exemple, si log_reuse_wait_desc dans sys.databases est LOG_BACKUP, alors les sauvegardes de journaux planifiées ou à la demande tronquent le journal. Pour plus d’informations, consultez Sauvegarder un journal des transactions.

      Si la valeur de la log_reuse_wait_desc colonne est NOTHING, mais que la valeur de deployment_state la colonne reste 3, sauvegardez le journal des transactions. Pour tronquer le journal des transactions, vous devrez peut-être effectuer plusieurs sauvegardes de journal des transactions.

  3. Si la deployment_state valeur est 4, le début de la partie active du journal des transactions a avancé au-delà du LSN de déséploiement, et le processus de suppression du conteneur attend l'enregistrement final de déséploiement. Dans la plupart des cas, cette étape se termine en quelques secondes sans aucune action supplémentaire.

    Si la base de données possède des réplicas de disponibilité, l’enregistrement de non-déploiement doit se propager et s’appliquer à tous les réplicas. Si la valeur 4 persiste pendant une longue période, consultez Déterminer pourquoi les modifications du réplica principal ne sont pas reflétées sur le réplica secondaire pour un groupe de disponibilité Always On pour plus d’informations.

  4. Si la deployment_state valeur est 5, le processus de suppression du conteneur attend la fin de l’opération de point de contrôle XTP finale. Pour lancer un point de contrôle immédiatement, exécutez la commande suivante :

    CHECKPOINT;

    Un point de contrôle XTP se produit automatiquement une fois que le journal des transactions a augmenté d’un certain seuil. Pour plus d’informations, consultez Opération de point de contrôle pour Memory-Optimized tables.

  5. Une fois l’opération de point de contrôle XTP finale terminée, la suppression du dernier conteneur à mémoire optimisée se termine correctement et la valeur de la deployment_state colonne devient 0.

  6. Si la deployment_state valeur est 6, cela signifie que l’instruction ALTER DATABASE ... REMOVE FILE du dernier conteneur à mémoire optimisée a été annulée ou abandonnée. Exécutez à nouveau l’instruction pour terminer la suppression du conteneur.

Contenu connexe

  • Last updated on