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

1.4　大量のユーザーによる同時更新が発生するシステムに最適

インメモリ OLTP 機能が最も効果を発揮するのは、大量のユーザーからの多数の更新要求が発生するシステムです。オンラインゲームや、FX 取引、オンライン ショッピング サイト、チケット予約、ポイントカード システムなど、トランザクションとしては小さく（実行されるステートメントが単純で、短いトランザクション）、多数の同時実行によるブロッキングが発生しやすいシステムで最も効果を発揮します。

従来のディスク ベースのデータベース エンジンでは、データの更新時（INSERT／UPDATE／DELETE 時）に、ロック待ち（Lock Wait）やラッチ待ち（Latch Wait）が原因で、同時実行性が低下することがありましたが、インメモリ OLTP 機能では、このようなブロッキングは発生しません。インメモリ OLTP 機能は、ロックおよびラッチを利用しないアーキテクチャ（Lock Free／Latch Free）を採用しているからです。

◆ ロック フリーな楽観的同時実行制御（tempdb 不使用のスナップショット分離）

インメモリ OLTP 機能では、ロックを利用しないマルチ バージョンの楽観的同時実行制御（Optimistic Concurrency Control）を採用しています。これは、SQL Server 2005 からサポートされているスナップショット分離機構をインメモリ OLTP 向けに改良したものです。この新しいスナップショット分離機構は、tempdb を利用しない、完全なインメモリ アーキテクチャです。

インメモリ OLTP 機能の楽観的同時実行制御では、次の図のように更新中のデータでも、ロック待ちが発生することなく、データを読み取ることが可能です。

◆ ラッチ待ちとは？ ～スループットの低下～

従来ながらのディスク ベースのテーブルでは、大量のユーザーからの多数の更新要求がある場合には、ラッチ待ちによるブロッキングが問題となり得ます。ラッチ（Latch）には、主にページ ラッチ（PAGELATCH_SH、PAGELATCH_EX）と IOラッチ（PAGEIOLATCH_SH、PAGEIOLATCH_EX）がありますが、前者は、ページへの同時アクセスを制御するための、SQL Server が内部的にページに対してかけるロックのようなもの、後者は、データ ファイル（.mdf）からメモリ内のデータ バッファへページを取り出すとき／書き出すときにかけるロックのようなものです。

ページ ラッチ（PAGELATCH_SH や PAGELATCH_EX）は、次の図のように、同じページに対して、多数のユーザーからの同時アクセスが発生した場合を制御するためのもので、同時に同じページを操作させないように、後からきたラッチを "待ち" にします（ページ ラッチ待ちの発生）。

更新系のステートメント（INSERT／UPDATE／DELETE）では、PAGELATCH_EX（排他ページラッチ。EX は Exclusive：排他の略）をかけにいき、SELECT ステートメントによる参照時には PAGELATCH_SH（共有ページラッチ。SH は Shared：共有の略）をかけにいきます。このとき、先にアクセスしている処理がある場合は（ラッチが既にかかっている場合には）、それが解放されるまで、"待ち" が発生します。このような、同時アクセスによって待ちが発生する状態は、ラッチ競合（Latch Contention）とも呼ばれています。

このように、ラッチ待ちが発生すると、ユーザー数が増えれば増えるほど、ラッチ待ちも増えることになるので、スループットが低下していきます。

これでは、同時実行数が増えれば増えるほど、システムの処理能力は頭打ちになり、スケールしなくなってしまいます。

これに対して、インメモリ OLTP が採用している、ラッチを利用しない「ラッチ フリー」のアーキテクチャであれば、ユーザー数が増えてたとしても性能低下は発生しにくくなります。

◆ ラッチ待ちが発生しているかどうかを調べる ～Latch Waits/sec～

現在のシステムで、ラッチ待ちが発生しているかどうかは、パフォーマンス モニター（システム モニター）の Latch Waits/sec カウンターを利用して調べることができます。この値が大きい値を示している場合には、ラッチ待ちが多発しているので、インメモリ OLTP 機能による性能向上を享受できる可能性が高くなります。

ラッチ待ちが多発している場合には、次のグラフのように Latch Waits/sec カウンターが跳ね上がります（赤の折れ線がラッチ待ちで、定期的に 15,000ぐらいまで跳ね上がっています）。

このグラフのように Batch Requests/sec（バッチ要求数）と Latch Waits/sec（ラッチ待ち）が連動している場合（跳ね上がる場所が同じ場合）は、複数のユーザーによる同時アクセスが発生していて、ラッチ待ちが原因で性能が頭打ちになっている可能性があるので、このような場合に、インメモリ OLTP 機能を利用することで性能向上を期待することができます。