メモリ最適化テーブルを使用してデータベースを復旧または復元する基本的なメカニズムは、ディスク ベーステーブルのみのデータベースと似ています。 ただし、ディスク ベースのテーブルとは異なり、データベースをユーザー アクセスに使用できるようにするには、メモリ最適化テーブルをメモリに読み込む必要があります。 これにより、データベースの復旧に新しいステップが追加されます。 データベース復旧の変更された手順は、次のように変更されます。
SQL Server が再起動すると、各データベースは次の 3 つのフェーズで構成される復旧フェーズを経ます。
分析フェーズ。 このフェーズでは、アクティブなトランザクション ログに対してパスが行われ、コミットされたトランザクションとコミットされていないトランザクションが検出されます。 インメモリ OLTP エンジンは読み込むチェックポイントを識別し、システム テーブルのログ エントリを再度読み込みます。 また、一部のファイル割り当てログ レコードも処理されます。
やり直しフェーズ。 このフェーズは、ディスク ベース テーブルおよびメモリ最適化テーブルで同時に実行されます。
ディスク ベース テーブルの場合、データベースが現在の状態に移動され、コミットされていないトランザクションに使用されたロックを取得します。
メモリ最適化テーブルの場合、データとデルタ ファイルのペアのデータがメモリに読み込まれ、最後の永続的チェックポイントに基づいてアクティブなトランザクション ログでデータが更新されます。
ディスク ベースのテーブルとメモリ最適化テーブルに対する上記の操作が完了すると、データベースにアクセスできます。
元に戻す段階。 このフェーズでは、コミットされていないトランザクションはロールバックされます。
メモリ最適化テーブルをメモリに読み込むと、目標復旧時間 (RTO) のパフォーマンスに影響する可能性があります。 データ ファイルおよびデルタ ファイルからメモリ最適化データを読み込む時間を短縮するために、インメモリ OLTP エンジンは次のように並行してデータ ファイルおよびデルタ ファイルを読み込みます。
デルタ マップ フィルターの作成。 デルタ ファイル ストアは、削除された行を参照します。 コンテナーごとに 1 行のスレッドがデルタ ファイルを読み取り、デルタ マップ フィルターを作成します。 (メモリ最適化データ ファイル グループには、1 つ以上のコンテナーを含めることができます)。
データ ファイルのストリーミング。 デルタ マップ フィルターが作成されると、論理 CPU と同数のスレッドを使用してデータ ファイルが読み取られます。 データ ファイルを読み取る各スレッドは、データ行を読み取り、関連付けられているデルタ マップをチェックし、この行が削除済みとしてマークされていない場合にのみ、行をテーブルに挿入します。 回復のこの部分は、以下に示すように、場合によっては CPU バインドされる場合があります。
メモリ最適化テーブルは、通常、I/O の速度でメモリに読み込むことができますが、データ行のメモリへの読み込みが遅くなる場合があります。 特定の場合を次に示します:
ハッシュ インデックスのバケット数が少ない場合、過剰な競合が発生し、データ行の挿入が遅くなる可能性があります。 これは一般に、全体にわたって、特に復旧の終了に向けて、非常に高い CPU 使用率になります。 ハッシュ インデックスを正しく構成した場合、復旧時間には影響しません。
1 つ以上の非クラスター化インデックスを持つ大きなメモリ最適化テーブル。バケット数が作成時にサイズ設定されるハッシュ インデックスとは異なり、非クラスター化インデックスは動的に増加し、CPU 使用率が高くなります。
メモリ最適化テーブルを使用したデータベースの復元
サーバー上にデータベースを復元するのに十分なメモリがあることはわかっていますが、データベースに必要なメモリが既存のリソース プールの一部として考慮される必要があります。 データベースが存在する前にリソース プールへのバインドを作成できないことがわかっているので、復元 WITH NORECOVERY を実行します。 これにより、データベースのディスク イメージが復元され、データベースが作成されますが、データベースがオンラインにならないため、In-Memory OLTP メモリは消費されません。
この時点で、リソース プールからデータベースへのバインドを作成し、RESTORE WITH RECOVERY を使用して復元されたデータベースをオンラインにすることができます。 データベースをオンラインにする前にバインドが行われるので、In-Memory OLTP メモリの消費量が適切に考慮されます。 これには、データベースを 1 回だけ復元する必要があります。 最初の RESTORE コマンドは、バックアップ ヘッダーのみを読み取る情報コマンドであり、最後のコマンドは、実際にビットを復元せずに回復をトリガーするだけです。