SQL Server 2008がリリースされてからSQL Server 2017まで既に10年経過しており、その間にメジャーバージョンも2012,2014,2016そして現在の2017と4回行われています（2008 R2も入れると5回）。
当然のことながら、その間に様々な機能が追加されており、2008にはなかったような便利な機能も多数搭載されています。
であれば、サポート切れにより仕方なくアップグレードというネガティブな理由だけでなく、バージョンアップすることでSQL Server 2008ではなかったようなメリットが受けられるかもしれません。
そこで今回は、SQL Server 2008ユーザーが2017にアップグレードすることで得られるメリットについてご紹介していきたいと思います。
| 発売製品 | ライフサイクルの開始日 | メインストリームサポートの終了日 | 延長サポートの終了日 |
| Microsoft SQL Server 2008 Enterprise | 2008/11/07 | 2014/7/8(Service Pack 4) | 2019/7/9(Service Pack 4) |
| Microsoft SQL Server 2008 R2 Enterprise | 2010/7/20 | 2014/7/8(Service Pack 3) | 2019/7/9(Service Pack 3) |
１．パフォーマンスの向上
集計処理のパフォーマンスを大幅に改善可能な機能である列ストアインデックスや、IOが発生しない為高速に処理可能なインメモリOLTPなど、SQL Server 2008以降でパフォーマンス向上につながる機能が多く追加されています。特に、列ストアインデックスについては、データ量が多ければ多いほど効果があるので、例えば夜間バッチの集計で数時間かかっていたような処理が数分で終わるようになった、なんてこともありえるかもしれません。
また、SQL Server 2016 以降は、列ストアインデックスと従来のインデックス（またはインメモリOLTP）を組み合わせることもできるようになっています。これにより、従来はOLTP用とDWH用のデータベースを別々に構築していたようなケースも、同一データベース上で構築することができるかもしれません。
（出典：有限会社エスキューエル・クオリティ『SQL Server 2016 への移行とアップグレードの実践』）
(出典：有限会社エスキューエル・クオリティ『SQL Server 2016 への移行とアップグレードの実践』)
【参考資料】『SQL Server 2016 実践シリーズ No.1 SQL Server 2016 への移行とアップグレードの実践』の無料ダウンロードはこちらからどうぞ！
２．セキュリティの向上
SQL Serverでは、SQL Server 2008以降で様々なセキュリティの機能が追加されています。例えば、動的データマスキングでは、接続するユーザー毎にデータをマスクしてくれる機能で、あるユーザーには機微な情報を表示させたくないような場合に有効です。
この機能は、接続するユーザー側の設定だけでよいのでアプリケーションの改修無しでセキュリティを向上させることができます。
さらには、行レベルのセキュリティやAlways Encryptedなど、SQL Server 2008と比較してセキュリティを向上させる機能が多く追加されています。SQL Server 2017の機能を使用して、よりセキュアなデータベースに移行することも可能であると言えます。
３．運用系機能の向上
SQL Server 2008以降、運用系の機能も色々と追加されています。例えば、インデックスの作成や再構築、削除がSQL Server 2012からオンラインで実行できるようになっています。今までは、サービスを停止してインデックスのメンテナンスをしていたというケースもあったと思いますが、SQL Server 2017にアップグレードすることでこのような運用を改善することができます。
また、SQL Server 2017からは再開可能なインデックスの再構築という機能も追加されました。これは、インデックスを再構築中に途中で停止することができる機能で、例えば予定時間内に再構築が終わらなかった、という場合でも再構築を一時停止して別日に再度実行する、ということが可能になります。どちらも運用者にとっては非常にありがたい機能と言えます。
また、SQL Server 2016で追加されたクエリストアという機能も運用者にとって非常に重宝する機能といえます。
あるバッチ処理が突然遅延した時に、運用者はどのクエリが何故遅延したのかを調査する必要があります。SQL Server 2008でこのような事象が発生した場合、どのSQL文が遅延したかをアプリケーションのログやDMVなどで調査し、そのSQL文に対して過去の実行プランと同じになるようにヒント句を作成し、アプリケーションを修正するというようなことが必要でした。
ただ、DMVに、その情報がメモリからキャッシュアウトされていたり、実行時の情報が更新されていたりして、「問題が発生した際の情報」「問題が発生する前の情報」を確認できないで苦労した方も多かったのではないでしょうか。SQL Server 2017では、クエリストアを使用することで、どのクエリが何故遅延したのか、遅延した時点とそうでない時は何が違うのかを比較しながら確認することができるようになっています。さらに、遅延したクエリに対して、アプリケーションの書き換え無しで遅延前の高速な時の実行プランで固定化することができるようになっています。
【参考資料】『SQL Server 2016 実践シリーズ No.1 SQL Server 2016 への移行とアップグレードの実践』の無料ダウンロードはこちらからどうぞ！
４．エディションに依存しない開発
SQL Server 2017ではエディションを意識しない開発が可能になっています。どういうことかというと、例えば、あるシステムで当初はStandard Edition（SE）を使用していたが、データ量やアクセス数の増加によりEnterprise Edition（EE）にアップグレードする場合があったとします。
この時に、アプリケーションとしてSEで開発していると、SQL ServerのアップグレードによりSQL Serverだけでなく、アプリケーションもEE向けに書き換える必要が出てきます。例えば、パーティションを使用していて、パーティションを考慮したクエリに書き換えるなどアプリケーション側でも考慮が必要なケースが発生します。
SQL Server 2017だと、SEでもパーティションの機能を使用することができるので、SEの段階でパーティションを使用して開発しておき、データベースだけエディションをEEに変更する、ということも可能になります。これは、ISVのようなパッケージ製品を開発している会社にもメリットがあるケースがあります。例えば、パッケージ製品で使用するDBのエディションを、顧客の規模や要件に合わせて切り替えているようなケースです。
このような場合、EE用とSE用でソースを分けて管理していることがあり、ソース修正時のメンテナンス性が落ちてしまうことがあります。SQL Server 2017にすれば、共通のソースを管理すればよくなる為、エディション毎の管理から解放されます。
共通ソースの管理
もちろん、SQL Server 2008でSEを使用していて、アップグレード時にパーティションを使用する、ということもできるので、SEのデータベース上に数百GBのテーブルがあるような環境であれば、SQL Server 2017への移行時にパーティションテーブルに切り替えることで、パフォーマンスが劇的に改善する、なんてことがあるかもしれません。
SQL Server 2017のエディション毎の機能差については、こちらをご参照頂ければと思います。
パーティション以外にも、先ほどご紹介した列ストアインデックスや、セキュリティの機能なども使用可能なので、SEを使用している環境であれば、バージョンアップするだけでEEにアップグレードしたようなメリットが得られる可能性があります。
***
以上、SQL Server 2008からアップグレードすることで使えそうな機能について解説してきました。SQL Server 2017にすることでSQL Server 2008にはなかった便利な機能が使えそう、ということはご理解いただけたかと思います。では、実際にアップグレードしようした時に、何か問題が発生したりすることはないのでしょうか。
次回は実際のアップグレード時に気にすべきところについてお話したいと思います。
