前回は基本的な構成について確認してみました。
今回はログファイルについてみていきたいと思います。
Memory Optimized Table もトランザクションログを書き出し、ログファイルに関しては通常のログファイル (ldf) を使用します。
通常のテーブルの動作としては WAL (Write Ahead Log : 先行ログ書き込み) が行われ、操作ログが最初にログファイルに書き込みが行われます。
以下のようなテーブルを作成してみます。
|
CREATE TABLE DataTable |
このテーブルにデータを挿入してトランザクションログの状態を確認してみたいと思います。
|
SET NOCOUNT ON |
トランザクションを開始していますが、COMMIT はしていない状態です。
この状態のレコードに関してはロールバックにより破棄される可能性があることになります。
それではこの操作をした場合のトランザクションログの状態を sys.fn_dblog から確認してみます。 
通常のテーブルではトランザクション中の操作もトランザクションログに書き込みが行われます。
次に以下のような Memory Optimized Table を作成してみます。
|
CREATE TABLE MemTable CONSTRAINT PK_MemTable PRIMARY KEY NONCLUSTERED HASH (Col1) WITH (BUCKET_COUNT = 1024) |
このテーブルに対して先ほどと同じようにデータを挿入してみます。
|
SET NOCOUNT ON |
この状態で確認したトランザクションログがこちらです。
以下のトランザクションログはログレコードの末尾付近の情報となるのですが INSERT に関してのログレコードが記録されていません。 
sys.fn_dblog_xtp という関数が SQL Server 2014 で追加されているのでこちらでも確認してみます。
こちらでも INSERT のログは確認できませんね。 
それではトランザクションを確定するための COMMIT をしてみます。
コミットをしたタイミングで Memory Optimized Table に対しての操作が LOP_HK として記録されていきます。
Memory Optimized Table ではコミット時にログに記録がされます。
コミットをしたタイミングでログファイル / チェックポイントファイルへの書き込みも発生するようです。
実際にはログファイルに書き込みが終われば復旧できる状態は整うため、チェックポイントファイルへの書き込みはバックグラウンドのオフラインチェックポイント処理で操作されているようですね。
Memory Optimized Table 用に XTP_LOG_FLUSH_THREAD / XTP_LOG_COMPLETION / XTP_CKPT_AGENT / XTP_THREAD_POOL / XTP_OFFLINE_CKPT というようなバックグラウンドプロセスが動作していますので、このあたりでチェックポイントファイルへの書き込みも行われていそうですね。
ショートトランザクションの処理であればそれほど気にしないでよいかもしれませんがトランザクションが長い場合にはコミット時のディスク I/O の集中と処理時間については意識しておいたほうがよさそうですね。
ロールバックの際はメモリ上のデータを破棄すればよいだけになるので、WAL を使用していないことの処理性能はこの辺に現れてきそうですね。
この際には、ログレコードをグループ化して、書き込んでいるようで単純な行単位のレコード記録ではないようです。
# LOP_FS_DOWNLEVEL_OP などもストリームデータの書き込みですので Memory Optimized Table の操作になります。 
上記の画像は sys.fn_dblog のものですので sys.fn_dblog_xtp でも情報を確認してみます。
こちらでも操作がされたことが確認できますね。
Memory Optimized Table についてのログはこちらのほうがレコード数が多いため、確認はこの関数から行ったほうがよさそうです。 
トランザクションログの書き込みについても今までの動作とは少し異なってきますのでこの辺もしっかり意識しておきたいですね。
いちからはじめる Memory Optimized Table その 1
いちからはじめる Memory Optimized Table その 2 ←今回の投稿
いちからはじめる Memory Optimized Table その 3