Azure SQL Database のインメモリ OLTP ストレージを監視する
適用対象: 
Azure SQL Database
In-Memory OLTP では、メモリ最適化テーブルおよびテーブル変数内のデータは、メモリ内データ用に確保されたデータベース メモリの一部であるインメモリ OLTP ストレージに存在します。
- Premium (DTU) サービス レベルおよび Business Critical (仮想コア) サービス レベルのデータベースとエラスティック プールは、インメモリ OLTP をサポートします。
- Hyperscale サービス レベルは、インメモリ OLTP オブジェクトのサブセットをサポートしますが、メモリ最適化テーブルは含みません。 詳細については、「Hyperscale の制限事項」を参照してください。
データがインメモリ OLTP ストレージの上限に収まるかどうかを判断する
さまざまなサービス目標のストレージの上限を確認します。 Premium および Business Critical サービス目標には、それぞれインメモリ OLTP ストレージの最大サイズがあります。
- DTU ベースのリソース制限 - 単一データベース
- DTU ベースのリソース制限 - エラスティック プール
- 仮想コアベースのリソース制限 - 単一データベース
- 仮想コアベースのリソース制限 - エラスティック プール
メモリ最適化テーブルのメモリ必要量の推定は、Azure SQL Database で SQL Server の要件を推定する場合と同じように行います。 「メモリ必要量の推定」を参照してください。
テーブル行とテーブル変数行、およびインデックスも上限にカウントされます。 また、ALTER TABLE ステートメントには、テーブル全体とそのインデックスの新しいバージョンを作成するのに十分なメモリが必要です。
この上限に達すると、挿入操作や更新操作は失敗することがあります。 その場合は、データを削除してメモリを再利用するか、データベースまたはエラスティック プールのサービス目標をスケールアップする必要があります。 詳細については、「インメモリ OLTPストレージのエラー状況の修正 - エラー41823および41840」をご覧ください。
監視とアラート
Azure Portal では、インメモリ OLTP ストレージの使用量を、サービス目標のストレージ上限の割合として監視できます。
- SQL データベースの [概要] ページで、[監視] ページでグラフを選択します。 または、左側のナビゲーション メニューから、 [監視] を見つけて [メトリック] を選択します。
- [メトリックの追加] を選択します。
- [基本] で、インメモリ OLTP ストレージの割合のメトリックを選択します。
- アラートを追加するには、[リソース使用率] ボックスを選択して [メトリック] ページを開き、[新しいアラート ルール] を選択します。 次の手順に従ってメトリック アラート ルールを作成します。
または、次のクエリを使用して、インメモリ ストレージの使用率を表示します。
SELECT xtp_storage_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;
インメモリ OLTP を使用してメモリ不足エラーを解決する
データベースまたはエラスティック プールでインメモリ OLTP ストレージの上限に達すると、エラー 41823 (単一データベースの場合) またはエラー 41840 (エラスティック プールの場合) で、 INSERT、UPDATE、ALTER、および CREATE ステートメントが失敗する可能性があります。 どちらのエラーの場合も、アクティブなトランザクションが中止します。
エラー 41823 および 41840 は、データベースまたはエラスティック プール内のメモリ最適化テーブルおよびテーブル変数が、インメモリ OLTP ストレージの最大サイズに達したことを示します。
これらのエラーを解決するには、次のいずれかを実行します。
- 従来のディスク ベース テーブルにデータをオフロードするなどして、メモリ最適化テーブルからデータを削除します。
- サービス目標を、メモリ最適化テーブルおよびテーブル変数に保持する必要があるデータ用に十分なインメモリ OLTP ストレージがある目標にアップグレードします。
Note
まれに、エラー 41823 および 41840 が一時的なものである場合があります。これは、利用できるインメモリ OLTP ストレージが十分にあり、操作の再試行が成功することを意味します。 したがって、使用可能なインメモリ OLTP ストレージの総量を監視し、かつ、エラー 41823 または 41840 が初めて発生した場合は再試行することをお勧めします。 再試行ロジックについて詳しくは、インメモリ OLTP での競合の検出と再試行ロジックに関する項目をご覧ください。
DMV を使用した監視
メモリ消費量を定期的に監視することで、メモリ使用量がどのように増加しているか、およびリソース制限に対してどの程度余裕があるかを判断できます。 データベースまたはインスタンスのオブジェクトによって消費されているメモリ量を特定します。 sys.dm_db_xtp_table_memory_stats または sys.dm_os_memory_clarks の DMV を使用できます。
sys.dm_db_xtp_table_memory_statsにクエリを実行することで、すべてのユーザー テーブル、インデックス、およびシステム オブジェクトのメモリ消費を確認できます。SELECT object_name(object_id) AS [Name], * FROM sys.dm_db_xtp_table_memory_stats;インメモリ OLTP エンジンとメモリ最適化オブジェクトに割り当てられたメモリは、データベース内の他のメモリ コンシューマーと同じ方法で管理されます。
MEMORYCLERK_XTP型のクラークは、インメモリ OLTP エンジンに割り当てられたすべてのメモリを占めます。 次のクエリを使用して、インメモリ OLTP エンジンによって使用されるすべてのメモリ (特定のデータベース専用のメモリを含む) を検索します。-- This DMV accounts for all memory used by the In-Memory OLTP engine SELECT [type], [name] , memory_node_id , pages_kb/1024. AS pages_MB FROM sys.dm_os_memory_clerks WHERE [type] LIKE '%xtp%';type name memory_node_id pages_MB -------------------- ---------- -------------- -------------------- MEMORYCLERK_XTP Default 0 18 MEMORYCLERK_XTP DB_ID_5 0 1358 MEMORYCLERK_XTP Default 64 0
動的管理ビュー sys.dm_os_out_of_memory_eventsを使用して、Azure SQL Database のメモリ不足エラーの詳細を取得することもできます。 次に例を示します。
SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;