SQL Server 2017 への移行とアップグレードの実践（AD）

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

2018/07/04 06:00

通知

　前回は、SQL Serverをアップグレードすることで得られるメリットについてご紹介しました。では具体的にアップグレードする場合の方法と、アップグレード時の懸念点についてお話ししていきたいと思います。

通知

１．アップグレードの方法

　まず、アップグレードの方法ですが大きく分けて2つあります。1つは、既存環境のSQL Serverをアップグレードする方法（インプレースアップグレード）で、もう1つは新しい環境を構築し、データベース（データ）を移行してアップグレードする方法（移行）になります。

　インプレースアップグレードで既存環境のSQL Server 2008をアップグレードする場合、以下バージョンからのアップグレードのみサポートされます。

SQL Server 2008 SP4 以降
SQL Server 2008 R2 SP3 以降

　アップグレードの詳細はこちらに記載されておりますので、ご確認ください。

　実際にアップグレードする場合、インプレースアップグレードより移行を選択するケースが多いと思います。これは、アップグレード後のテストができない（別環境を用意しないといけない）ことや、万が一アップグレードに失敗した場合に切り戻しが難しいこと、ハードウェアのEOSLやOSのサポート切れのタイミングと合わせて実施することが多い等の理由が挙げられるかと思います。

　では、データベースを別環境に移行してアップグレードする場合、移行にはどのような方法があるのでしょうか？

　具体的な移行方法は以下となります。

a．デタッチアタッチの機能を使用してデータファイルを新環境にコピー

b．既存バックアップデータを使用して新環境にリカバリ

c．ログ配布やSSISなどSQL Serverの機能を使用した移行

d．Attunity Replicateなどサードパーティのツールを使用した移行

　aについては既存データベースを停止する必要がありますが、bからdはオンラインで実施可能であり、ダウンタイムも抑えることができます。既存環境への影響やダウンタイムなどの移行要件に合わせて移行方法を検討する必要があります。

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

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

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

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

※互換性レベルが140の場合。100であればエラーにはなりません。

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

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

② 互換性レベルの影響

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

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

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

SQL Serverのバージョン	互換性レベル
Microsoft SQL Server 2008 R2	100
Microsoft SQL Server 2012	110
Microsoft SQL Server 2014	120
Microsoft SQL Server 2016	130
Microsoft SQL Server 2017	140

　ただし、この互換性レベルが通常よりも低い場合に問題が発生する可能性があります。具体的には、稼働中の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の互換性レベルに変更することをお勧めいたします。