１．Data Migration Assistant（DMA）
DMAは、データベースの互換性を検証するツールです。
アップグレードをしようとした時に最も気になる点は、SQL Serverをバージョンアップした時にどれぐらい影響があるかだと思います。アップグレード時に廃止される機能、非サポートの機能がシステムでどれぐらい使用されているを確認する為には多くの時間が必要です。
このツールを使用することで、アップグレードにより互換性に影響がある箇所を洗い出してくれます。
DMAのインストール
DMAのシステム要件やダウンロードサイトはこちらをご確認ください。
移行元データベースの互換性を確認するツールなので、互換性を確認するだけであれば移行先の環境は必要ありません。また、対応OSはWindows Server 2012以上なので、SQL Server 2008で使用している可能性が高いWindows Server 2008では動かず、自PCや別サーバーにDMAをインストールして、リモートで接続する必要があります。ちなみに、移行対象としてAzure SQL Databaseにも対応しているので、Azureへの移行を検討している方にも使えそうです。
DMAの使用
実際にDMAを使用してみます。今回使用するバージョンは、3.4になります。DMAを起動すると、以下の画面が立ち上がります。「＋」ボタンをクリックして、プロジェクト情報を指定します。
- Project Type：Assessment/Migrationを指定
- Migrationを選択すると、データを移行することが可能。評価の場合Assessmentを選択
- Project name：任意のプロジェクト名
- Source server type：SQL Serverのみ
- Target server type：SQL Server/Azure SQL Database/SQL Server on Azure Virtual Machines
設定後、Createをクリックしてプロジェクトを作成します。
次に、レポートに出力したい評価内容を選択します。
- Select target version：移行対象のSQL Serverのバージョンを指定
- Select report type
- Compatibility Issues：互換性に問題がある機能の提示
- New features’ recommendation：推奨機能の提示
- Check feature parity：SQL Server 2017 on Linuxを指定した場合の互換性を提示
上記設定後、Nextをクリックします。
最後に評価対象のデータベースを指定します。接続するサーバーのサーバー名と認証タイプを指定し、次の画面で評価したいデータベースを選択します。
選択後、Start Assessmentをクリックすると、評価が開始されます。
レポート
出力されたレポートが以下になります。
アップグレードで影響がある箇所がCompatibility（互換性レベル）毎にレポートされています。上記だと、tpccというデータベースでUnqualified Join(s) detectedという仕様変更が発生する可能性があり、dbo.newordプロシージャとdbo.slevで使用していると指摘されています。ちなみにこの指摘は、テーブル結合の記載でINNER JOIN等を使用せずにWHERE句でa.col1 = b.col1のように記載していると稀に直積結合になる可能性がある為、INNER JOINの使用を推奨しています。
このように、問題箇所とその機能を使用しているオブジェクトをレポートで確認できるので、アップグレードによる互換性の問題箇所を簡単に特定することができます。ただし、レポートの対象はシステムの全てではなくSQL Serverのデータベース内にあるオブジェクトであり、アプリケーション側のクエリは当然ながら対象外ですので、この点はご注意いただければと思います。
【参考資料】『SQL Server 2016 実践シリーズ No.1 SQL Server 2016 への移行とアップグレードの実践』の無料ダウンロードはこちらからどうぞ！
２．Database Experimentation Assistant（DEA）
次に、DEAというツールをご紹介します。DEAはアップグレードによりパフォーマンスに差異があるかどうかを分析することができるツールです。
DEAの機能としては、Capture,Replay,Analysisの3つがあります。
- Capture：ワークロードをキャプチャする機能
- Replay：キャプチャしたワークロードを別環境で再現する機能
- Analysis：ワークロードの結果を分析してレポートする機能
実際のアップグレードでは、以下のような使い方が考えられます。
- 本番環境でワークロードをキャプチャ
- １のワークロードをステージング環境と移行先環境で再現
- ステージング環境と移行先環境で何が遅延したか確認
DEAインストール
DEAのシステム要件やダウンロードサイトはこちらをご確認ください。
対応OSがWindows Server 2012以降なので、DMA同様Windows Server 2008では動作しないのでご注意ください。
DEAの使用
DEAを使ってみましょう。
今回、移行を想定した以下のような検証環境を作成しています。また、DEAのバージョンは2.6を使用しています。
0．起動
DEAを起動すると、以下のような初期画面が表示されます。
１．Capture
ワークロードをキャプチャする機能を実行します。キャプチャは移行元の本番環境から取得することを想定しています。
- Capture name：任意の名前
- Format：SQLトレース/Xeventsを選択 ―Xeventは動作せず。恐らく、SQL Server 2008には対応していないと思われる
- Duration：キャプチャする間隔（分）
- Capture Location：キャプチャしたトレースファイルの出力先―キャプチャするSQL Server側に出力されます
- Server Type：SQL Server/AzureSqlDb/AzureSqlManagedInstanceを選択
- Server name：サーバー名かIPアドレスを指定
- Authentication Type：Windows認証/SQL認証を選択
- Database name：キャプチャするデータベース（任意）。
上記を指定後、Startを押下すれば、キャプチャがスタートします。
Capture DetailsのPROGRESSが設定したDurationからカウントダウンされ、0になったらキャプチャ終了です。
終了後、Capture LocationのフォルダにMinimum_[Capture Name]x.trcというトレースファイルが出力されています。このトレースファイルが取得したワークロードになります。
２．Replay
次に、1でキャプチャしたワークロードを別環境で実行します。
トレースファイルをDEAがインストールされている環境に移動します。
DEAで取得したワークロードを別の環境で実行します。
- Replay name：任意の名前
- Source Trace Format：SQL Trace/Xeventsを選択―キャプチャ時に指定したトレースフォーマットを指定
- Source Trace Location：local/Blob。キャプチャしたファイルの保存先
- Full path to source file：キャプチャしたファイルのパス
- Replay Tool：Dreplay/Inbuiltを選択―Trace FormatがSQL Traceの場合、Dreplayを選択
- Controller machine name：リプレイコントローラーがあるホスト名
- Replay Trace Location：リプレイ時のトレースファイルの保存先
- Server Type：SQL Server/AzureSqlDb/AzureSqlManagedInstanceを選択
- Server name：サーバー名かIPアドレスを指定
- Authentication Type：Windows認証/SQL認証を選択。―Dreplayの場合Windows認証にする必要があります
- Database name：キャプチャするデータベース。未指定の場合全データベースが対象
Startを実行すると、対象環境に対してキャプチャしたワークロードが実行されます。実行後、対象サーバー上にリプレイ時のトレースファイルが作成されます。
【参考資料】『SQL Server 2016 実践シリーズ No.1 SQL Server 2016 への移行とアップグレードの実践』の無料ダウンロードはこちらからどうぞ！
３．Analysis
最後に、2で取得した結果を分析し、レポートを表示します。分析データはSQL Server上のデータベースとして保存されます。ちなみに、今回はDEA環境にDEA用のSQL Serverを導入していますが、別環境のSQL Serverを使用することも可能です。
接続先のサーバー名と接続タイプ（SQL Server認証/Windows認証）を指定します。
次に、分析用のトレースファイルを指定してStartをクリックします。
実際に作成されたレポートが以下になります。
上記だと、Degrated（性能劣化）が83%、Improved（改善）が10.6%、Cannot Evaluate（評価不能）が3.8%、Same（同等）が2.6%となっており、性能劣化したクエリが多く存在していることがわかります。グラフをクリックすることで、クエリを確認することができます。
ちなみに、Cannot Evaluateは実行回数が少ない為評価ができないクエリになります。DEAはExecutionsが少なくとも30回実行されている必要がある為、あまり短い時間を指定したり処理量が少ない環境で実行しても評価されない可能性がありますので、検証時にはご注意ください。
さらに、クエリをクリックすることで、遅延したクエリの実行状況を確認することができます。
最後に
DMA、DEAについてご紹介しました。DMAでSQL Serverの機能的な互換性、DEAで性能を簡単に確認できることがご理解いただけたかと思います。システムが大きければ大きいほどアップグレードによる影響範囲を確認する作業も大変になってきますので、これらのツールを使用して少しでも楽で安全にアップグレードを進めていただければと思います。
