SQLServer2008またはSQLServer2008 R2を実行している場合、2019年7月9日 あなたにとって意味がありますか？これらのバージョンのSQLServerの両方が一緒にサポートライフサイクルの終わりに達すると、重要なセキュリティ更新プログラムを取得できなくなります。これにより、組織に深刻なセキュリティとコンプライアンスの問題が発生する可能性があります。

これらのバージョンのSQLServerがリリースされたとき、10年間のサポートが提供されていました。 5年間のメインストリームサポートと5年間の拡張サポート。組織でまだSQLServer2008/2008 R2が運用されている場合、組織はどのようにリスクに対処する予定ですか？厳しく規制されている組織にとって、これは大きな懸念事項です。

移行方法と移行先を選択し、途中で障害にぶつからないようにする必要があります。

移行評価ツール

SQL Server 2008/2008 R2からのアップグレードを計画している場合、Microsoftは、環境のテストと検証をはるかに簡単にしました。移行の評価を支援し、移行タスクを処理することさえできるツールが多数存在しますが、それらはすべてわずかに異なります。これらのツールには次のものが含まれます：

• データ移行アシスタント
• Microsoft Assessment and Planning Toolkit
• Azureデータベース移行サービス
• データベース実験アシスタント

Data Migration Assistantは、最新のデータプラットフォームへのアップグレードに役立ちます。これは、新しいバージョンのSQL Serverの機能に影響を与える可能性のある互換性の問題を検出し、新しい環境のパフォーマンスと信頼性の向上に関する推奨事項を作成することで実現します。ソースは、SQL2012以降およびAzureSQLデータベースをターゲットとするSQLServer2005以降にすることができます。

Microsoft Assessment and Planning Toolkitは長年使用されており、MAPツールと呼ばれることがよくあります。現在の環境のインベントリを作成して、SQL Server（およびその他のアプリケーション）が存在する場所を見つけるのに最適です。

Azure Database Migration Serviceは、既存のツールとサービスの機能の一部を統合して、Azureに移行するための包括的なソリューションをお客様に提供します。このツールは、移行を実行する前に必要な変更をガイドするための推奨事項を提供する評価レポートを生成します。このサービスには現在、VPNまたはエクスプレスルートが必要です。

最後に、Database Experimentation Assistantは、SQLServerアップグレード用の新しいA/ Bテストソリューションであり、使い慣れたツールです。分散再生を利用してワークロードをキャプチャし、ターゲットSQLServerに対して再生します。これは、SQLServerのハードウェアの変更またはバージョンの違いをテストするために使用できます。 SQLServer2005以降からワークロードをキャプチャできます。

移行オプション

オンプレミスアップグレード： 最も簡単な移行方法の1つは、新しいバージョンのSQLServerにアップグレードすることです。この場合、SQL Server 2012、2014、2016、または2017から選択できます。クライアントには、可能な限り最新バージョンにアップグレードすることをお勧めします。 SQL Server 2012はすでにメインストリームサポートを終了し、SQL Server 2014は2019年7月9日にメインストリームサポートを終了します。すべての計画とテストが含まれるため、アップグレードは組織にとって非常に時間とコストがかかる可能性があるため、最新バージョンに移行すると次のアップグレードまでの時間を増やします。また、SQL Server 2016および2017には多くのパフォーマンスと機能の改善があり、現時点ではSQLServer2012または2014への移行は非常に不適切です。

オンプレミスアップグレードの一般的なアプローチは、物理環境または仮想環境に関係なく、新しくビルドして移行することです。新規に構築することで、データベースを復元し、多数のテストと検証を行って、本番環境に移行する前にすべてが期待どおりに機能することを確認できます。

Azure VMにアップグレードして移行する： クラウドへの移行を検討している組織にとって、Azure Infrastructure as a Service（IaaS）は優れたオプションです。 AzureVMでSQLServerを実行することは、オンプレミスによく似ています。 VMのサイズ（vCPUとメモリの数）を指定し、I/Oとサイズの要件に合わせてストレージを構成します。構成とパッチ適用のためにOSとSQLServerをサポートする責任は引き続きあります。 Azure IaaSを使用すると、ワークロードのニーズの変化に応じて仮想マシンのサイズを拡大または縮小することでワークロードを簡単に拡大できます。また、Azure Active Directoryの統合、脅威の検出、およびその他の多くのAzureのメリットを活用できます。

Azure SQLデータベースに移行する： もう1つのオプションは、AzureSQLDatabaseに移行することです。 Azure SQL Databaseは、サービスとしてのデータベースと考えることができ、MicrosoftのPlatform as a Service（PaaS）の一部です。 Azure SQL Databaseの機能はデータベーススコープです。つまり、クロスデータベースクエリ、SQL Serverエージェント、データベースメールなどの特定のものは使用できません。ただし、単一のデータベースを利用するアプリケーションを使用している多くのお客様は、最小限の労力でAzureSQLDatabaseに移行できます。 Data Migration Assistantを使用すると、AzureSQLDatabaseとの互換性をすばやくテストできます。 Azure SQL Databaseを使用すると、DTU（Database Transaction Units）またはvCoresごとにデータベースのサイズを変更したり、データベースをElasticPoolにグループ化したりできます。 Azure SQL Databaseを使用すると、最小限の労力とダウンタイムでリソースをスケールアップおよびスケールダウンできます。

Azure SQLマネージドインスタンスに移行する： 新しいオプション（2018年現在）は、AzureSQLマネージドインスタンスに移行することです。これは、現在10月1日より汎用層で一般提供されている新製品です。管理対象インスタンスは、インスタンスレベルのプログラミングモデルを使用して構築されました。これは、SQLServerのフルバージョンで使用されている機能がサポートされていることを意味します。マネージドインスタンスの目標は、オンプレミスと100％の表面積の互換性を持つことです。インスタンス内のすべてのデータベースは同じサーバー上にあるため、データベースメール、SQL Serverエージェント、サービスブローカーなどと同様に、データベース間のクエリがサポートされます。 2つの価格帯があります。 HAの読み取り不可能なセカンダリを含む汎用、および2つの読み取り不可能なセカンダリと読み取り可能なセカンダリを持つビジネスクリティカル。マネージドインスタンスはMicrosoftのPaaSオファリングの一部であるため、PaaSのすべての組み込み機能を利用できます。

そのままAzure仮想マシンに移動する： SQL 2008 / SQL 2008R2インスタンスをAzureVMに移動した場合、Microsoftは追加料金なしで3年間の拡張セキュリティ更新プログラムを提供します。目標は、準備ができたら、SQLServerの新しいバージョンにアップグレードするための時間をもう少し与えることです。

有料滞在： これは移行オプションではありませんが、最大3年間の拡張セキュリティアップデートを購入するオプションがあります。このオプションには制限があります。エンタープライズ契約に基づいて、これらのインスタンスまたはサブスクリプションライセンスに対してアクティブなソフトウェアアシュアランスが必要です。これが当てはまる場合、このオプションを使用すると、SQL Server2008/2008R2の計画と移行にかかる時間を増やすことができます。

移行のベストプラクティス

移行またはアップグレードを実行するときは、注意が必要な特定の事項があります。まず、ベースラインが必要ですが、これを十分に強調することはできません。環境に変更を加えるときはいつでも、その変更が環境にどのように影響するかを測定できる必要があります。ご使用の環境の主要なパフォーマンスメトリックを知ることは、認識された影響をトラブルシューティングするときに役立ちます。 perfmonとDMVを使用してこれらのメトリックを手動で収集するか、パフォーマンス監視プラットフォームに投資することができます。以前の投稿で両方のテクニックについて詳しく書きましたが、今 SentryOneの45日間の延長評価を取得できます 。 CPU使用率、メモリ消費量、ディスクメトリックなどのベースラインメトリックがあると、アップグレードまたは移行後に状況が良くなったのか悪くなったのかをすばやく知ることができます。

インスタンス内の構成オプションにも注意する必要があります。何度も、アップグレードまたは移行後にSQL Serverインスタンスを確認するように求められましたが、ほとんどの既定の設定が使用されていることがわかりました。古いシステムがまだ利用可能な場合は、それをクエリして、以前のデフォルト以外の値を取得し、それらを新しい環境に適用して、既知の構成に戻すことができます。本番サーバーのsys.configurationsを確認して、新しい環境で同様の変更を行うことを検討することをお勧めします（並列処理のコストしきい値、並列処理の最大度、アドホックワークロードの最適化など）。「検討」と書いたことに注意してください。新しいサーバーでコア数またはメモリが異なる場合は、新しいサーバーのサイズを考慮して設定を構成する必要があります。

物事がうまくいかない場合のあなたのバックアウト計画は何ですか？戻ることができる適切なバックアップがありますか？ほとんどの場合、アップグレードまたは移行では、新しいVMまたは物理サーバーに移動します。フェイルバックは、古いサーバーに戻ることである可能性があります。新しいバージョンのSQLServerでデータを変更した場合、フェイルバックははるかに複雑になります。 SQLServerデータベースのバックアップを新しいバージョンのSQLServerから古いバージョンに復元することはできません。

結論

SQLServer2008またはSQLServer2008 R2をまだ使用している場合は、2019年7月9日以降もコンプライアンスを維持するために、いくつかのオプションを利用できます。SQLServer2008またはSQLServer 2008 R2を継続するには、拡張セキュリティ更新プログラムを購入できます。または、資格がある場合はAzure仮想マシンに移動します。アップグレードできる場合は、オンプレミスまたはAzureVMでサポートされているバージョンのSQLServerに移行するか、AzureSQLデータベースやAzureSQLマネージドインスタンスなどのマネージドソリューションへの移行を検討できます。