SQL Azure and Session Tracing ID – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

もし注意を払っていたら、SQL Azureに接続しているとSQL Server Management Studio 2008 R2に新しいプロパティ（セッショントレースID）が追加されていることに気がついたかもしれません。

セッショントレース識別子は、全てのSQL Azureの接続時に生成されるユニークなGUIDです。サーバサイド上で、SQL Azureチームは、セッショントレースIDによって全ての接続の記録と追跡をしています。つまり、もしセッション識別子とエラーが起こったことがわかれば、Azure Developerサポートは、エラーを探し、エラーの原因を追及することができます。

 

SQL Server Management Studio

 

SQL Server Management Studioで、接続プロパティウィンドウでセッショントレース識別子を取得することができます。

 

Transact-SQL

 

下のクエリを使用してTransact-SQLでセッショントレースID識別子を取得することができます。

SELECT CONVERT(NVARCHAR(36), CONTEXT_INFO())

 

C#

 

またはC#でも取得することができます。

using (SqlConnection conn = new SqlConnection(…))
{
    // Grab sessionId from new connection
    using (SqlCommand cmd = conn.CreateCommand())
    {
        conn.Open();
         cmd.CommandText = "SELECT CONVERT(NVARCHAR(36), CONTEXT_INFO())";
        sessionId = new Guid(cmd.ExecuteScalar().ToString());
    }
}

重要なことは、セッショントレースIDは、クライアントサイド上のADO.NETコネクションプールとサーバへの接続ごとに発行されます。コネクションプールがリサイクルされ、接続し直すまで、SqlConnectionのインスタンスは同じセッショントレースIDになります。

 

まとめ

 

もし、セッショントレースIDとサーバネーム、おおよその時間を用意し、Azure Developer サポートに電話すると、デバッグプロセスを早めることができ、貴重な時間を守ることができます。

SQL Azure Date and Time Functions – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

Transact-SQLには、SQL Serverのインスタンスが動作するコンピューターのOSに依存する値を返す多数の日付、時刻関数があります。MCS UK Solution Development Teamブログに、SQL Azureでそれらの使用方法が説明されています。
その記事は、「ここ」から読めます。

＝＝＝＝＝＝

SQL AzureとOSに依存する時間関数

SQL Azure Date and Time Functions derived from the Operating System – MCS UK Solution Development Team – Site Home – MSDN Blogsを翻訳しています。

SQL Azureの時間関数は、全て基本的にUTCで動作し、サーバがホストデータセンターに関係無く同じ結果を返します。以下のクエリを、2010年5月19日12:06:06(UTC)、北ヨーロッパに干すとされているSQL Azureのインスタンスに対して実行したところ、以下のテーブルのような結果になりました。

クエリ

SELECT
    SYSDATETIME() as SYSDATETIME,
    SYSDATETIMEOFFSET() as SYSDATETIMEOFFSET,
    SYSUTCDATETIME() as SYSUTCDATETIME,
    CURRENT_TIMESTAMP as currenttimestamp,
    GETDATE() as getdate,
    GETUTCDATE() as getUTCdate;

 

実行結果

SYSDATETIME()	2010-05-19 12:06:04.2422123
SYSDATETIMEOFFSET()	2010-05-19 12:06:04.2422123 +00:00
SYSUTCDATETIME()	2010-05-19 12:06:04.2422123
CURRENT_TIMESTAMP	2010-05-19 12:06:04.250
GETDATE()	2010-05-19 12:06:04.250
GETUTCDATE()	2010-05-19 12:06:04.240

米国中北部、米国中西部、東南アジアにホストされているSQL Azureデータベースから同じ結果を返します。

Generating Scripts for SQL Azure – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

SQL ServerからSQL Azureへ移行する時、最初のステップは、SQL ServerのスキーマからSQL Azureへ移行するためのスクリプトを生成することです。SQL Server Management Studio 2008 R2に、新たに追加されたSQL Azureをターゲットに設定する拡張設定を使用することで、簡単に生成できます。
ステップバイステップで設定方法を説明します。

1) SQL Server Management Studio 2008 R2を開きます。

2) 転送したいデータベースを含むSQL Serverに接続します。

3) データベース上で右クリックし、[タスク]→[スクリプトの生成]を選択します。

 

4) スクリプトの生成とパブリッシュ ダイアログを開きます。 次へボタンをクリックし、説明ウィザードを飛ばします。

5) オブジェクトの選択ページが開きます。

 

 

6) データベース全体とすべてのデータベースオブジェクトのスクリプトを作成を選択し、「次へ」ボタンを選択します。

7) スクリプト作成オプションの設定ウィザードページが開きます。

 

8) 新しいクエリウィンドウに保存を選択し、詳細設定ボタンをクリックします。スクリプト作成の詳細オプションダイアログが開きます。

 

 

9) データベースエンジンの種類に対応したスクリプトオプションが表示されるまでスクロールを下げます。そのオプションのドロップダウンリストからSQL Azure データベースを選択します。「OK」ボタンを押します。

10) 次へボタンをクリックします。

11) 次へボタンをクリックし、概要ページを飛ばします。

12) スクリプトの保存またはパブリッシュダイアログで、データベースがクエリ化され、完了をクリックできるようになり、クリックするとクエリウィンドウにSQL Azureで使用できるクエリが表示されます。

13) This new query window in SQL Server Management Studio will automatically be connected the source SQL Server.

14) クエリウィンドウで右クリックし、メニューから[接続]→[接続の変更]を選択します。

 

15) 接続するSQL Azure サーバを設定します。オプションボタンを使用して、データベースを選択することができます。

 

 

16) SQL Server Management Studio で生成したスクリプトを実行し、SQL Azureにスキーマを作成します。

In order to use SSIS or BCP to transfer your SQL Server data to SQL Azure you need to have the schema is place on SQL Azure including your clustered indexes. クラスターインデックスを含んだSQL Azure上のスキーマに、SQL ServerからSQL Azureにデータを転送するのに、SSISまたはBCPを使用します。他のデータのアップロードを行うオプションとしては、スクリプトの保存またはパブリッシュダイアログで設定を変更しデータの生成を行う方法もあります。INSERT文が、スクリプトに追加されます。スクリプトのサイズが膨大になりますので、小さなデータベース限定の方法となりますが。

SQL Azureのテーブルにデータを追加するには、クラスター化インデックスが必要です。クラスター化インデックスが無いテーブルにデータを追加しようとすると、エラーが発生しデータを追加することができません。SQL Serverには、そのような制限はありません。

なぜ、SQL Azureには、そのような制限があるのでしょうか。

SELECT * AND SQL Azure – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

全ての良いDBAと開発者は、特別必要が無ければ全てのレスを返すクエリを発行すべきで無いことを知っています。

SELECT * FROM [Table]

SELECT文では、必要な列のみを返すようにします。SELECT *を使用すると余計なページングの原因となります。RFIDルックアップ、不必要なテーブルロック、カバードインデックスの作成意図の無効化等が発生します。結果としてパフォーマンスに悪影響が出ます。

さらに、SQL Azureには SELECT *を使用すべきでない理由があります。データ転送料に応じた課金を行うからです。もし、(Windows Azureアプリケーションではない)データセンターの外から使用する場合、クエリによって発生するデータ転送量に応じて料金を支払います。もし使用しない列も要求すると、使用していないデータの転送量にまで支払うことになります。

SELECT *クエリを削除することをあなたのTO-DOリストにあるのなら、SQL Azureですばらしい体験ができるでしょう。

 

(コメント欄より抜粋)

Entity FrameworkのようなORMでも、SELECT *は生成させるべきで無い。しかし、「Oraders.Where」や「.OrderBy」などを使用しても、特別にSELECT句「.select」を指定しない場合、SELECT *が生成されてしまいます。