ダウンロード：Sync Framework fo SQL Azure

2010-08-06SQL Azure Team Blog

Download: Sync Framework for SQL Azure – SQL Azure Team Blogを簡単に翻訳した投稿です。

このドキュメントは、SQL AzureとSQL Serverと同期をするためのベストプラクティスを提供します。ホワイトペーパーでは、オンプレミスのSQL ServerとSQL Azure間でMicrosoft Sync Framework Power Pack for synchronization を使用した方法に焦点をあてています。

ダウンロード；Download details: Sync Framework for SQL Azure

SQL Azureへのデータ転送を高速に行う

2010-08-03SQL Azure Team Blog

Loading Data to SQL Azure the Fast Way – SQL Azure Team Blogを簡単に翻訳したエントリーです。

Lubor KollarとGeorge VargheseはSQL Azureへデータを転送する時に、いくつかのツールを使用したときのパフォーマンス情報を公開している。
Loading data to SQL Azure the fast way – SQLCAT Blogsを読んでみると良い。

＝＝＝＝＝

以下、ブログの一部分を抜粋して紹介する。詳細を知りたい場合は、元記事を参照してほしい。

データを転送するツールとして、SQL Server BCP Utility, SQL Server Integration Services (SSIS), Import and Export Data 、SQL Server Management Studio (SSMS)が提供されている。この投稿では、どのツールを使用すると速いのかを調べた結果を紹介する。

下のグラフは、一つのクラスター化インデックスを持つSQL Azureテーブルに1GBのデータを転送したときにかかった時間を表している。

使用したツールと転送データのある場所でグルーピングしている。それぞれのグラフは、シングルストリームとマルチストリームを比較している。

この結果から、Windows AzureからSQL Azureへデータを転送したときが最も速いことがわかった。multiple streamを使用したとき明らかにどのツールでもパフォーマンスが改善することが分かった。multiple streamは、Windows Azure内外関係なく効果がある。

BCPはバッチサイズ(1トランザクションでコミットする行数)とパケットサイズ(インターネット越しに1パケット辺りで送信するバイト数)を設定することができる。データの特徴とネットワークの状況に応じたパラメータ設定が必要で、パフォーマンスはパラメータ設定に大きく影響を受ける。

MSコーポレートFirewall配下のNWでは・・・・

Tool	Observation
BCP	ベストパフォーマンス；5ストリーム、バッチサイズ10,000、パケットサイズ4K、
SSIS	ベストパフォーマンス；7ストリームUse bulk upload when possible チェックボックスを選択し、ADO .NET destination SQL Azure componentをし余殃する。

まとめ

SQL Azureにデータを転送するとき、複数ストリームを使用して並列転送を行うのが良い。

BCPは、それぞれの環境に合わせて適切なパラメータ設定をする。

SQL Azureにデータ転送をした後、非クラスター化インデックスを追加する。

データ転送前にインデックスを追加すると最終的なデータベースサイズが50％増加し、同じデータを転送するのにかかる時間が170%増加した。

もし大きなインデックスを作成するとき、エラーメッセージが発生したら、オンラインオプションを使用して再度実行してください。

OData SDK for PHPでSQL Azureデータを取得する

2010-08-03SQL Azure Team Blog

Consuming SQL Azure Data with the OData SDK for PHP – SQL Azure Team Blogを簡単に翻訳したエントリーです。

Brain SwanはOData SDK for PHPを使用してSQL Azure OData ServiceからSQL Azureのデータを取得する方法についてブログに投稿している。
Consuming SQL Azure Data with the OData SDK for PHPを読んでみると良い。

＝＝＝＝＝＝＝＝

以下、そのブログを抜粋して簡単に翻訳しています。
元記事では、SQL Azureサーバーの準備と、ローカルのNorth WindowデータベースをSQL Azure Migration Wizardを使用してSQL Azureにデータベースを移行する手順が説明されています。以下の抜粋は、SQL Azure上にデータベースの用意をしたところからの説明になります。

SQL Azure OData Serviceを作成する

Welcome to SQL Azure Labsにアクセスし、SQL Azure ODataServiceを選択する。
サーバー名、ユーザー名、パスワードを入力し、Connectボタンをクリックする。
接続後、ドロップダウンリストからOdata Serviceに使用したいデータベースを選択します。Enable ODataチェックボックスにチェックを入れます。
Anonymous Access Userドロップダウンリストからdboを選択することで、匿名アクセスが可能になります。

OData Serviceのエンドポイントを用意できました。URLをブラウザーにコピー＆ペーストすることで、いじることができます。

PHPでOData Serviceにアクセスする

OData Serviceのセットアップが完了したら、Retrieving Data with the OData SDK for PHP – Brian Swanの投稿で説明した方法でPHPからOData Serviceにアクセスできる。

ダウンロード：Windows Azure Security Notes(英語)

2010-08-03Windows Azure

Now Available: Azure Security Notes PDF – J.D. Meier’s Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

Azure Security Notes (PDF)は、クラウドセキュリティやAzure セキュリティから学び、メモしたコレクションです。これはガイドではなく、またMicrosoftのパタン＆プラクティスでもありません。patterns & practices Windows Azure Security Guidance projectの調査段階で学んだことを共有するためにまとめたものです。

ダウンロード

Download Azure Security Notes (PDF)

Ch 1 – クラウドセキュリティへのアプローチ
Ch 2 – クラウドセキュリティの脅威と対策
Ch 3 – クラウドセキュリティを改善するためのガイドラインのデザイン
Ch 4 – Webアプリケーソンセキュリティアーキテクチャの選択
Ch 5 – Webアプリケーションセキュリティシナリオ
Ch 6 – Webサービスセキュリティのアーキテクチャを選択する
Ch 7 – Webサービスセキュリティシナリオ
Ch 8 – データセキュリティアーキテクチャの選択
Ch 9 – データセキュリティシナリオ

参考

クラウドアプリケーション用のセキュリティチェックリスト
WEBアプリケーションの驚異
Webサービスの驚異
カンペ – Webアプリケーションのセキュリティ驚異と対策
カンペ – Web サービス (SOAP) セキュリティ驚異と対策
カンペ – Web サービス (REST) セキュリティ驚異と対策
カンペ – データセキュリティと対策
ハウツー – Azureテーブルストレージでのフォーム認証の使用
ハウツー – SQL Azureでのフォーム認証の使用
ハウツー – Windows Azure上のシングルサインオン認証をSSLで有効にする

SQL AzureでSQL Server Agentを何とか実現させる方法: Part 2

2010-08-02SQL Azure Team Blog

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

今のところ、SQL AzureはSQL Server Agentの概念を持っていません。このシリーズでは、Windows Azureワーカーロールを使用して、簡単に代用できるものを作成したいと思います。このシリーズの最初の投稿で、Visual Studioとコードで、Windows AzureワーカーロールでSQL Server Agentと同等のものを作成する方法を紹介しました。
このエントリーでは、一日に一回ジョブを実行するメカニズムを作成します。

データベースの作成

Windows Azureは、ワーカーロールは、そのうちデータセンターで異なるサーバに移動する可能性のあるステートレスなプラットフォームです。このため、ジョブが完了するまでジョブの状態を記録し続ける必要があります。その為に迷うことなくSQL Azureを選択します。SQL Azureサーバ下に、SQLServerAgentと呼ばれるデータベースを作成します(データベース名msdbは予め予約されています)。このデータベースに、オンプレミスのSQL Server Agentテーブルsysjobactivityの簡単バージョンであるjobactivityと呼ばれるテーブルを作成します。
私が使用したスクリプトは以下のものです。

CREATE TABLE [dbo].[jobactivity](
    [job_id] uniqueidentifier NOT NULL PRIMARY KEY,
    [job_name] nvarchar(100) NOT NULL,
    [start_execution_date] datetime NOT NULL,
    [stop_execution_date] datetime NULL,
)

job_idはオブジェクトの日次インスタンスを表し、job_nameはジョブ実行の為の任意のキーです。異なる名前を使用することで多くのジョブを走らせる為に、このテーブルを使用します。

ジョブの開始と停止の追跡

ジョブ開始時にテーブルにデータを追加する為のストアドプロシージャと、ジョブ停止時に実行ストップを更新する為のストアドプロシージャの２つが必要です。Startjobストアドプロシージャは、ワーカーロールがジョブを開始する為のシグナルを行に登録する前に、ジョブが始まらないことを保証します。

CREATE PROCEDURE StartJob (
    @job_name varchar(100),
    @job_id uniqueidentifier OUTPUT)
AS

BEGIN TRANSACTION

SELECT    @job_id
FROM    [jobactivity]
WHERE    DATEDIFF(d, [start_execution_date], GetDate()) = 0 
    AND [job_name] = @job_name

IF (@@ROWCOUNT=0)
BEGIN
    -- Has Not Been Started
    SET @job_id = NewId()
    INSERT INTO [jobactivity] 
        ([job_id],[job_name],[start_execution_date])
        VALUES (@job_id, @job_name, GetDate())
END
ELSE
BEGIN 
    SET @job_id = NULL
END

COMMIT TRAN

もう一つのストアドプロシージャStopJobは、次のようになります。

CREATE PROCEDURE [dbo].[StopJob](
    @job_id uniqueidentifier)
    
AS

UPDATE [jobactivity]
SET [stop_execution_date] = GetDate()
WHERE job_id = @job_id

ストアドプロシージャを呼び出すワーカーロールを書きます。

protected Guid? StartJob(String jobName)
{
    using (SqlConnection sqlConnection = new SqlConnection(
        ConfigurationManager.ConnectionStrings["SQLServerAgent"].
            ConnectionString))
    {
        try
        {
            // Open the connection
            sqlConnection.Open();

            SqlCommand sqlCommand = new SqlCommand(
                "StartJob", sqlConnection);

            sqlCommand.CommandType =
                System.Data.CommandType.StoredProcedure;

            sqlCommand.Parameters.AddWithValue("@job_name", jobName);

            // WWB: Sql Job Id Output Parameter
            SqlParameter jobIdSqlParameter = new 
                SqlParameter("@job_id", SqlDbType.UniqueIdentifier);
            jobIdSqlParameter.Direction = ParameterDirection.Output;
            sqlCommand.Parameters.Add(jobIdSqlParameter);

            sqlCommand.ExecuteNonQuery();

            if (jobIdSqlParameter.Value == DBNull.Value)
                return (null);
            else
                return ((Guid)jobIdSqlParameter.Value);
        }
        catch (SqlException)
        {
            // WWB: SQL Exceptions Means It Is Not Started
            return (null);
        }
    }
}

protected void StopJob(Guid jobId)
{
    using (SqlConnection sqlConnection = new SqlConnection(
        ConfigurationManager.ConnectionStrings["SQLServerAgent"].
            ConnectionString))
    {
        // Open the connection
        sqlConnection.Open();

        SqlCommand sqlCommand = new SqlCommand(
            "StopJob", sqlConnection);

        sqlCommand.CommandType =
            System.Data.CommandType.StoredProcedure;

        sqlCommand.Parameters.AddWithValue("@job_id", jobId);

        sqlCommand.ExecuteNonQuery();
    }
}

1日1回、午後１時にspTestJobストアドプロシージャを実行するために、ワーカーロールのRunメソッドを実行します。

public override void Run()
{
    Trace.WriteLine("WorkerRole1 entry point called", "Information");

    while (true)
    {
        DateTime nextExecutionTime = new DateTime(
            DateTime. UtcNow.Year, 
            DateTime. UtcNow.Month, DateTime. UtcNow.Day,
            13, 0, 0);
        if (DateTime. UtcNow > nextExecutionTime)
        {
            // WWB: After 1:00 pm, Try to Get a Job Id.
            Guid? jobId = StartJob("TestJob");
            if (jobId.HasValue)
            {
                Trace.WriteLine("Working", "Information");

                // WWB: This Method Has the Code That Execute
                // A Stored Procedure, The Actual Job
                ExecuteTestJob();

                StopJob(jobId.Value);
            }

            // WWB: Sleep For An Hour
            // This Reduces The Calls To StartJob
            Thread.Sleep(3600000);
        }
        else
        {
            // WWB: Check Every Minute
            Thread.Sleep(60000);
        }
    }
}

上のコードにエラーハンドリングのコードがないことに気づいたでしょうか。エラーが発生したらどうなるでしょうか。SQL Azureがエラーを返したらどうなるでしょうか。データセンターで異なるサーバでワーカーロールがリサイクルしたらどうなるでしょうか。それらの問題への対処については、このシリーズの3回目でコードを追加して対処したいと思います。