SQL Azure

この投稿は、Tech ED NA 2011の「Understanding the Windows Phone Development Tools | Tech·Ed North America 2011 | Channel 9」セッションをざっくりとまとめ補足した投稿です。途中で力尽きたので、最後辺りはさっぱりしていますので、元ネタを参照した方がいいかと。

SQL Azureアーキテクチャ

  • SQLデータベースは共有インフラ
  • 一般的なハードウェアを使用した大規模分散クラスター
  • スケーラブルな高可用性テクノロジーを提供
    それぞれのSQL Azureデータベースは3つに多重化している
    自動レプリケーションとフェイルオーバー
  • TDSリクエストをゲートウェイサービスが転送する

image

上の図は、物理マシンの簡易構成図です。SQL Azureデータベースは、仮想環境では無く物理マシンにホストされます。
物理マシン上にSQLインスタンスがあり、インスタンスの中にSQL DBがあります。SQL DBには複数ユーザのDBがホストされます。SQLインスタンスやSQL DBは、ユーザがSQL Azureを使用する際に認識することはできません。
例えば、私がDBを3つ作成した場合、1つは物理マシン4に作成されたとしも残りの2つは、物理マシン4かもしれない100、500などまったく別の物理マシンにホストされる可能性のほうが高いです。

SQL Azure

SQL Azureのクエリパフォーマンスを分析するには、SQL Server Management Studioを使用するか、SET STATISTICS T-SQLコマンドを使用します。SQL Server Profilerは、今のところSQL Azureではサポートしていません。この投稿では、SQL Server Profilerの代わりに、サーバに実行されたT-SQLの結果セットを分析しパフォーマンスを改善することに焦点を当てます。

 

SQL Server Management Studio

 

SQL Server Management Studioを使用して、クエリの実行プランを表示することができます。実行プランを使用して、SQL Azureのインデックス使用状況、取得データ、各ステップごとの取得行数を知ることができます。

実行プランの取得方法

  1. SQL Server Management Studio 2008 R2を起動します。(このバージョンでは、簡単にSQL Azureに接続可能)
  2. 「新しいクエリ」ウィンドウを開きます。
  3. 新しいクエリウィンドウにクエリをコピペします。
  4. ツールバーの「実際の実行プランを含める」ボタンをクリックし、実行プランの表示を有効にします。

    000000

    または、メニューバーから「実際の実行プランを含める」を選択します。

    000001

  5. クエリを実行すると別のタブに実行プランが表示されます。

    20101026210719

実行計画の見方は、SQL Server 2008 R2と同じですので、この投稿では取り扱いません。「グラフィカル実行プランの表示 (SQL Server Management Studio)」を参照してください。クエリのパフォーマンスの改善する方法の一つに、カバードインデックスにする方法があります。「I/Oパフォーマンスを改善する」を参照してください。

 

USING "SET STATISTICS"

 

SET STATISTICSは、Transact-SQL コマンドで、SQL Server Mnagement Studioのクエリウィンドウで実行することで、クエリの実行統計を取得できます。SET STATISTICSは二種類あり、その一つが、SET STATISTICS TIME ONです。TIMEコマンドは、クエリのパースとコンパイル、実行時間を表示します。

クエリは次のようになります。

SET STATISTICS TIME ON

SELECT *

FROM SalesLT.Customer

      INNER JOIN SalesLT.SalesOrderHeader ON

            SalesOrderHeader.CustomerId = Customer.CustomerId

実行結果は、以下のようになります。ストップウォッチのような動作をします。

20101026210833

 

もう一つが、SET STATISTICSのオプションが、SET STATISTICS IO ONです。SQL AzureでのクエリのIOパフォーマンス状況が表示されます。

クエリは次のようになります。

SET STATISTICS IO ON

 

SELECT *

FROM SalesLT.Customer

      INNER JOIN SalesLT.SalesOrderHeader ON

            SalesOrderHeader.CustomerId = Customer.CustomerId

 

実行結果は、次のようになります。

20101026211540

 

実行しているSQLを取得する

 

SQL Serverでは、SQL Profilerを使用することでリアルタイムで現在実行しているクエリを取得することができます。SQL Azureでは、次のようなSQLを使用して、プロシージャキャッシュ経由で、実行回数と実行されたクエリを取得します。

SELECT q.text, s.execution_count

FROM sys.dm_exec_query_stats as s

      cross apply sys.dm_exec_sql_text(plan_handle) AS q

ORDER BY s.execution_count DESC

 

SQL Azureでのプロシージャキャッシュについては、「SQL Azure上のプロシージャキャッシュについて理解する」を参照してください。

この投稿は、Gaining Performance Insight into SQL Azure – TechNet Articles – Home – TechNet Wikiを紹介したものです。

SQL Azure Team Blog

Improving Your I/O Performance – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

SQL ServerのI/Oパフォーマンスを改善する場合、通常はストレージを調整し、RAIDを構成し、tempdbのファイル数を増やしたりします。しかし、SQL Azureのようにファイルストレージを変更できない場合、I/Oパフォーマンスをどのように改善したら良いのでしょうか、クエリを改善しI/Oを減らすことに集中することになります。I/O数の高いクエリを探し、I/Oパフォーマンスを改善する方法を説明します。

 

I/Oの使用が高いクエリを探す

 

次のTransact-SQLは、遅いクエリを25個取得します。

SELECT TOP 25
    q.[text],
    (total_logical_reads/execution_count) AS avg_logical_reads, 
    (total_logical_writes/execution_count) AS avg_logical_writes, 
    (total_physical_reads/execution_count) AS avg_phys_reads, 
     Execution_count
FROM sys.dm_exec_query_stats   
    cross apply sys.dm_exec_sql_text(plan_handle) AS q 
ORDER BY
 (total_logical_reads + total_logical_writes) DESC

クエリの実行結果は次のようになります。

 

最も大量にデータを読み込むクエリ

 

データを読み込むクエリでI/Oga大量に発生するもので、あなたが使用すべきでない代表例が下のクエリです。

SELECT * FROM [Table]

このクエリは、[Table]から全ての列と全ての行を読み込みます。これは、次のようにして改善することができます。

  • where句を使用して、クエリの使用目的に応じた必要な行のみを読み込むようにします。
  • テーブルから必要な列のみを取得するように、明確に列名を指定するようにします。

カバードインデックスを作成する

 

カバードインデックスを使用することでI/Oを減らせます。

カバードインデックスとは、where句とselect使用としているカラムを、非クラスタインデックスに含んでいるインデックスです。

複数テーブルを結合している場合に威力を発揮します。

 

まとめ

 

I/Oを改善するには、クエリのパフォーマンスを向上させることに集中させます。SQL Serverのクエリの最適化に関するMSDNに掲載されているテックニックを参考にできます。

ストレージ部分はマイクロソフトが最適化をしていますので、ユーザはクエリの改善に集中することになります。