SE の雑記

Memory Optimized Table のデータの実体はメモリ上に配置されることになります。
データの永続性の指定として DULABILITY = SCHEMA_ONLY / SCHEMA_AND_DATA を設定し、永続化をするかを指定することになります。

SCHEMA_ONLY に関して再起動時にはスキーマの情報のみが再読み込みされれば再起動前と同じ状態にすることができますが、SCHEMA_AND_DATA の場合にはデータの読み込みも必要となります。

Memory Optimized Table を使用している場合には起動時に、

• Memory Optimized Table のコンパイル
• チェックポイントファイルからのデータの読み込み
• 未適用のログレコードの適用

が発生することを意識しておく必要があります。
Memory Optimized Table のテーブルは、内部ではネイティブコードにコンパイルされています。
テーブルを作成した時には作成したタイミングでコンパイルがされますが、以降はサービスの再起動のタイミングで再度コンパイルされることになるようです。

チェックポイントファイルからのデータ読み込みの詳細に関しては Storage に記載されています。
Memory Optimized Table を使用している場合は再起動時にチェックポイントファイル (データファイル / 差分ファイル) からデータを読み込み、メモリ上にデータを復元する必要があります。
# 差分ファイルのデータを差分用のマップ領域にロードし、そこをフィルタしてデータファイルを読み込み、Memory Optimized Table にロードしているようですね。

この際、複数のファイルを並列でロードすることで読み込みのトラフィックを最適に発生させるようになっています。

通常のテーブルであれば、データの読み込みは必要になった時に行われるため、起動時にはロールバック / ロールフォワードといったログ適用の時間を考慮しておく必要がありますが、Memory Optimized Table を使用している場合にはログ適用の時間の他にチェックポイントファイルのロードも軌道に必要な時間として考慮しておく必要が出てきます。

SCHEMA_AND_DATA を使用している場合には、Memory Optimized Table を使っていてもディスクの I/O については考慮する必要が出てきます。
メモリ上にデータを格納しているとはいえ、一貫性や耐障害性を保つためにログレコードは記録されます。
ログレコードの記録はトランザクションの完了速度にも影響してきますので、PCI-E ベースのフラッシュメモリの使用が推奨されています。

データファイルの読み込みに関しては、再起動時の復旧時間に影響してきます。
Memory Optimized Table のデータはシーケンシャルに書き込みされているため、読み込みを行う際も各ファイルをいかにして効率よくシーケンシャルに読み込むかということを考慮する必要が出てくるかと。
通常のテーブルと同じで専用のディスクを用意し、複数のディスクでストライピングするといったことがパフォーマンスを考える中で重要になってくると思います。
# 現状、ファイルサイズには制限があるようですので、スロットが空いていれば PCI-E のフラッシュメモリでもよいかもしれませんが。

待ち事象 にも Memory Optimized Table 用の新しい型が追加されており、XTP_HOST_LOG_ACTIVITY / WAIT_XTP_OFFLINE_CKPT_NEW_LOG / WAIT_XTP_OFFLINE_CKPT_NEW_LOGというようなログやチェックポイントに関しての項目を取得できるようになっています。
起動時の REDO / UNDO の復旧処理などは WAIT_XTP_RECOVERY から確認することができそうです。

SQL Server の ERRORLOG には、

というように、サーバー起動時のデータベースの復旧にかかった時間を取得することができますので、ここか起動に必要だった時間を確認することもできるかと。

メモリに最適化されたテーブルとはいえ、ディスクの考慮も必要となってきますので、最適なディスク構成は意識しておきたいですね。

いちからはじめる Memory Optimized Table その 1
いちからはじめる Memory Optimized Table その 2
いちからはじめる Memory Optimized Table その 3
いちからはじめる Memory Optimized Table その 4 ←今回の投稿