適用対象:
SQL Server 2025 (17.x) プレビュー以降のバージョン
SQL Server 2022 (16.x) 以前のバージョンでは、In-Memory OLTP がデータベースに対して有効になっている場合、すべての In-Memory OLTP オブジェクトが削除された場合でも、最後のメモリ最適化コンテナーとメモリ最適化ファイル グループを削除することはできません。 その結果、In-Memory OLTP エンジンは、使用されていないときに引き続き実行されます。
SQL Server 2025 (17.x) Preview 以降では、残りの In-Memory OLTP オブジェクトがないデータベース内のすべてのメモリ最適化コンテナーとファイル グループを完全に削除することで、In-Memory OLTP エンジンを停止できます。
メモリ最適化コンテナーとファイル グループを削除し、In-Memory OLTP エンジンを停止するには:
検証手順として、データベースに接続し、次のクエリを実行して、In-Memory OLTP (XTP) エンジンがデータベースにデプロイされていることを確認します。
SELECT deployment_state, deployment_state_desc FROM sys.dm_db_xtp_undeploy_status;deployment_state列が 1 または 2 の場合、In-Memory OLTP エンジンがデプロイされ、次の手順に進むことができます。deployment_state列が 0 の場合、In-Memory OLTP エンジンは現在のデータベースにデプロイされていないか、既に停止しており、この記事の残りの部分は適用されません。メモリ最適化テーブルとテーブル型、ネイティブ コンパイル ストアド プロシージャなど、データベース内のすべての In-Memory OLTP オブジェクトを削除します。
注意事項
この手順により、現在のデータベースのメモリ最適化テーブル内のデータが永続的に失われる可能性があります。 続行する前に、データが不要であることを確認し、データベースのバックアップを作成します。
データベース In-Memory OLTP オブジェクトを検索するには、次の T-SQL ステートメントを実行します。
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;詳細については、 DROP TABLE、 DROP PROCEDURE、DROP TYPE を参照 してください。
ALTER DATABASE ... REMOVE FILEステートメントを使用して、メモリ最適化コンテナーをすべて削除します。 詳しくは、「ALTER DATABASE の File および Filegroup オプション」をご覧ください。 SQL Server Management Studio (SSMS) のデータベースの [データベースのプロパティ] ダイアログの [ファイル] ページを使用して、メモリ最適化コンテナーを削除することもできます。データベースの最後のメモリ最適化コンテナーを削除すると、In-Memory OLTP エンジンの削除が開始されます。 これは実行時間の長い操作であり、追加の手順が必要になる場合があります。 詳細については、この記事で後述 する最後のメモリ最適化コンテナーの削除を完了する手順 を参照してください。
メモリ最適化コンテナーの最後の削除中に実行時間の長い
ALTER DATABASE ... REMOVE FILEステートメントをキャンセルまたは中止すると、削除が部分的に完了している可能性があります。 削除を完了するには、後でALTER DATABASE ... REMOVE FILEステートメントを実行します。ALTER DATABASE ... REMOVE FILEGROUPステートメントを使用するか、SSMS の [データベースのプロパティ] ダイアログの [ファイル グループ] ページを使用して、メモリ最適化ファイル グループを削除します。
メモリ最適化コンテナーとファイル グループの削除が成功し、deployment_stateの sys.dm_db_xtp_undeploy_status 列の値が 0 の場合、In-Memory OLTP エンジンが停止します。
注
データベースに データベース スナップショットがある場合、メモリ最適化コンテナーの削除はサポートされません。 メモリ最適化コンテナーを削除する前に、すべてのスナップショットを削除します。
メモリ最適化コンテナーの最後の削除を完了する手順
最後のメモリ最適化コンテナーを削除する ALTER DATABASE ... REMOVE FILE ステートメントがすぐに完了しない場合は、追加の手順が必要です。
sys.dm_db_xtp_undeploy_status DMV は、In-Memory OLTP エンジンの削除プロセスの状態を提供します。 次の手順では、このクエリを使用して、現在の状態と必要なアクションを確認します。
SELECT deployment_state,
deployment_state_desc,
undeploy_lsn,
start_of_log_lsn
FROM sys.dm_db_xtp_undeploy_status;
deployment_state値が 3 で、undeploy_lsn列の値が 0 の場合は、次のコマンドを実行します。CHECKPOINT;deployment_state値が 3 で、undeploy_lsn列の値が 0 以外の場合、コンテナーの削除プロセスでは、start_of_log_lsn列のログ シーケンス番号 (LSN) がundeploy_lsn列の LSN 値を超えるまで待機しています。 これには、トランザクション ログを切り捨てる必要があります。 ログを縮小するには次のコマンドを実行します。
CHECKPOINT;start_of_log_lsnを超えてundeploy_lsnを進めるために、このコマンドを複数回実行し、各コマンドの実行後に 1 分待つ必要がある場合があります。データベースで完全復旧モデルまたは一括ログ復旧モデルを使用している場合は、
CHECKPOINTコマンドの実行に加えて、ログ切り捨ての遅延の理由を特定して対処する必要があります。これは、log_reuse_wait_descカタログ ビューのsys.databases列で報告されます。deployment_stateコマンドの実行後CHECKPOINT値が 3 のままの場合は、次のステートメントを実行します。SELECT name, log_reuse_wait_desc FROM sys.databases WHERE database_id = DB_ID();ログ切り捨ての遅延の理由がわかったら、ログの切 り捨てを遅延させる可能性がある要因 を参照して、詳細を確認し、適切なアクションを決定してください。
アクティブなデータベースでは、通常、トランザクション ログはしばらくすると切り捨てられ、追加のユーザー 操作は行いません。 たとえば、
log_reuse_wait_descのsys.databasesがLOG_BACKUPとなる場合、スケジュールされたログバックアップまたはオンデマンドログバックアップによってログが切り捨てられます。 詳細については、「 トランザクション ログのバックアップ」を参照してください。log_reuse_wait_desc列の値がNOTHINGされていても、deployment_state列の値が 3 のままである場合は、トランザクション ログをバックアップします。 トランザクション ログを切り捨てるには、複数のトランザクション ログ バックアップを行う必要がある場合があります。
deployment_state値が 4 の場合、トランザクション ログのアクティブな部分の開始は展開解除 LSN を超えて進み、コンテナーの削除プロセスは最終的な展開解除ログ レコードを待機しています。 ほとんどの場合、この手順は数秒で完了し、追加のアクションは実行されません。データベースに可用性レプリカがある場合は、デプロイ解除レコードが伝達され、すべてのレプリカに適用される必要があります。 値 4 が長時間保持される場合は、「 Always On 可用性グループのセカンダリ レプリカにプライマリ レプリカからの変更が反映されない理由を特定 する」を参照してください。
deployment_state値が 5 の場合、コンテナーの削除プロセスは、最終的な XTP チェックポイント操作の完了を待機しています。 チェックポイントをすぐに開始するには、次のコマンドを実行します。CHECKPOINT;XTP チェックポイントは、トランザクション ログが特定のしきい値に達すると自動的に発生します。 詳細については、「 Memory-Optimized テーブルのチェックポイント操作」を参照してください。
最後の XTP チェックポイント操作が完了すると、最後のメモリ最適化コンテナーの削除は正常に完了し、
deployment_state列の値は 0 になります。deployment_state値が 6 の場合は、最後のメモリ最適化コンテナーのALTER DATABASE ... REMOVE FILEステートメントが取り消されたか中止されたことを意味します。 ステートメントをもう一度実行して、コンテナーの削除を完了します。