SQL Server サーバ移行手順と注意点【SQL Server 2005→2017】

どうも、Wazです。

先日、アプリのデータベースとして使用しているSQL Serverのサーバ本体の入れ替え行いました。その時にいろいろ調べたりしたので、手順や注意点などを紹介します。

移行手順

移行手順はざっくりと以下の流れです。

①移行元と移行先の環境確認・比較

まずはそれぞれの環境を確認します。

サーバOSが最新になるので、SQL Serverのバージョンも上げることにしました。

今回は最新の2019ではなく、一つ前の2017を選択しています。2017でもサポートは「2027/10/12」までとなっているので、今のところ問題ないかと思います。

②SQL Serverのバージョンアップに伴う影響確認

SQL Serverのバージョンが上がることで重要になってくるのが「DB互換性レベル」です。

バージョンごとに既定のレベルがあり、それぞれのバージョンでサポートしているレベルも決まっています。

今回、元の環境では互換性レベル「80（SQL Server 2000）」で運用していました。

つまり、新しい環境のSQL Server 2017でDBを復元すると、サポートしている互換性レベルの中で一番低い「100（SQL Server 2008）」で復元されます。

このままでもDBは問題なく復元できるのですが、SQL Server 2017の最新機能は使えません。

また互換性レベルが変わることにより、使えなくなる機能などがあるため、該当するものがないか一通り確認します。
データベースエンジンのアップグレードに関する問題

私のところでは「ORDER BY 句の列の別名をテーブル別名によってプレフィックス指定できない」というものだけ該当しました。

ただし、これが結構厄介なやつでした。

例えば次のようなSQLです。

Shainテーブルから、FastNameとLastNameを取得し、LastNameの昇順で並び替えています。

この中で、s.LastNameを「ln」という別名にしているにも関わらず、ORDER BY句でプレフィックス「s.」としているところが問題の箇所です。

これがレベル80（SQL Server 2000）では正常に動作するが、レベル100（SQL Server 2008）ではエラーになります。

SQLの話なので、DBを復元＆アップグレードしただけでは気付けません。
アプリを実行して初めて判明するのです。本当に厄介です。

まぁこんな書き方あまりしないとは思いますが、1つでもあった以上、調べない訳にはいかないです。

ということで、SQL Serverにデータアクセスしているアプリ20個くらいで使っているSQLを全部調べました。

といってもさすがに全てのSQLを一から見ていくのは大変なので、関数などを起点に検索をかけ、該当SQLをチェックするという流れをとりました。

そもそも別名を使うのは何等かの関数などを利用するはずという考えからです。

一応参考までに以下のようなもので検索しました。

③影響のあるアプリの修正

②で検索した結果、たぶん何百かあるSQLのうち、数か所だけ該当の使い方をしている箇所がありました。

修正は簡単で、基本的にはORDER BY句のプレフィックスを削除するだけで完了です。

ざっくり調査99%、修正1%というような作業工数でした。

④DB移行

ここまでで準備は完了なので、あとはDBを移行していきます。

DB移行はいろいろなサイトで情報が載っているのではここでは省略しますが、ざっくりと以下の流れです。

　・現在のDBをバックアップ
　・新規のDBへ復元
　・ログイン設定
　・メンテナンス設定（バックアップなど）

　以上

まとめ

ということで、本記事は「SQL Server サーバ移行手順と注意点【SQL Server 2005→2017】」について書きました。

今回SQL Server 2005→2017と、結構バージョン差がある中での移行でしたが、やってみて思ったのは「意外にもすんなり移行できた」です。

バージョンアップって何かいろいろ面倒だな～と後回しにしがちですが、こんなにすんなりいくならもっと早くできたかなーとちょっと反省。

だけど今回2017まで上げたので、これであと7年は大丈夫ですね(^^♪