Azure SQL Databaseは、Microsoftのサービスとしてのデータベースであり、非常に高い柔軟性とセキュリティを提供し、MicrosoftのPlatform-as-a-Serviceの一部として、追加機能を利用できます。 Azure SQL Databaseはデータベーススコープであるため、パフォーマンスの調整に関してはいくつかの大きな違いがあります。
インスタンスの調整
フルインストールでの構成に慣れているインスタンスレベルの項目の多くは、立ち入り禁止です。これらのアイテムの一部は次のとおりです。
- 最小および最大サーバーメモリの設定
- アドホックワークロードの最適化を有効にする
- 並列処理のコストしきい値の変更
- インスタンスレベルの最大並列度の変更
- 複数のデータファイルを使用したtempdbの最適化
- トレースフラグ
これらのいくつかにあまり腹を立てないでください。 ALTER DATABASE SCOPED CONFIGURATIONステートメントを使用すると、個々のデータベースレベルでかなりの数の構成設定を行うことができます。これは、AzureSQLDatabaseおよびSQLServer2016以降のSQLServerで導入されました。これらの設定には次のものが含まれます。
- プロシージャキャッシュをクリアする
- MAXDOPをゼロ以外の値に設定する
- クエリオプティマイザのカーディナリティ推定モデルを設定します
- クエリ最適化修正プログラムを有効または無効にします
- パラメータスニッフィングを有効または無効にします
- IDキャッシュを有効または無効にします
- バッチが初めてコンパイルされるときに、コンパイルされたプランスタブがキャッシュに保存されるようにするか無効にします。
- ネイティブにコンパイルされたT-SQLモジュールの実行統計の収集を有効または無効にします。
- ONLINE =ON/OFF構文をサポートするDDLステートメントのデフォルトオプションでオンラインを有効または無効にします。
- RESUMABLE =ON/OFF構文をサポートするDDLステートメントのデフォルトオプションで再開可能を有効または無効にします。
- グローバル一時テーブルの自動ドロップ機能を有効または無効にします
スコープ構成のリストからわかるように、個々のデータベースの特定の動作を微調整するための多くの制御と精度があります。一部のお客様にとっては、インスタンスレベルの制御の制限が悪影響を与える可能性がありますが、他のお客様はそれをメリットと見なします。
顧客ごとにデータベースがあり、完全な分離が必要な企業の場合、それはAzureSQLDatabaseに組み込まれています。 SQL Serverのインスタンスレベルの機能が必要であるが、MicrosoftのPaaSオファリングを利用したい場合は、インスタンススコープのAzureSQLマネージドインスタンスがあります。そこでの目標は、SQL Serverと100％の表面積の互換性を持つことです。したがって、最小および最大サーバーメモリを設定し、アドホックワークロードの最適化を有効にし、並列処理のMAXDOPとコストしきい値の両方を変更できます。管理対象インスタンスのTempdbにはすでに複数のファイルがありますが、さらに追加して、デフォルトのサイズを増やすことができます。多くの点で、SQLServerのフルインストールのように感じられます。
クエリの調整
Azure SQLDatabaseとSQLServerのもう1つの違いは、AzureSQLDatabaseではクエリストアがデフォルトで有効になっていることです。クエリストアをオフにすることはできますが、それを使用するAzureポータルのインテリジェントパフォーマンスツールを制限します。クエリストアは、クエリのパフォーマンスとプランの選択に関する洞察を提供する機能です。クエリストアは、クエリ、プラン、およびランタイム統計の履歴もキャプチャするため、何が起こっているかを確認できます。再コンパイル時間、実行時間、実行回数、CPU使用率、メモリ使用量、物理的な読み取り/書き込みなどが最も多いクエリを知りたいですか？クエリストアにはその情報があります。 SQL Serverの場合、データベースごとにこの機能を有効にする必要があります。 Query Storeを初めて使用する場合は、同僚のErin StellatoがPluralsightに関する3時間のコースを受講して、始めるのに役立ちます。
インテリジェントパフォーマンスツールのカテゴリには、4つの機能があります。まず、パフォーマンスの概要では、CPU消費量ごとの上位5つのクエリ、自動チューニング、チューニングアクティビティ、および現在の自動チューニング設定からの推奨事項を一覧表示することにより、データベース全体のパフォーマンスの概要を示します。このランディングページでは、パフォーマンスを簡単に垣間見ることができます。
次に、パフォーマンス推奨オプションは、インデックス作成に関する現在の推奨事項、またはインデックスを削除する必要があるかどうかを一覧表示します。最近のアクションが完了している場合は、履歴も表示されます。
第3に、Query Performance Insightは、CPU、データI / O、またはログI / Oごとの上位5つのクエリを表示することにより、リソース消費に関するより深い洞察を見つけることができる場所です。上位5つのクエリは色分けされているため、全体的な消費の割合を視覚的にすばやく確認できます。 query-idをクリックすると、SQLテキストなどの詳細を取得できます。長時間実行されるクエリタブもあります。 Microsoftがこのような機能をAzurePortalに無料で組み込んでいるのが本当に気に入っています。これは、顧客に最も問題のあるクエリを確認するためのポータルを提供することにより、価値を提供します。ここで私が難しいと思うのは、日ごと、週ごと、前月を比較するための全体的なベースラインを確認する方法があることです。ただし、簡単な分析と概要については、QueryPerformanceInsightが役立ちます。
このカテゴリの最後の機能は自動チューニングです。ここで、フォースプランの構成、インデックスの作成、およびインデックス設定の削除を行うことができます。強制的にオン、オフにするか、サーバーから継承することを選択できます。強制プランを使用すると、Azureは、リグレッションされたクエリの実行プランの中でより良いと思われるものを選択できます。この機能は、SQL Server 2017EnterpriseEditionにも自動プラン修正として存在します。一部のDBAは、自動チューニング機能について聞いたときに神経質になります。これは、将来DBAの必要性が置き換えられる可能性があるためです。私はいつも「クエリを積極的に調整するために毎日どのくらいの時間を費やしていますか？」という質問をするのが好きです。圧倒的な反応は、人々が実際にプロアクティブに調整するのにほとんど時間を費やすことができないということです。ほとんどの人は、実際に「調整」するのは、コードのリリース後またはユーザーが不満を言い始めたときだけだと答えています。
組み込みツールとクエリストアを使用する価値があることに加えて、DMVもすぐに利用できます。 Glenn Berryには、利用できるAzureSQLDatabase専用のスクリプトのコレクション全体があります。私が呼びたい特定のDMVの1つは、sys.dm_os_wait_statsです。これはサーバーレベルから取得されるため、データベースレベルの待機統計を実際に確認する場合は、代わりにsys.dm_db_wait_statsを使用する必要があります。
ハードウェア–スケーリング
Azure SQL Databaseのパフォーマンスを検討する際のもう1つの考慮事項は、基盤となるハードウェアです。 Azure SQL Databaseの価格は、データベーストランザクションユニット（DTU）とvCoreによって決まります。 DTUは、CPU、メモリ、およびI / Oを組み合わせた尺度であり、3つの層に分かれています。ベーシック、スタンダード、プレミアム。ベーシックはわずか5DTU、スタンダードは10〜3,000 DTU、プレミアムは125〜4,000DTUです。 vCoreベースの層には、1〜80のvCoreの範囲の汎用およびビジネスクリティカルがあります。
DTUモデルでは、開発とテストのためにBasicを検討する必要があります。バックアップの保持期間は7日間しかないため、本番データでは実行可能とは思われません。標準は、中程度から低いI / O要求で、低、中、高のCPU要求に適しています。基本層と標準層は、DTUあたり2.5 IOPSを提供し、5ミリ秒（読み取り）、10ミリ秒（書き込み）です。プレミアム層は、中から高のCPU需要と、2ミリ秒（読み取り/書き込み）でDTUあたり48IOPSを提供する高I/O向けです。プレミアム層には、標準よりも桁違いに高速なストレージがあります。 vCoreモデルには、物理コアあたり7GBのRAMを提供するGen4プロセッサと、論理コアあたり5.1GBのRAMを提供するGen5プロセッサがあります。 I / Oの観点から、汎用はvCoreあたり500 IOPS、最大7,000を提供します。 Business Criticalは、コアあたり5,000 IOPS、最大200,000を提供します。
概要
Azure SQL Databaseは、データベースの分離が必要なシステムに最適ですが、Azure SQLマネージドインスタンスは、インスタンスレベルの互換性（データベース間のクエリサポート）が必要な環境に最適です。 Azure SQL Databaseを調整する必要がある場合、インスタンスレベルのオプションは立ち入り禁止であるため、データベースレベルで処理を行う必要があります。したがって、データベーススコープの構成設定が微調整オプションです。パフォーマンスの低いクエリのトラブルシューティングを行うと、クエリストアなど、役立つ組み込みツールがいくつかあり、通常のチューニングスクリプトのほとんどが機能します。ベースライン、より多くの履歴データ、およびワークロードの管理に役立つアドバイザリ条件を作成する機能など、さらに多くの機能が必要になる場合があります。これは、SentryOneDBSentryのような強力な監視ソリューションが役立つ場合があります。
他のすべてが失敗した場合、またはワークロードが現在のハードウェアリソースを超えて単純に増加した場合は、より高い層に拡張します。