SQL Server 2016の概要とIn-Memory OLTP の改善点(後編)

柔軟さを増した管理運用機能

　SQL Server 2014 のIn-Memory OLTP関連オブジェクトは管理/運用面からみた場合に、必ずしも扱いやすいものではありませんでした。例えば、メモリ最適化テーブルやネイティブ コンパイル ストアドプロシージャは、一度作成すると変更することができません。またメモリ最適化テーブルのデータ型を変更したり列を追加したりする際には、かならず一旦テーブルを削除しなければなりません。さらにはインデックスの再構築もサポートされていません。そのため(言うまでもなく)メンテナンス作業に多くのコストがかかります。例えばメモリ最適化テーブルに列を追加する場合には、次のような作業が必要になります。

1. 　メモリ最適化テーブル内に蓄積したデータを、別のテーブルあるいはデータベース外へ一旦退避
2. 　メモリ最適化テーブルを削除
3. 　スキーマ変更(列を追加)したメモリ最適化テーブルを再度作成
4. 　退避していたデータを、作成し直したメモリ最適化テーブルへ再度ロード

　このような管理運用面の取り扱いの難しさは、当然In-Memory OLTPの導入を検討する際の大きなハードルとなってきました。そこで SQL Server 2016 では次のような改善が取り入れられます。

メモリ最適化テーブル/ネイティブコンパイルストアドプロシージャ定義の変更をサポート

　最大の懸念(といっても過言ではないと思っています)であった、作成済みのメモリ最適化テーブルおよびネイティブ コンパイル ストアドプロシージャの定義に変更を加えることができるようになります。これによってメンテナンス作業時間が削減でき、従来型のディスク テーブルとほぼ同等の管理面での柔軟性を得ることができます。ただし、次の点に注意が必要です。

　メモリ最適化テーブル定義変更時のメモリ使用量

　メモリ最適化テーブルの定義を変更する際には、通常の2倍のメモリを必要とします。そのため、ハードウェアのサイジングの際には、メンテナンス作業時のメモリ使用量も考慮に入れる必要があります。

　ネイティブ コンパイル ストアドプロシージャとメモリ最適化テーブルの依存関係

　ネイティブ コンパイル ストアドプロシージャは作成時にスキーマバインディング属性が必要となります。そのため、ネイティブ コンパイル ストアドプロシージャが参照しているメモリ最適化テーブル(さらにはネスト実行しているネイティブ コンパイル ストアドプロシージャも含みます)の定義の変更ができません。つまり、メモリ最適化テーブルのスキーマ定義変更を行う際には、そのテーブルを参照しているネイティブ コンパイル ストアドプロシージャを削除する必要があります。

インデックスメンテナンス作業をサポート

　非クラスタ化インデックスの再構築や、非クラスタ化ハッシュインデックスのバケット数変更といったメンテナンス作業がサポートされます。これにより、メンテナンス作業毎にテーブルの削除を行う必要がなくなり、ディスクテーブルと同等のメンテナンス負荷でインデックスの管理を行うことができます。また、非クラスタ化インデックスの再構築/非クラスタ化ハッシュインデックスのバケット数変更に関しては、依存関係のあるネイティブ コンパイル ストアドプロシージャを予め削除しておく必要がありません。この点もメンテナンス性を向上させるポイントといえるでしょう。