Finding Blocking Queries in SQL Azure – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳し紹介したエントリーです。

遅かったり、長い間実行しているクエリは、過度のリソース消費を伴い、クエリのブロッキングの原因となります。つまり、パフォーマンス劣化につながります。ブロッキングの意味は、SQL ServerとSQL Azureで違いはありません。ブロッキングは、ロックによる同時実行制御を行うリレーショナル データベース マネージメントシステムでは避けることができない特徴です。

以下のクエリは、合計時間が長かったり、ほかのクエリにブロッキングされたりして、実行時間が長いクエリのトップ10を表示します。

SELECT TOP 10 r.session_id, r.plan_handle,
    r.sql_handle, r.request_id,
    r.start_time, r.status,
    r.command, r.database_id,
    r.user_id, r.wait_type,
    r.wait_time, r.last_wait_type,
    r.wait_resource, r.total_elapsed_time,
    r.cpu_time, r.transaction_isolation_level,
    r.row_count, st.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as st
WHERE r.blocking_session_id = 0 
    and r.session_id in 
    (SELECT distinct(blocking_session_id)
         FROM sys.dm_exec_requests)
GROUP BY r.session_id, r.plan_handle,
    r.sql_handle, r.request_id,
    r.start_time, r.status,
    r.command, r.database_id,
    r.user_id, r.wait_type,
    r.wait_time, r.last_wait_type,
    r.wait_resource, r.total_elapsed_time,
    r.cpu_time, r.transaction_isolation_level,
    r.row_count, st.text
ORDER BY r.total_elapsed_time desc

ブロッキングの原因は、残念なアプリケーション仕様であったり、残念な実行計画や、インデックスの不足が、ブロッキングの原因となりえます。

 

ブロッキングを理解する

 

SQL Azure上で、一つ目の接続が特定のリソースを共有ロックし、２つ目の接続が同じリソースに共有ロックと矛盾するロックを取得しようとした時にブロッキングが発生します。通常、最初の接続（共有ロック）がリソースをロックしている時間はとても短い時間です。ロックを解放したとき、二つ目の接続は、リソースにロックをかけ、プロセスを続けます。これは普通の動作で、頻繁に発生することでパフォーマンスへの影響はほとんどありません。

トランザクションの続行時間が長くなり、クエリがロックをかけ続けていると、ほかのクエリのパフォーマンスに影響が出ます。クエリがトランザクションを実行しておらず、(かつ、ロックヒント文を使用していない)場合、SELECT分はデータを読み取っている間だけ共有ロックを取得します。INSERTやUPDATEやDELETE分は、実行が終了するまでロックを取得しつづけることで、一貫性とロールバックを行うことができます。

クエリの種類や、トランザクションの分離レベルやロックヒントの使用有無などによって、クエリのロック時間や動きが変わります。詳細については、MSDNを参照してください。

• Locking in the Database Engine
• Locking and Row Versioning
• Lock Modes
• Lock Compatibility (Database Engine)
• Row Versioning-based Isolation Levels in the Database Engine
• Controlling Transactions (Database Engine)

まとめ

 

短くて速くて単純なクエリを多用することがブロッキングの減少につながります。長く大きなトランザクションは、ちいさな塊にし、トランザクション量を減らし、効率のいいSQLを書くようにすることがパフォーマンス観点状重要になります。一つの残念な遅いクエリがブロックすると、ほかの早いクエリまでもが遅くなってしまい全体としてパフォーマンスが劣化してしまいます。

Leveraging SQL Azure with Microsoft Access – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

SQL Server Migration Assistant（SSMA for Access v4.2）はアップデートされて、Microsoft AccessからSQL Azureへのマイグレーションをサポートするようになりました。今回のリリースでは、ローカルのMicrosoft AccessからSQL Azureへ直接簡単にデータ移行が行えるようになりました。SQL Azureに移行することで、高いスケーラビリティと、データの集中管理や分散配置されたデータの統合管理を行えるようになります。
SQL Server Migration Assistantツールキットは、データベースのマイグレーションを行うときに、複雑な変更条件についてはマニュアルで取り組むよう設計されています。SQL Server Migration Assistantを使用することで、顧客とパートナーは結果的に時間とコストとリスクがあるマニュアル作業を減らすことができます。

既存のAccessアプリケーションのフロントエンド部分は、SQL Azureへデータ移行後も使用し続けることができます。Access 2010は、リンクテーブルを使用してSQL Azureへ接続することができます。クラウドへ移行しても、Accessユーザは既存のインターフェイスを使用し続けることができるので、過去の投資は無駄になりません。

Access 2010でSQL Azureを使用する方法に関する詳細な情報は、Access 2010 and SQL Azure – Microsoft Access – Site Home – MSDN Blogsを参照してください。

The Fast Way to Move from MySQL to SQL Azure – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

SQL Server Migration Assistant（SSMA for MySQL v1.0）はアップデートされて、MySQLからSQL Azureへのマイグレーションをサポートするようになりました。今回のリリースでは、ローカルのMySQLからSQL Azureへ直接簡単にデータ移行が行えるようになりました。SQL Azureに移行することで、高いスケーラビリティと、データの集中管理や分散配置されたデータの統合管理を行えるようになります。
SQL Server Migration Assistantツールキットは、データベースのマイグレーションを行うときに、複雑な変更条件についてはマニュアルで取り組むよう設計されています。SQL Server Migration Assistantを使用することで、顧客とパートナーは結果的に時間とコストとリスクがあるマニュアル作業を減らすことができます。

Microsoft Codename “Dallas” Releases CTP 3 – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

マイクロソフト コードネーム「Dallas」CTP 3が、www.sqlazureservices.comで公開されています。CTP 3では、幾つかの改善が行われ、Dallasでの体験を向上させ、アDallasからデータを使用して行うプリケーション開発を簡単にしました。また、要望の多かった以下の用な機能を追加しました。

• Dallasのユーザ認証をするためのBasic認証
• 今年のMIXで公表されたODataを柔軟にクエリを発行できる
• Visual Studioにサービス参照を追加できる
• 新しいプロバイダーとデータの追加

Dallasの詳細については、DallasのホームページとBlogを参照してください。

Dallasとは、各種データを販売、提供するサービスです。

Microsoft® Codename "Dallas" is a new service allowing developers and information workers to easily discover, purchase, and manage premium data subscriptions in the Windows Azure platform.

A Server Is Not a Machine – SQL Azure Team Blogを簡単に翻訳したエントリーです。

サーバーはマシンではありません。
SQL Azureポータルで次の画像のように、SQL Azureにはサーバーの概念があります。

しかし、サーバーはオンプレミス環境でインストールされたSQL Serverでのサーバーとは同じではありません。オンプレミスのSQL Serverをインストールしたサーバーは、リソース、ストレージなどとセットになったマシンとほぼ同義です。その為、サーバーに追加できるデータベース数にも制限があります。

SQL AzureでのサーバーはTDSエンドポイントのことです。それぞれのデータベースは、データセンター内の複数のマシンにまたがって構成されるサーバー配下に作成されます。SQL Azureでのサーバーは、データベースの追加に制限が無く、データセンターのリソースをすべて利用することができます。つまり、あなたのSQL Azureサーバーがリソースオーバーすることはありません。

別の観点から考えると、別のデータベースを作成するとにデータセンター内に新しいサーバーを作成する必要がありません。SQL Azureは、自動的にサーバー作成を行います。オンプレミスでのSQL Serverインストールは、ロードバランスや要求の分散などを行うためにサーバー数を考慮しなければなりません。SQL Azureでは、データセンター内で必要に応じてロードバランスや要求の分散を提供します。

 

SQL Azreフロントエンド

 

SQL Azureフロントエンドサーバーは、ポート1433でTDSプロトコルを開けたインターネットに接続されているマシーンです。サービスゲートウェイの役割に加え、アカウントプロビジョニング、課金、モニタリングなどを行います。もっと重要なことは、適切なバックエンドサーバーへのルーティングを行うことです。SQL Azureに接続すると、フロントエンドサーバーは直接、あなたのサーバーを見て、リクエストをフォワードします。

 

無制限のデータベース

 

SQL Azureサーバー配下で使用できるデータベース数には制限がありません。しかし、規定では、SQL Azureアカウントには150データベース(masteデータベースもカウントに含む)に制限されています。制限数の拡大は提供していますので、必要な場合は、Microsoft Online Services Customer Portalから問い合わせしてください。