はじめにAzureSQLデータベースでのパフォーマンスの調整

Azure SQL Databaseの導入とv12での機能の追加により、データベース管理者は、組織がデータベースをこのプラットフォームに移行することに関心を寄せ始めています。

最近、Azure SQL Databaseについて詳しく調べ始め、世界中のデータセンターやAzureSQLDatabaseでボックスバージョンをサポートすることとは大幅に異なる点を確認しました。前回の記事「チューニング：開始するのに適した場所」では、SQLServerのチューニングを開始するためのアプローチについて説明しました。主な違いを見つけるために、これをAzureSQLDatabaseと照合することにしました。

私の元の記事では、無視されるかデフォルトのままになっている一般的なインスタンスレベルの設定と、メンテナンス項目から始めました。これらには、メモリ、maxdop、並列処理のコストしきい値、アドホックワークロードの最適化の有効化、およびtempdbの構成が含まれます。 Azure SQL Databaseでは、インスタンスについて責任を負わず、これらの設定を変更することはできません。 Azure SQLDatabaseはPlatformasa Service（PaaS）です。つまり、Microsoftがインスタンスを管理します。あなたは、1つまたは複数のデータベースを持つ単なるテナントです。

ただし、メンテナンスはあなたの責任であるため、ボックス製品の場合と同様に、統計を更新し、インデックスの断片化を処理する必要があります。これらのタスクについては、ほとんどのクライアントがSQLServerを実行しSQLServerエージェントをスケジュールされたジョブで使用する専用のAzureVMでこれらのプロセスを管理していることがわかりました。

私の記事の手順に従って、次に調べ始めるのは、ファイルと待機の統計と高コストのクエリです。オンプレミスデータベースを使用する本番データベースとしての仕事のこの側面が、Azure SQL Databaseを使用するときに変更されるかどうか疑問に思っている場合、答えは実際にはではありません。。ファイルと待機の統計はまだありますが、少し異なる方法でそれらに到達する必要があります。ファイル統計と待機統計（または一定期間のファイル統計と一定期間の待機統計のクエリ）にPaul Randalのスクリプトを使用することに慣れている場合は、次のためにいくつかの変更を行う必要があります。これらのスクリプトは、AzureSQLDatabaseで動作します。

Paulのファイル統計スクリプトを最初に試したとき、AzureSQLDatabaseがsys.master_filesをサポートしていないために失敗しました。：

メッセージ208、レベル16、状態1
無効なオブジェクト名'sys.master_files'。

sys.databasesを使用するようにスクリプトを変更できました結合でデータベース名を取得し、スクリプトの一部を削除して個々のファイル名を取得します。これは、単一のデータとログファイルのみを処理するためです。次の画像で、私が行った変更を確認できます。

その後、file-stats-over-a-period-of-timeスクリプトを実行したときに、sys.databasesに同じ変更を加えました。 file_idへの参照を削除します結合では、Azure SQLDatabasev12がグローバル##tempテーブルをサポートしていないために失敗しました。

すべてのグローバル##tempテーブルをローカルに変更すると、使用されていた既存の一時テーブルを削除できないという別の問題が発生しました。これは、グローバル##tempテーブルのようにローカル#tempテーブルを名前で直接参照できないためです。しかし、このようなチェックをOBJECT_ID('tempdb..#SQLskillsStats1')に変更することで、これを簡単に克服できました。。 2番目の一時テーブルにも同じ変更を加え、スクリプトの最初と最後のコードブロックを更新しました。

もう1つ変更を加えて、[mf].[type_desc]を削除する必要がありましたおよびLEFT ([mf].[physical_name], 2) AS [Drive] それらはsys.master_filesに依存しているため。これでスクリプトが完成し、AzureSQLDatabaseで使用できるようになりました。

パフォーマンスの問題をトラブルシューティングするときは、定期的にfile-stats-over-a-period-of-timeを使用します。累積データには目的がありますが、ユーザーのワークロードが実行されている特定の時間帯に関心があります。

ファイル統計では、データベースファイルごとの遅延と、全体的なI/Oを削減するためにどのように調整できるかを考慮しています。アプローチはSQLServerと同じであり、クエリを適切に調整し、正しいインデックスを設定する必要があります。ワークロードが大きすぎる場合は、パフォーマンスの高いDTUデータベース層に移行する必要があります。私にとって、これは素晴らしいことです。ハードウェアを投げるだけです。しかし、それは伝統的な意味での実際のハードウェアではありません。 Azure SQL Databaseを使用すると、ビジネスとI / Oの需要が増大するにつれて、基本的にスイッチを切り替えるだけで、より安価な階層から始めて拡張できます。

待機統計を取得するための最良の方法を見つけようとするのは簡単でした。私たちの多くが使用している標準のスクリプトは引き続き機能しますが、データベースが実行されているコンテナの待機統計を取得します。これらの待機は引き続きシステムに適用されますが、同じコンテナ内の他のデータベースで発生した待機を含めることができます。 Azure SQLデータベースには、新しいDMV sys.dm_db_wait_statsが含まれています、現在のデータベースにフィルターをかけます。あなたが私のようで、主にすべての良性の待機を省略したPaulの待機統計スクリプトを使用する場合は、sys.dm_os_wait_statsを変更するだけです。 sys.dm_db_wait_statsへ。同じ変更が一定期間の待機スクリプトでも機能しますが、グローバル変数からローカル変数に変更する必要もあります。

高コストのクエリを見つけることになると、実行する私のお気に入りのスクリプトの1つは、最も使用されている実行計画を見つけます。私の経験では、1日に100,000回呼び出されるクエリを調整することは、通常、IOが最も高いが、週に1回しか実行されないクエリを調整するよりも大きなメリットです。次のクエリは、最もよく使用されるプランを見つけるために使用するものです。

SELECT  usecounts ,
        cacheobjtype ,
        objtype ,
        [text]
FROM    sys.dm_exec_cached_plans
        CROSS APPLY sys.dm_exec_sql_text(plan_handle)
WHERE   usecounts > 1
        AND objtype IN ( N'Adhoc', N'Prepared' )
ORDER BY usecounts DESC;

デモでこのクエリを使用するときは、常にプランキャッシュをフラッシュして値をリセットします。 DBCC FREEPROCCACHEを実行しようとしたとき Azure SQL Databaseで、次のエラーが発生しました：

DBCC FREEPROCCACHE AzureSQLDatabaseではサポートされていません。これは私にとって厄介でした。私が本番環境にいて、いくつかの悪い計画があり、ボックスバージョンでできるようにプロシージャキャッシュをクリアしたい場合はどうなりますか。 Google / Bingを少し調べたところ、Microsoftの記事「SQLAzureでのプロシージャキャッシュについて」が見つかりました。この記事には次のように記載されています。

SQLAzureは現在DBCCFREEPROCCACHE（Transact-SQL）をサポートしていないため、キャッシュから実行プランを手動で削除することはできません。ただし、クエリによって参照されるテーブルまたはビュー（ALTERTABLEおよびALTERVIEW）に変更を加えると、プランはキャッシュから削除されます。

説明されている動作を確認せずにKimberlyTrippとこれについて話し合うと、プランはキャッシュからフラッシュされませんが、プランは無効になります（その後、プランは最終的にキャッシュから削除されます）。これは特定の状況では役立ちますが、これは私が必要としていたものではありませんでした。私のデモでは、sys.dm_exec_cached_plansのカウンターをリセットしたいと思いました。新しい計画を作成しても、望ましい結果は得られません。チームに連絡したところ、GlennBerryから次のスクリプトを試すように言われました。

ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

このコマンドは機能しました。特定のデータベースのプロシージャキャッシュをクリアすることができました。データベーススコープ構成は、SQL Server2016RC0で追加された新機能です。グレンはここでそれについてブログに書いています：SQLServer2016でのALTERDATABASESCOPEDCONFIGURATIONの使用。

自分のデータベースのいくつかをAzureSQLDatabaseに移動し、新しい機能とスケーラビリティーオプションについて学び続けることに興奮しています。また、SentryOneプラットフォームに最近追加されたSentryOneDBSentryとの連携も楽しみにしています。私は、マイク・ウッドが最近の投稿で説明したDTU使用状況ダッシュボードを試すことに最も興味があります。