SQL Server 2017へのアップグレードの方法とアップグレード時の懸念点について

２．アップグレード時の懸念点

　SQL Serverをアップグレードした後で、アプリケーションや運用にどのような影響が発生するのでしょうか？　SQL Serverのアップグレードは弊社でも過去に何度も実施したことがありますが、スムーズに移行されるケースが多いように思います。その中でも比較的問題になるケースが多いのが性能問題です。

　SQL Serverでは、よりよい実行プランを作成するためにオプティマイザの機能を常に改善しています。例えば、SQL Server 2014では基数推定（カーディナリティ推定）ロジックという機能が再設計され、SQL Server 2017ではAdaptive Queryという機能が追加されています。これによりあるクエリの実行プランが変わりパフォーマンスが改善されるケースもありますが、一方で、稀に最適ではない実行プランが選択されるケースがあり、これにより性能が劣化する場合があります。このため、SQL Server 2017の環境で事前にアプリケーションテスト等で性能を確認しておく必要があります。

　とはいえ、アップグレード時の性能問題についてはSQL Serverに限った話ではなく、移行を計画した時点で誰もが気になる点だと思いますが。

　性能以外での懸念点としては、以下が挙げられます。

　①廃止機能の使用

　②互換性レベルの影響

　③masterデータベースの移行

① 廃止機能の使用

　性能問題同様、SQL Serverに限らずどのRDBMSやその他のアプリケーションでも同じですが、SQL Server 2008から2017までの間で廃止や仕様変更によりアプリケーションに影響がある可能性があります。

　以下、SQL Server 2008以降で廃止された機能や重大な変更になります。

• SQL Server 2016 で廃止されたデータベース エンジンの機能
• SQL Server 2014 で廃止されたデータベース エンジンの機能
• SQL Server 2012 で廃止されたデータベース エンジンの機能
• SQL Server 2017 (14.x) におけるデータベース エンジン機能の重大な変更
• SQL Server 2016 におけるデータベース エンジン機能の重大な変更
• SQL Server 2014 におけるデータベース エンジン機能の重大な変更
• SQL Server 2012 におけるデータベース エンジン機能の重大な変更

　データベースエンジンに対する大幅な変更や廃止された機能はありませんが、影響が大きい仕様変更もありますので、アップグレード前にご確認いただければと思います。

　例えば、暗号化のアルゴリズムはSQL Server 2016以降AES_128、AES_192、AES_256 以外のすべてのアルゴリズムが使用できなくなっています。この為、SQL Server 2008でRC4などの暗号化アルゴリズムを使用している場合、SQL Server 2017ではこのような古いアルゴリズムを見直す必要があります。

　ちなみに、RC4などの非推奨の暗号化アルゴリズムを使用したSQL Server 2008をSQL Server 2017に移行（アップグレード）した場合、アップグレード自体はエラーが発生せず正常に完了してしまいます。ただ、対称キーに対するALTER文は実行できなくなってしまう為、例えば移行後にパスワードを追加しようとしてALTER SYMMETRIC KEYを実行した時に、以下のようなエラーが発生してしまいます。

メッセージ 33128、レベル 16、状態 3、行 37
​暗号化は失敗しました。キーでは、この db 互換性レベルでサポートされなくなった非推奨のアルゴリズム 'rc4' を使用しています。このキーを今後も使用する必要がある場合、より低い db 互換性レベルに切り替えてください。

　この場合だと、移行時には気づかずに運用後に初めて気づく、という可能性も考えられますので、廃止された機能を使用していないかについては十分ご確認いただければと思います。

② 互換性レベルの影響

　SQL Serverには互換性レベルという機能があります。

　アップグレードはしたいけど、アプリケーションへの影響が心配というような場合に、SQL Server 2017のインスタンス上で下位バージョンと同等に動作させることが可能です。

SQL Serverの互換性レベル（バージョン毎）

　ただし、この互換性レベルが通常よりも低い場合に問題が発生する可能性があります。具体的には、稼働中のSQL Server 2008のデータベースがSQL Server 2000や2005をアップグレードしており、アップグレード前の互換性レベルをそのまま使用しているような場合です。

　SQL Server 2017ではSQL Server 2008より以前のSQL Server 2000や2005の互換性レベル（80や90）を使用することができません。この為、SQL Server 2017にそれ以前の互換性レベルを使用したデータベースを適用した場合、自動的に互換性レベルが100に引き上げられてしまいます。これにより、例えば、互換性レベルが80の時に使用可能だった外部結合の書き方（「*=」や「=*」のような記述）をしたクエリがエラーになる等、問題が発生する可能性があります。

　SQL Server 2005以前のデータベースをSQL Server 2008にアップグレードしたことがある環境では特に注意が必要です。

　ちなみに、互換性レベルが100のままSQL Server 2017で使用しても前回ご説明したクエリストアや列ストアインデックス、オンライン再構築等の機能も使用可能ですが、一部の機能に制限が発生したりする場合があるので、可能であればSQL Server 2017の互換性レベルに変更することをお勧めいたします。

③ ユーザーデータベース以外のメタデータの移行

　インプレースアップグレードの場合は問題ありませんが、別環境のSQL Serverにデータベースを移行する場合、気を付けておきたいポイントとして、ユーザーデータベース以外の移行があります。

　SQL Serverは、バックアップ/リカバリやデタッチ/アタッチ等を使用してユーザーデータベースをまるごと移行することができます。ただし、ユーザーデータベース以外で管理されているメタデータは、データベースとは別に手動で移行する必要があります。

　例えば、リンクサーバーやフルテキストインデックス、ジョブエージェント等、以下にあるような機能や設定については、ユーザーデータベースとは別に移行する必要があります。

移行が必要なメタデータ

• サーバー構成オプションの指定
• 資格情報
• 複数データベースにまたがるクエリ
• データベースの所有権
• 分散クエリおよびリンク サーバー
• 暗号化データ
• ユーザー定義エラー メッセージ
• イベント通知と Windows Management Instrumentation (WMI) イベント (サーバー レベル)
• 拡張ストアド プロシージャ
• Full-Text Engine for SQL Server プロパティ
• ジョブ
• ログイン
• アクセス許可
• レプリケーションの設定
• Service Broker アプリケーション
• スタートアップ プロシージャ
• トリガー (サーバー レベル)

　以上、アップグレードの方法とその懸念点についてご説明しました。SQL Serverのデータベースエンジン自体に大幅な変更はないので、上記のような点を事前に調査頂き、安全に移行していただければと思います。

　次回は、このような調査を容易にするためのアップグレードツールについてご紹介したいと思います。

【参考資料】『SQL Server 2016 実践シリーズ No.1 SQL Server 2016 への移行とアップグレードの実践』の無料ダウンロードはこちらからどうぞ！