Tips

Handling Error 40552 IN SQL Azureをざっくりと日本語訳した投稿です。

エラー40552が発生する理由

SQL Azureは、サーバを複数ユーザで共有するクラウドデータベースサービスです。
全ユーザが等しくSQL Azureを快適に使えるように、一部のユーザがリソースを占有しないように幾つかのセーフ機能を持っています。

セーフ機能の１つに、トランザクションで大量にアクティブトランザクションログを生成していないか監視しています。
大量のトランザクションログ容量を使用するトランザクションを実行しているアプリケーションは、SQL Azureから次のエラーを受け取ることになります。

Msg 40552, Level 20, State 1, Line 1
The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

インデックスの作成、再構築、削除をする際に40552を回避する方法

インデックスの削除、再構築、作成は、大量のトランザクションログレコードを生成するので、大きなテーブル上でこのエラーメッセージを受け取る可能性があります。

この問題を回避する為に、新しいテーブルを作成しインデックスのレイアウトを完成され、その新しいテーブルに小さな粒度でデータを移行します。
しかし、たいていの場合、ONLINEオプションを使用してインデックス操作をするほうが、必要なトランザクションログスペースを少なくすることができます。
ONLINE=ONを指定して、CREATEやALTER、DROP INDEX操作をすると、実行方法が変わります。
一つの大きなトランザクションに変わって、長時間広いロックを取得することなく、裏側で複数の小さなトランザクションを実行する操作になります。

どちらの方法でも、操作に必要なトランザクションログ容量を減らすことができ、操作を実行している間でも、対象テーブルの使用を継続できます。

DNSのCNAMEにSQL Azureのデータベースサーバーを登録することで、SQL Azureの接続にカスタムドメインを使用できるようにすることができます。

つまり、SQL Azureのサーバー名「severNameString.database.windows.net」をDNSのCNAMEに登録して、「database.sqlazure.jp」で接続できるようになります。
SQL Azureのサーバー名文字列はランダム生成なので覚えにくかったのが、自分のドメインを使用できるようになるので、とても便利ですよ！

留意点

しかし、留意点というか問題点がございます。接続時の認証情報を以下のようにする必要があります。

これは、接続文字列などで、よく言われることなので違和感が少ないかと思います。

その対象にSQL Server Management Studio 2008 R2も含まれてしまうので、要注意。下の図のようにサーバー名を付与してあげてください。

まぁ、コマンドプロンプトでNSLOOKUPからドメインを逆引きをすれば、サーバー名をさっくと調べることができ、いちいちAzure管理ポータルを開かなくていいので、楽には違いないですね。

情報源

A Custom DNS Name for my SQL Azure Database Server

Windows Azureアプリケーションのデバッグを通して、Azureプラットフォームでのデバッグテクニックを蓄積しました。Windows Azureのトラブルシュートの為に使用している情報の多くを共有するためのBlogシリーズを投稿する予定です。
シリーズの最初は、Azure VMにリモートデスクトップで接続し、確認することができるリソースを紹介したいと思います。

VM上のリソース

問題の解決の為に重要なことの一つは、環境全体と提供されているリソースとログファイルについて理解することです。
Cドライブは設定情報とローカルストレージを格納します。
Dドライブは、WindowsとWaAppAgentログを格納します。
Eドライブは、顧客のロールコードを格納します。

Cドライブ：ログファイル、ローカルストレージフォルダー

デバッグ（例えば、WinDBG、ツール、ダンプファイル、ログファイルなど）している間、ローカルの一時領域としてCドライブを使用できます。すべてのトラブルシューティングツールが読み込むためにC:\Scratchを作成します。

• C:\Config サービス設定情報
  • <DeploymentID>.<RoleName>.<index>.xml
    これは、ユーザロール用メインの設定情報です。サービス設定ファイル（管理ポータルで設定を更新したり、更新を再配置など）を更新したら、複数のコピーされたXMLファイルが格納され、<index>カウンターは、新しい設定バージョンが1つ追加されます。
    • デプロイ名
    • サービス名
    • 証明書
    • ホストプロセス
    • cscfg設定と値
    • ローカルストレージフォルダー
    • InputEndpoint、InternalEndpoinとポートのマッピング
  • <GUID>.ccf
    • OSバージョン
    • クラスター名
    • デプロイID
    • VMサイズ（<ProcessorCount>を探してください）
    • ipconfig情報
• C:Resources ローカルストレージ、ログファイル、AspNetTemp
  • ディレクトリ\<GUID>.<RoleName>.DiagnosticStore – IISログ、失敗したリクエスト（freb）ログ
  • ディレクトリ\<guid>.<role>.DiagnosticStore\Monitor\Tables – Azure 診断モニターが収集したすべての調査情報（イベントログ、ロールログ、WAD調査情報など）。table2csv.exeを使用して.tsfファイルを収集する方法は、Getting Azure Diagnostic Information from a VMを参照してください。
  • Temp\<GUID>.<RoleName>\RoleTemp – ホストプロセスログ
  • Directory\<GUID>.<RoleName>.<LocalStorage name> – サービスモデル(.csdef)で定義されている<LocalStorage>フォルダーです。

Dドライブ：Windows(%SystemDrive%、%SystemRoot%など)、エージェントログ

• D:\Packages\GuestAgent – エージェントログ
  • このロケーションからWaAppAgent.exeが開始されます。
  • WaAppAgent.exe.log – インスタンスのスタートアップ詳細を記録するエージェントログファイル
  • WaAppAgent.<index>.log – 履歴ログファイル

Eドライブ：サービスパッケージを含む仮想ドライブ

ゲストエージェントがサービスパッケージを配置したとき、このドライブが作成されます。これは動的に生成され、落ち着くまでFドライブ、Gドライブとなります。

• _entrypoint.txt – ホストプロセスが呼び出すエントリポイントを含むDLL
• RoleModel.xml – <Startup>タスクと<Sites>設定エレメントを含むXMLファイルです。また、MSBuild情報とターゲット.NET Frameworkのバージョンを含みます。
• <GUID>.csman – PackageManifestは、パッケージのすべてのファイル一覧（Visual Studioにコピー＆ペーストできる形式）を記録しています。
• \Base\x64 – サービスコードで動作するホストプロセス
• \Approot – 顧客のコード、aspxページ、DLLなど
• \Sitesroot\<index> – Full IISサイトの動作起点のフォルダーです。
  ロールがデプロイされたとき、\Approot から、この\Sitesroot へファイルがコピーされ、IISは、\Sitesrootから動作するように設定されます。一時的なテストの為に、ロールを変更する（web.configの変更、新しいDLLなど）場合には、ここを置き換えなければなりません。

Using DebugView to Troubleshoot Windows Azure Deployments – Snip/Shot by Toddy Mladenovを元にてけてけっと書いた投稿です。

Windows Azure のデプロイに失敗する場合に、表面的には何が問題で失敗しているのかがわかりにくく、原因特定に手間取ることがあります。
しかし、幸運にもリモートデスクトップでロールに接続できる状態の場合は、SysinternalのDebugViewを使用して、問題の発生原因を特定できるかもしれません。

手順

1. Windows Azureのデプロイに失敗しているロールにリモートデスクトップで接続します。
   接続手順は、Windows Azure実行環境へのリモート・デスクトップ接続 － ＠ITを参照。
2. リモートデスクトップで接続したら、ロール上で直接technetからダウンロードするか、リモートデスクトップのローカル共有を使用して、ファイルを転送します。
   IEは(Windows Server 2008標準設定で)セキュリティ強化されていますので、信頼済みサイトにtechnetを追加しないとファイルがダウンロードできないかも。
   ダウンロード先は、DebugView for Windowsです。
3. Dbgview.exeを開始し、Captureメニューからキャプチャーしたいものを選択します。ツールバー上のアイコンで、キャプチャーの開始と停止ができます。

すると上のようなキャプチャーが取れます。
上の画像のケースはスタートアップタスクでこけていることがわかり、原因解決に役立った・・・・そうです（笑

参考情報

Sysinternalで公開されているDebugView for Windows

DebugView は、ローカル システム、または TCP/IP 経由でアクセスできるネットワーク上の任意のコンピュータにおける、デバッグの出力を監視できるアプリケーションです。カーネル モード デバッグの出力と Win32 デバッグの出力の両方を表示できるので、アプリケーションやデバイス ドライバーから生成されたデバッグの出力をデバッガーで取得する必要がなく、標準以外のデバッグの出力 API を使用するようにアプリケーションやドライバーを変更する必要もありません。

この投稿は、「Windows Azure Traffic Manager Configuration Guid」に記載されている「Best Practice for Hosted Services and Polices When Using Windows Azure Traffic Manager」をざっくり意訳した投稿です。

ホストサービス

サービスは同一サブスクリプションを使用する

Windows Traffic Managerで制御したいすべてのホストは、ポリシーを作成するのと同じサブスクリプションでなければなりません。ポリシーに異なるサブスクリプションのホストサービスを追加することはできません。

Productionサービスのみ使用可能

Windows Traffic Managerで制御できるホストサービスは、Production環境だけです。ステージング環境のホストサービスは、ルーティングに追加することはできません。ポリシーでルーティング制御をしているときに、VIP SWAPを実行した場合、ホストサービスがProduction環境になった段階でルーティングに使用することができます。

ホスト名はわかりやすいものにする

Traffic Managerでポリシーを作成したり編集する際に、追加するホストサービスのDNS名を検索することができます。下の画像の①に文字列を入力すると、②の部分がフィルタリングされて表示されます。(複数あって、特定のDNS名を見つけたいときに使用します。)

複数の(たとえば、20個とかの)ホストサービスを使用している状態で、命名が悪いと、ホストサービスを追加するのが難しくなります。別のポリシーに追加してしまうなど、ミスを誘発してしまいます。

１つのポリシーに追加するホストサービスはすべて同じ動作とポートにする

ホストサービスが混在していると、リクエストしたサービスとは異なるサービスをクライアントが呼び出してしまう状態が発生してしまいます。サービスAとBが混在していて、ユーザがAを呼び出そうとしたのに実際にはBが返ってくる状態は、良いとは言えないです。

１つのポリシーに追加するすべてのサービスを同じモニタリング方法を使用する

ポリシーで使用するすべてのホストを監視する場合、一つだけパスかファイルを選択することができます。ポリシーからサービスを１つ移動させたり、サービスを異なる方法で監視すると、常にオフライン表示になるサービスがあるかもしれません。オフラインになっていると、ユーザにそのサービスのIPが返されることは無く、トラフィックがホストサービスに振り分けられることはありません。

ポリシー

ポリシーを変更するよりも、ポリシーを無効にするかホストサービスを無効にする

たいていの場合、ホストサービスを除外したり、ポリシーをオフラインにしたくなることがあるかと思います。そんな時は、ポリシーを変更するよりも単純にホストサービスやポリシーを無効化したほうが良いです。
下の図は、ポリシーの無効化するためのボタンを示しています。

Traffic Manager ドメイン

(Traffic上で一意の)プレフィックスをわかりやすいものにする

Traffic Managerドメインは、一意です。ドメインの一番最初のパートのみを設定することができます。

設定出るのは、CTPの前の部分だけです。

Traffic Managerドメインは、証明とルーティング目的で使用します。クライアントマシン（エンドユーザ）では、決して使用しないドメインなので、ドメイン名を読みやすくする必要性はありません。しかし、このドメインでポリシーを確認するので、重要です。管理ポータル上で、ほかのドメインから参照できるかを簡単に設定できます。

ドットを使用して、読みやすいドメインを作る

ドメイン名プレフィックスは、ピリオド記号を使用してパーツを分けることができます。

たとえば、メインドメイン名がwww.contoso.com の場合で、ポリシーでアジアとUSとヨーロッパにポリシーを設定した課金サービスに使用する名前には、billing.asia.us.europe.contoso.ctp.trafficmgr.comのようなプレフィックスを設定することができます。しかし、いくつかの制限事項があります。(ピリオドで分割された各部分をラベルと呼称します。 label.label.label.ctp.trafficmgr.com)

• 各ラベルには63文字しか使用できません。
• 127以上のラベルを使用できません。
• URLは全部で263文字でなければなりません。ctp.trafficmgr.comの部分で18文字使用しています。

DNS TTL(Time-to-Live) 生存時間

Windows Traffic ManagerにDNSエントリを更新するためにクエリを、クライアントとセカンダリDNSサーバが、どれぐらいの頻度でクエリを投げるかをDNS Time-To-Liveの値で設定します。

推奨は規定値の300秒（５分）です。値を小さくするとTraffic Managerへのトラフィック量が増え、パフォーマンスへの影響がでてしまいます。