SQL Server 2014 実践シリーズ （HTML 版）
「No.1 インメモリ OLTP 機能の実践的な利用方法」

1.6　RDB での主な性能低下をインメモリ OLTP で解決

従来ながらのディスク ベースの RDB（リレーショナル データベース）では、性能低下を引き起こす原因として、主に次の 5つがあります。

これらが原因で性能が低下している場合は、インメモリ OLTP 機能を採用することで、性能向上を期待することができます。

ロック待ちやラッチ待ちは、前述したように、多数のユーザーが同時に同じデータ（やページ）を操作することで発生する "待ち" ですが、インメモリ OLTP 機能では、ロックおよびラッチを利用しないアーキテクチャ（Lock Free／Latch Free）を採用しているので、こういった待ちに悩まされることがなくなります。

バッファ管理は、ディスクからデータ バッファ（メモリ）への読み込みとチェックポイント時のデータ ファイル（.mdf）への書き込みがありますが、前者はメモリを追加することで対応できます。インメモリ OLTP では、テーブル内の全てのデータをメモリへ配置（インメモリ化）します。その分のメモリが必要になりますが、データベース内のすべてのテーブルをインメモリ化する必要はなく、性能を向上させたいテーブルのみをインメモリ化することができます。

チェックポイント時のデータ ファイルへの書き込みは、詳しくは後述しますが、従来のデータベース エンジンよりも、インメモリ OLTP 機能でのデータの書き込みのほうが負荷が軽いことを確認しています。また、インメモリ OLTP 機能では、SCHEMA_ONLY（データの永続化なし）オプションを利用して、データの書き込みを行わないようにすることもできます。

インデックス管理は、従来のデータベース エンジンにおける通常のインデックス（b-tree 構造）でのメンテナンス コストです。b-tree インデックスでは、データが追加／更新されて、データが増えていくと、断片化が発生して、速度低下を引き起こします。これを解消するには、インデックスを再構築（ReBuild）または再構成（ReOrganize）しなければなりません。この処理は、処理の履歴をトランザクション ログへ書き込むので、データベース ミラーリングや、AlwaysOn 可用性グループを利用している場合には、その処理履歴をミラー サーバーへ転送する負荷もかかります。

インメモリ OLTP 機能では、ハッシュ インデックスがサポートされたことで、断片化に悩まされることがなくなり、再構築や再構成は必要ありません。また、インデックスに関する更新情報は、トランザクション ログに記録しないアーキテクチャを採用しているので、ログへの書き込み量を削減できるというメリットも得られます。

ログへの書き込みは、前述したように、インメモリ OLTP 機能でも、SCHEMA_AND_DATA（データの永続化有り）オプションを利用している場合には行いますが、インデックスに関する更新情報をログへ記録しない分、性能面でのメリットが得られます。また、Delayed Durability（遅延書き込み）オプションを利用することで、ログへの書き込みを非同期で行えるようになるので、性能向上を実現することができます。

SCHEMA_ONLY（データの永続化なし）オプションを利用した場合であれば、ログへの書き込みを行わないこともできるので、その分大きく性能を向上させることができます。