I Miss You SQL Server Agent: Part 1 – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

今のところ、SQL Azureはクラウド上でのSQL Server Agentの動作をサポートしていません。SQL Azureで、SQL Server Agentの機能が必要な場合は、Windows Azureワーカーロールとカスタムコードで代用できます。このシリーズで、代用する方法を紹介します。

 

SQL Server Agent

SQL Server Agentは、ジョブと呼ばれる管理タスクをスケジュール実行するためのMicrosoft Windows サービスです。SQL Server Agentは、SQL Serverに格納されたジョブ情報を使用します。ジョブは、一つ以上のジョブステップを含んでいます。各ステップは、データベースバックアップのようにSQL Server自信のタスクも含んでいます。SQL Server Agentは、ジョブをスケジュール実行、特定のイベント結果を受けての実行、呼び出されての実行に対応しています。例えば、平日業務後、全ての会社のサーバをバックアップしたい場合、SQL Server Agentを使用すれば自動実行させることができます。月曜から金曜までの22時以降起動するバックアップをスケジュールします。もしバックアップ実行に問題が発生した場合、SQL Server Agentはイベントを記録し、あなたに通知します。SQL Server AgentはオンプレミスのEnterprise、Datacenter、StandardエディションのSQL Serverにインストールされますが、ExpressとCompactエディションには提供されていません。

 

ワーカーロール

ワーカーロールはクラウド上の基本的なWindowsサービスです。ワーカーロールを開始させたとき、エンドレスループをするようにデザインされています。

• シングルプロセスイベントを確認する
• 動作を実行する
• 次に確認する必要ができるまでスリープする様々な目的で使用できるように、ワーカーロールは意図的に抽象的になっています。

注意事項：ワーカーロールは意図的に抽象化されており、SQL Server Agentは開発されており、一年程度で製品提供されると思うので、ワーカーロールで完璧にSQL Server Agentの機能を複製するつもりはありません。代わりに、Windows AzureワーカーロールからSQL Server Agentが行うような多くのタスクを実現できるように、いくつかのアイディアとシンプルなコードを提供しようと思っています。

 

初めに

初めに、Visual Studioでワーカーロールを含むクラウドプロジェクトを作成します。これに関して、基本的な事を知りたい場合は、ここを参照してください。

WorkerRole.vbと呼ばれるファイルにいくつかのサンプルコードが生成されます。

public override Sub Run()
    ' これは WorkerRole1 の実装例です。実際のロジックに置き換えてください。
    Trace.WriteLine("WorkerRole1 entry point called", "Information");

    While (True)
        Thread.Sleep(10000);
        Trace.WriteLine("Working", "Information");
    End While
End Sub

最初にすることは、SQL Azureデータベース上でストアドプロシージャを実行させるコードを書くことです。これは、SQL Server Agentジョブ内のステップでTransact-SQLを実行させるのと同等です。

次のようなコードになります。

    Protected Sub ExecuteTestJob()
 
        Using sqlConnection As SqlConnection = New SqlConnection(ConfigurationManager.ConnectionStrings("AdventureWorksLTAZ2008R2").ConnectionString)
 
            Try

                '接続を開く

                sqlConnection.Open()

 

                Dim sqlCommand As SqlCommand = New SqlCommand("spTest", sqlConnection)

                sqlCommand.CommandType = System.Data.CommandType.StoredProcedure

 

                sqlCommand.ExecuteNonQuery()

 

            Catch ex As SqlException

                Trace.WriteLine("SqlException", "Error")

                Throw

            End Try

        End Using

    End Sub

基本的にはSQL Azure上で、SqlCommand.ExecuteNonQuery()メソッドを使用して、データを返さないストアドプロシージャを実行します。SQL Server Agentのように何も結果を返しません。

 

例外のハンドリング

 

上の例では、Windows AzureワーカーロールでSQL Server Agent版を作成するための最初のステップなので、例外のハンドリングがとても貧相になっています。

SQL Server Agentのロジックから、成功したら次のステップへ進み、失敗したらジョブを終了し、失敗を報告するものを使用する場合、ワーカーロールでtry/catchを使用してSQL Server Agentの動作をシミュレーションします。このシリーズの3回目でエラーハンドリングの問題について取り組みます。

 

まとめ

このシリーズの2回目では、一日の間で、特定の時間にストアドプロシージャを実行させる方法について紹介します。

Programmatically Changing the Firewall Settings – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

SQL Azureは2種類のアクセス制御をしています。

• ユーザIDとパスワードによる認証
• IPアドレスによるアクセス制御を行うサーバ側のFirewallによるフィルタリング

SQL Azure ServerにはIPアドレスによる通信制御を行うFirewallがあります。アクセスしようとしているクライアントのIPがFirewallのアクセス許可ルールに登録されていない場合は、クライアントはSQL Azureにアクセスすることはできません。
アクセスを許可するIPを登録するには、SQL Azureポータルを使用することが一般的です。SQL Azureを使用するには、SQL AzureポータルでFirewallルールを作成する必要があります。Firewallルールを作成するまでは、クライアントはSQL Azureにアクセスすることができません。
下のスクリーンショットは、SQL AzureのFirewallルールを追加した例です。

 

Transact-SQLでFirewallルールを変更する方法

 

SQL Azureに接続して、MasterデータベースでTransact-SQLを実行することでFirewallルールを変更することができます。
システムストアドプロシージャ「sp_set_firewall_rule」を実行することでFirewallルールを追加することができます。次の例は、FirewallルールにアクセスすることができるIPアドレスを1つ追加するTransact-SQLです。

exec sp_set_firewall_rule N'Wayne Berry','206.63.251.3','206.63.251.3'

次の例は、Microsoft servicesとWindows Azureからのアクセスを許可するFirewallルールを追加するTransact-SQLです。

exec sp_set_firewall_rule N'MicrosoftServices','0.0.0.0','0.0.0.0'

Firewallルールの名前は、一意である必要があります。

Firewallルール一覧を確認するには、sys.firewall_rulesビューを参照します。

次の例は、ルール一覧を取得するTransact-SQLです。

select * from sys.firewall_rules

次のスクリーンショットは、SQL Server Management StudioでSQL Azureに接続して、コマンドを実行した結果です。

また、「sp_delete_firewall_rule」システムストアドプロシージャを使用することで、Firewallルールを削除することができます。

exec sp_delete_firewall_rule N'Wayne Berry'

 

セキュリティの考察

 

Masterデータベースに接続している間、サーバプリンシパルレベルのログインのみSQL AzureサーバのFirewallの設定をすることができます。SQL Azureポータルに管理者でログインしたときと同じ話です。

SQL Azureに接続して、sp_set_firewall_ruleなどのプロシージャを実行する前に、予め最低一つはFirewallルールを追加しておかなければなりません。

 

コマンドラインからFirewallルールを設定する方法

 

Windowsコマンドラインからsqlcmd.exeを使用してSQL Azureに対してTransact-SQLを実行することができます。

コマンドラインを使用して、Firewallルールを設定するスクリプトを実行することができます。

 

Windows AzureからFirewallルールを設定する方法

 

ADO.NETを使用して、Windows AzureからSQL Azureに対してTransact-SQLを実行することができます。つまり、Windows AzureからSQL AzureのFirewallルールを設定することができます。

Windows Azureは、Windows Azureを呼び出したクライアントのIPがわかることです。

Windows Azure webロール上のwebページを呼び出したIPを動的に、SQL AzureのFirewallルールに追加することができます。

PowerPivotまたはWinFormsのようにユーザが直接SQL Azureに接続する場合に、とても有効です。

次の例は、動的にSQL AzureのFirewallルールに動的にIPアドレスを追加している簡単な例です。

String clientIPAddress = Request.UserHostAddress;

using (SqlConnection sqlConnection = 
    new SqlConnection(ConfigurationManager.ConnectionStrings["SqlAzureMaster"].ConnectionString))
{
    sqlConnection.Open();

    using (SqlCommand sqlCommand =
        new SqlCommand("sp_set_firewall_rule", sqlConnection))
    {
        sqlCommand.CommandType = System.Data.CommandType.StoredProcedure;

        sqlCommand.Parameters.Add("@name", SqlDbType.NVarChar).Value 
            = clientIPAddress;
        sqlCommand.Parameters.Add("@start_ip_address", SqlDbType.VarChar).Value 
            = clientIPAddress;
        sqlCommand.Parameters.Add("@end_ip_address", SqlDbType.VarChar).Value 
            = clientIPAddress;


        sqlCommand.ExecuteNonQuery();
    }
}

Understanding the Procedure Cache on SQL Azure – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

SQL ServerとSQL Azureはクエリのパフォーマンス改善に利用する為のプロシージャキャッシュを持っています。このエントリでは、SQL Azure上のプロシージャキャッシュの動きについて説明します。

SQL Azureには、実行計画とバッファデータの保存に使用するためのメモリプールがあります。このメモリプールは、データベースの所有者に関係無く、物理マシン上の全てのデータベースで使用されます。プールは、マシン上の全てのデータベースにまたがる為、自分のDBの実行計画が一つも保存されていない場合があります。実行計画やバッファデータがプール上で使用できる割合は、システムの状態に応じて動的に変わります。メモリプールの中で、実行計画の保存に使用されている部分は、プロシージャキャッシュと呼ばれます。

SQL AzureでSQL文を実行したとき、リレーショナルエンジンは最初に、同じSQL文に実行計画が存在するかどうかを確認します。SQL Azureは実行計画がある場合は再利用し、SQL文を再コンパイルするオーバーヘッドを減らします。もし実行計画が存在しない場合は、SQL azureはクエリの実行計画を生成します。

SQL Azureとプロシージャキャッシュのレプリカ

 

SQL Azure上で動作するデータベースのインスタンスはレプリカと呼ばれます。同時に、起動している1つのデータベースには、3つのレプリカが存在します。一つ目のレプリカは、プライマリレプリカと見なされます。全ての読み書きをするクエリはプライマリレプリカに発行されます。他の二つのレプリカはセカンダリと見なされます。プライマリレプリカに書き込まれたデータは、セカンダリレプリカに書き込まれます。もしプライマリレプリカが落ちた場合、ロードバランサーが起動し、セカンダリレプリカをプライマリレプリカへ昇格させます、
それぞれのレプリカは、別々のラックに分かれた異なる物理マシン上に配置されます。プロシージャキャッシュは、各サーバごとにあるので、プライマリレプリカが落ちてセカンダリレプリカがプライマリレプリカに昇格したときには、プロシージャキャッシュには、そのデータベース用の実行計画はありません。

 

プロシージャキャッシュの統計情報

 

SQL Azureはキャッシュ上に全ての実行計画のパフォーマンス統計情報を保持しています。動的管理ビュー(DMV)であるsys.dm_exec_query_statsを使用して自分のデータベースに発行された統計情報を見ることができます。

SELECT *
FROM sys.dm_exec_query_stats

sys.dm_exec_query_statsを使用してI/Oパフォーマンスが悪いクエリを見つける方法について、別のエントリで説明しています。

sys.dm_exec_query_statsは、SQL Azureデータベースのプライマリレプリカの統計情報のみを表示します。もしセカンダリレプリカがプライマリレプリカに昇格したら、sys.dm_exec_query_statsの結果は、すごく変わります。キャッシュ上にクエリは無く、実行回数は少なくなります。

 

プロシージャキャッシュから実行計画を削除する

 

実行計画は、メモリに保存できる限りは、プロシージャキャッシュに記録されます。Memory Pressureが発生した場合、SQL Azureは、プロシージャキャッシュから削除する実行計画を決定するためにコストベースを使用します。

SQL Azureは計画の所有者に関係無くキャッシュから実行計画を削除します。サーバ上に存在する全てのデータベースの、全ての実行計画が横断的に、削除のために評価されます。プロシージャキャッシュ上の実行計画は、個々のデータベースでは無く、物理マシーンの利益の為に最適化されます。

SQL Azureは現在のところDBCC FREEPROCCACHE (Transact-SQL)をサポートしていません。その為、手動でキャッシュから実行計画を削除することはできません。しかし、クエリ(ALTER TABLE や ALTER VIEW) でテーブルやビューの参照関係を変更すると、キャッシュから実行計画は削除されます。

まとめ

 

SQL AzureはSQL Serverの上に構築されているので、多くの点で、プロシージャキャッシュはSQL Serverと同じように動作します。しかし、幾つかの違いがあり、それらを理解しておいて方が良いと思います

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に掲載されているテックニックを参考にできます。

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

Getting Started With Project Houston: Part 1 – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

マイクロソフトのプロジェクトコードネームHoustonは、SQL Azureのライトなデータベース管理ツールです。Houstonは、クエリの作成・実行、データベーススキーマのデザイン・編集、テーブルデータの編集のような基本的なデータベースの管理タスクを行うことができます。
現在、Houstonは最初のコミュニティテクノロジー・プレビュー(CTP)です。このエントリでは、HoustonのCTO版の紹介とスクリーンショットをお見せします。Houstonの利用方法をお見せします。

HoustonはwebベースのSilverlightアプリケーションです。つまり、インターネット接続ができる様々な場所から、Silverlightをサポートしている様々なブラウザ(ブラウザ一覧)でアクセスし使用することができます。Houstonはインストールをするソフトウェアではありませんが、Silverlihtはインストールするソフトウェアです。まだインストールしていない場合は、初めてHoustonにアクセスしたときにインストールをする為のダイアログが表示されます。

https://manage.sqlazurelabs.com/にアクセスすることでHoustonの利用を始めることができます。SQL Azureラボは、CTP版のプロジェクトや先進的なものを配置します。リリース後には、URLが変わります。

 

ログインをする

 

現在のCTP版では、ログインする時にSQL azure Server、データベース、管理者ID、パスワードを入力する必要があります。

HoustonはSilverlightアプリケーションなので、あなたのPC上のローカルクライアントで動作します。WEBアプリケーションでは無いが、Windows Azureにホストされたwebサービスと通信をします。

 

スタートページ

 

ログインすると、中央にスタートページが表示されます。スタートページには、アクセスするデータベースを選択する為の情報が表示され、ぐるぐる回転します。Houstonは、一つのブラウザで一つのデータベースを管理することができます。もし二つ以上のデータベースを管理したいときには、ブラウザのタブを使用し、もう一つHoustonにアクセスします。

 

矢印をクリックすると箱が回転します。回転するとき「oh」、「ah」と言っているのを確認してください。

 

 

ヒントページでは、Houstonの機能を確認するためのHoustonのビデオへのリンクが記載されています。

 

 

ナビゲーション

 

アプリケーションの上の方はツールバーです。ツールバーは、メインタブの表示内容に合わせて変化します。

 

 

データベースツールバーは下のような内容です。

 

 

ツールバーは下のように変化します。

 

 

メインタブの操作内容に関係無く、アプリケーションの左上のデータベースリンクをクリックすることで、いつでもデータベースツールバーに戻ることができます。
Houstonは、他のタブに移動しても元のタブでの変更を維持しています。テーブルを変更し、保存せず別のタブを開いても変更は失われません。アプリケーションは、タブ内に鉛筆アイコンが表示されている場合、テーブル/タブを保存する必要があることを示しています。

アプリケーションを終了させようとすると、変更を保存する必要があることを示す警告が表示されます。保存しなければ、操作が失われます。

 

 

Houstonは、CTP版です。その為、まだプロダクトにはバグがあったり、上のダイアログのようにスペルミスがあります。私は、上のダイアログの件をMicrosoft Connectにすでに報告している。

Feedbackやバグ報告

プロジェクトHoustonは通常のMicrosoftサポートサービスのサポートを受けることはできません。コミュニティベースのサポートは、SQL Azure Labs Support Forumに質問を投稿することができます。プロダクトチームが回答します。

 

バグの登録の仕方

1. フィードバック | Microsoft Connectに移動する。
2. すでにフィードバックが報告されていないか検索し確認してください。
3. まだ報告されていない場合は、ページの一番下に移動し、オレンジの「Submit Feedback」をクリックしてください。
4. 「Select Feedback」上の、「SQL Server Suggestion Form」をクリックします。
5. バグフォームで、「Category」=Tools(Houston)を選択します。
6. 質問を入力します。
7. マイクロソフトに送信するため「Submit」をクリックします。

フィードバックの仕方

1. フィードバック | Microsoft Connectに移動する。
2. すでに問題が報告されていないか検索し確認してください。
3. まだ報告されていない場合は、ページの一番下に移動し、オレンジの「Submit Feedback」をクリックしてください。
4. 「Select Feedback」上の、「SQL Server Bug Form」をクリックします。
5. バグフォームで、「Version」=Houston build CTP 1 – 10.50.9610.34を選択します。
6. バグフォームで、「Category」=Tools(Houston)を選択します。
7. 質問を入力します。
8. マイクロソフトに送信するため「Submit」をクリックします。

まとめ

 

Houston Blogを始めます。