SQL Server 2017の新機能を徹底解説：DBAが知っておくべき主要な変更点

SQL Serverをより新しいバージョンにアップグレードすることを検討していますか？SQL Server 2016とSQL Server 2017のどちらを選ぶか迷っているのであれば、本記事で解説する理由から、SQL Server 2017へのアップグレードをおすすめします。

SQL Serverの新バージョンのリリースは、データベース管理者や開発者にとって興味深い新機能の宝庫です。SQL Server vNext（一般にSQL Server 2017と呼ばれます）のCommunity Technology Preview（CTP）2.0も例外ではありません。既存の機能やサービスには数多くの更新が実装されています。この記事では、データベース管理者（DBA）の視点から、SQL Server 2017のデータベースエンジンにおける新機能について詳しく見ていきます。

はじめに

Microsoft® SQL Server 2017は、より高速な処理、柔軟性の向上、そしてコスト削減を実現する数々の新機能を搭載して登場しました。SQL Server 2016は「大きな飛躍」と呼ばれる多くの改善をもたらしましたが、SQL Server 2017はそれ以上に、あらゆるレベルで企業顧客が必要とするものを提供します。適応型クエリ処理によるパフォーマンスの新たなピーク、クロスプラットフォーム対応による柔軟性の向上、統計分析・データサイエンス向けの新しい統合機能、そしてLinux®、Ubuntu®オペレーティングシステム、Docker®上での稼働など、新バージョンは確かな技術とコスト削減をもたらします。

ここで紹介するSQL Server 2017の主な変更点は以下の通りです。

• Linux版SQL Server
• 再開可能なオンラインインデックス再構築
• SQL Server Machine Learning Services
• クエリ処理の改善
• 自動データベースチューニング
• TempDBファイルサイズの改善
• スマート差分バックアップ
• スマートトランザクションログバックアップ
• SELECT INTOステートメントの強化
• 分散トランザクションのサポート
• 可用性グループの新機能
• 新しい動的管理ビュー（DMV）
• インメモリ機能の拡張
• セキュリティの強化
• 高可用性とディザスターリカバリー
• パフォーマンスの向上

Linux版SQL Server

SQL ServerはもはやWindows専用のリレーショナルデータベース管理システム（RDBMS）ではありません。さまざまな種類のLinuxオペレーティングシステム上で実行できるようになりました。さらに、Linux、Windows、Ubuntu、Docker上のSQL Serverでアプリケーションを開発し、それらのプラットフォームへ展開することも可能です。

再開可能なオンラインインデックス再構築

この機能により、データベースのフェイルオーバー、ディスク容量不足、一時停止などのイベント発生後でも、中断した箇所からオンラインインデックス再構築操作を再開できます。

以下の画像は、この操作の一例です。

インデックス作成時のガイドライン

オンラインインデックス操作を行う際には、以下のガイドラインが適用されます。

• 基になるテーブルにimage、ntext、textなどのラージオブジェクト（LOB）データ型が含まれる場合、クラスター化インデックスはオフラインでの作成・再構築・削除が必要です。
• 非一意かつ非クラスター化インデックスは、テーブルにLOBデータ型が含まれていても、その列がインデックス定義内でキー列または非キー（包含）列として使用されていなければ、オンラインで作成できます。
• ローカル一時テーブルのインデックスはオンラインで作成・再構築・削除できません。この制限はグローバル一時テーブルには適用されません。
• 同一テーブルまたはビューに対し、同時に複数の新しい非クラスター化インデックスを作成するか、非クラスター化インデックスを再編成する場合のみ、並行したオンラインインデックスDDL（データ定義言語）操作が可能です。それ以外の同時実行されるオンラインインデックス操作は失敗します。例えば、同じテーブル上で既存インデックスをオンライン再構築しながら、新しいインデックスをオンライン作成することはできません。

SQL Server Machine Learning Services

SQL Server 2016ではRプログラミング言語が統合され、データベースサーバー内でRを実行したり、Transact-SQL（T-SQL）スクリプトに埋め込んだりすることが可能になりました。SQL Server 2017では、さらにPythonスクリプトをデータベースサーバー自体の中で実行できます。RとPythonはどちらもデータ分析と自然言語処理機能に対する幅広いサポートを提供する人気のプログラミング言語です。

クエリ処理の改善

SQL Server 2017は、アプリケーションワークロードの実行時条件に応じて最適化戦略を適応させます。これには、SQL ServerおよびSQL Databaseでクエリパフォーマンスを向上させるための適応型クエリ処理機能が含まれます。

以下の図に示すように、クエリ処理には3つの新しい改善があります。

• バッチモードメモリ許可フィードバック：実行プランに必要なメモリ量を再計算し、キャッシュから適切なメモリを割り当てるフィードバック技術です。
• バッチモード適応型結合：ハッシュ結合またはネストされたループ結合を使い分けることで、プランをより高速に実行します。実行プランの最初の入力をスキャンした後、最速で出力を生成できる結合方式を動的に判断します。
• インターリーブ実行：マルチステートメントテーブル値関数を検出すると実行プランの最適化を一時停止し、正確なカーディナリティを算出してから最適化を再開します。

自動データベースチューニング

この機能は、潜在的なパフォーマンス問題を検出すると通知し、修正アクションの適用を可能にします。また、SQLプラン選択の回帰によって引き起こされたパフォーマンス問題を、データベースエンジンに自動的に修復させることもできます。これにより、データベースは動的にワークロードへ適応し、どのインデックスやプランがパフォーマンス向上につながるか、逆にどのインデックスがワークロードに悪影響を与えるかを見つけ出します。自動チューニングプロセスは、これらの発見に基づいてワークロードのパフォーマンスを改善するアクションを適用します。さらに、変更後も継続的にパフォーマンスを監視し、実際に改善されていることを確認します。パフォーマンスが向上しなかったアクションは自動的に元に戻されます。

SQLプラン選択の回帰

SQL Serverデータベースエンジンは、T-SQLクエリを実行する際に異なるSQLプランを使用する場合があります。クエリプランは統計情報、インデックス、その他の要因に依存します。場合によっては、新しいプランが以前のものより優れているとは限らず、パフォーマンスの回帰を引き起こすことがあります。プラン選択の回帰による劣化に気づいた場合は、sp_query_store_force_planストアドプロシージャを使用して、過去に使用されていた良好なプランを見つけ、現在のプランの代わりにそのプランを強制的に使用させることができます。SQL Server 2017（v.14.x）のデータベースエンジンは、回帰したプランに関する情報と推奨される修正アクションを提供します。さらに、このプロセスを完全に自動化し、検出されたプラン変更に関する問題をデータベースエンジン自身に修復させることも可能です。

自動プラン修正

自動プラン修正の仕組みは以下の図の通りです。

以下の自動チューニング機能が利用可能です。

• 自動プラン修正（SQL Server 2017 v14.xおよびAzure SQL Databaseで利用可能）：問題のあるクエリ実行プランを特定し、SQLプランのパフォーマンス問題を修正します。自動チューニングは次のコマンドで有効化できます。

• 自動インデックス管理（Azure SQL Databaseのみで利用可能）：データベースに追加すべきインデックスと削除すべきインデックスを特定します。

TempDBファイルサイズの改善

SQL Server 2017のセットアップでは、TempDBファイルの初期サイズをファイルごとに最大256GB（262,144MB）まで指定できるようになりました。また、インスタントファイル初期化（IFI）が有効になっていない状態でファイルサイズを1GB超に設定すると警告が表示されます。指定したTempDBデータファイルの初期サイズによっては、IFIを有効化していないとセットアップ時間が指数関数的に増加する可能性があるため、注意が必要です。

スマート差分バックアップ

sys.dm_db_file_space_usageに新しい列modified_extent_page_countが導入され、データベース内の各データベースファイルにおける差分変更を追跡できるようになりました。この新しい列により、DBA、SQLコミュニティ、バックアップ用独立系ソフトウェアベンダー（ISV）は、データベース内の変更ページの割合が閾値（約70〜80%）を下回る場合に差分バックアップを実行し、そうでない場合はデータベースのフルバックアップを実行するといった、インテリジェントなバックアップソリューションを構築できるようになります。データベースの変更量が非常に多い場合、差分バックアップのコストと所要時間はフルバックアップとほぼ同等になるため、差分バックアップを取るメリットはほとんどありません。むしろ、データベースの復元時間が長くなる可能性さえあります。このようなインテリジェンスをバックアップソリューションに組み込むことで、差分バックアップの活用により復元・リカバリー時間を短縮できるようになりました。

スマートトランザクションログバックアップ

新しい動的管理関数（DMF）であるsys.dm_db_log_stats(database_id)がリリースされました。この関数は新しい列log_since_last_log_backup_mbを公開しており、DBA、SQLコミュニティ、バックアップISVが、データベース上のトランザクションアクティビティに基づいてバックアップを実行するインテリジェントなT-logバックアップソリューションを構築できるようになります。このT-logバックアップソリューションのインテリジェンスにより、短時間に大量のトランザクションアクティビティが発生しても、T-logバックアップ頻度が低すぎるとトランザクションログサイズが肥大化する事態を防げます。また、サーバーにトランザクションアクティビティがないにもかかわらず、スケジュールされたトランザクションログバックアップが過剰な数のT-logバックアップファイルを作成してしまう状況も回避できます。こうした状況が起きれば、ストレージ、ファイル管理、復元のオーバーヘッドが不必要に増加してしまいます。

SELECT INTOステートメントの強化

SQL Server 2017では、SELECT INTOステートメントにONキーワードを使用することで、新しいテーブルを作成するファイルグループ名を指定できます。デフォルトではユーザーの既定ファイルグループにテーブルが作成されます。この機能は以前のバージョンでは利用できませんでした。

分散トランザクションのサポート

SQL Server 2017は、可用性グループ内のデータベースに対する分散トランザクションをサポートします。このサポートには、同じSQL Serverインスタンス上のデータベース間だけでなく、異なるSQL Serverインスタンス上のデータベース間の分散トランザクションも含まれます。ただし、データベースミラーリング用に構成されたデータベースについては、分散トランザクションはサポートされません。

可用性グループの新機能

この機能には、クラスターなしのサポート、Minimum Replica Commit Availability Groups設定、Windows-Linux間のクロスOS移行とテストが含まれます。

具体的には以下の特徴があります。

• 可用性グループを、基盤となるクラスタ（Windows Serverフェールオーバークラスタリング／WSFC）なしで、またWindowsとLinux（またはDocker）が混在する環境全体にわたって構成できるようになりました。
• 新しいMinimum Replica Commit設定により、トランザクションをプライマリでコミットする前に、指定した数のセカンダリレプリカでコミットすることを必須にできます。

新しい動的管理ビュー

動的管理ビュー（DMV）には、以下の要素が含まれます。

• sys.dm_db_log_stats：トランザクションログファイルに関するサマリーレベルの属性と情報を公開し、トランザクションログの正常性監視に役立ちます。
• sys.dm_tran_version_store_space_usage：データベースごとにグループ化されたバージョンストア使用量への影響を確認できます。これにより、変更前後でのワークロードのプロファイリングをテスト環境で実施したり、他のデータベースもバージョンストアを使用している場合でも経時的な影響を監視したりできます。
• sys.dm_db_log_info：仮想ログファイル（VLF）情報を公開し、トランザクションログの潜在的な問題の監視、警告、未然防止に役立ちます。
• sys.dm_db_stats_histogram：統計情報を調査するための新しい動的管理ビューです。以下の画像をご覧ください。

• sys.dm_os_host_info：プラットフォーム、ディストリビューション、サービスパックレベル、言語などの情報を公開します。
• sys.dm_os_sys_info：拡張され、CPUに関する情報（ソケット数、コア数、ソケットあたりのコア数など）が確認できるようになりました。

インメモリ機能の拡張

SQL Server 2017のインメモリ関連の変更点は以下の通りです。

• 計算列とその列に対するインデックスがサポートされました。
• CASE式、CROSS APPLY、TOP (N) WITH TIESがネイティブコンパイルモジュールでサポートされました。
• JSONコマンドがチェック制約とネイティブコンパイルモジュールの両方で完全にサポートされました。
• システムストアドプロシージャsp_spaceusedが、メモリ最適化テーブルの容量を正しく報告するようになりました。
• システムストアドプロシージャsp_renameが、インメモリテーブルとネイティブコンパイルモジュールで動作するようになりました。
• メモリ最適化テーブルに対する8インデックスという制限が廃止されました。
• メモリ最適化ファイルグループのファイルをAzure Storageに保存できるようになりました。

セキュリティの強化

データベーススコープの資格情報に対して、CONTROL、ALTER、REFERENCES、TAKE OWNERSHIP、VIEW DEFINITIONなどの権限を許可、拒否、取り消せるようになりました。また、ADMINISTER DATABASE BULK OPERATIONS権限がsys.fn_builtin_permissionsで表示されるようになりました。

高可用性とディザスターリカバリー

SQL Server 2017の強化されたAlways On機能により、ミッションクリティカルなアップタイム、高速フェイルオーバー、簡単なセットアップ、読み取り可能なセカンダリの負荷分散を実現します。これは、LinuxとWindowsの両方に対応した高可用性とディザスターリカバリーの統合ソリューションです。さらに、非同期レプリカをAzure仮想マシンに配置し、ハイブリッドな高可用性構成を組むことも可能です。

パフォーマンスの向上

SQL Server 2017では、クエリと統計情報の収集・表示方法に関して以下の変更が導入されました。

• 新しいDMV sys.dm_exec_query_statistics_xmlにより、クエリプロファイリングが有効になっている場合、セッションとプランを相互に関連付けることができます。以下の画像をご覧ください。

• Showplan XMLに、プランで使用された統計情報に関する情報が含まれるようになり、実際のプランについては実行時メトリクスと上位10件の待機統計も含まれるようになりました。これらの待機統計は、クエリストアでも追跡されるようになっています。
• 新しい動的管理関数sys.dm_db_stats_histogramにより、DBCC（データベースコンソールコマンド）を使用せずに、ヒストグラム情報へプログラムからアクセスできるようになりました。

まとめ

SQL Server 2017には、システムの導入に役立つ数多くの変更が含まれており、参考になる情報も豊富に公開されています。「単なるLinux移植版」と思われがちですが、コアとなるデータベースエンジンにはすべてのプラットフォームに利益をもたらす実質的な改良が多数施されています。MicrosoftはSQL Server 2017の累積的な更新プログラムを通じて製品に追加機能を継続的に提供しており、SQL Server 2017はSQL Server 2016よりも長期間にわたってMicrosoftによる完全なサポートを受けることができます。

フィードバックタブからコメントや質問をお送りください。また、私たちとの対話を始めることもできます。