SQL Azure

今まで、Silverlight製の旧ポータルでしか操作できなかったSQL Reporting Services（SQLレポート）のサーバー管理がHTML5製の管理ポータルでできるようになりました（アナウンスはガスリーBlog）。

と言うわけで、早速操作してみました。

SQLレポートサーバーを作成する

左側のメニューに「SQLレポート」が追加されています。ぱちぱち。

image

ちなみに、左下の「＋新規」、中央部の「レポートサーバーを作成する」のどちらをクリックしてもSQLレポートの作成画面は同じ画面が開きます。

image

今のところ、簡易作成以外の作成画面は用意されていないようです。まぁ必要性も薄いですが。

image

必要事項を入力して、「SQLレポートサービスの作成」をクリックすると、作成ステータスが表示され数分で完了します。

image

レポートサービス一覧のURLをクリックすると、SQLレポートのログイン画面が表示されます。

image

ログイン画面。ここでIDとPasswordを入れてログインすると･･･････後は、今までと同じですね。

SNAGHTML163399d

SQLレポートサーバーのダッシュボード

SQLレポート一覧の左のほうをクリックするとダッシュボード画面が表示されます。

image

SQLレポートサーバーの使用状況を確認できます。

image

ユーザーの管理ができます。

image

レポートのアップロードやダウンロード、ディレクトリ作成などができます。

image

SQL Azure

sys.dm_db_wait_statsとは

SQL Serverでは、OS全体の待ち事象状況を確認するための動的管理ビューとして、「sys.dm_os_wait_stats」が提供されています。
Windows Azure SQL Databaseの場合、共有モデルで提供されているので、サーバー全体の待ち事象を確認できてもうれしいことが無いため、提供されていませんでした。

各データベースごとの待ち事象を確認できることは意味があるので、Windows Azure SQL Database用にデータベースの待ち事象を確認できるように、「sys.dm_db_wait_stats」が提供されるようになりました。

sys.dm_db_wait_statsの説明

sys.dm_wait_stats では、既に終わった待機時間が示されます。この動的管理ビューでは、現在待機中の待機時間は示されません。
クエリ実行中に発生している待機時間の種類によって、クエリにボトルネックや機能停止ポイントがあるかどうかを判断できます。

列名 説明
wait_type 待機の種類の名前。 詳細については、このトピックの「待機の種類」を参照してください。
waiting_tasks_count この待機の種類における待機の数。 このカウンターは、待機が開始するたび増加します。
wait_time_ms この待機の種類における総待機時間 (ミリ秒単位)。 この時間には signal_wait_time_ms が含まれます。
max_wait_time_ms この待機の種類における最大待機時間。
signal_wait_time_ms 待機スレッドがシグナルを受け取ってから実行を開始するまでの時間。

 

DBCC SQLPERF (‘sys.dm_db_wait_stats’, CLEAR);
によるカウンターリセットには対応していません。

参考情報

SQL Azure, Windows Azure

msnnodesql（Microsoft Driver for Node.JS for SQL Server）にはx86とx64の2種類のバージョンが提供されています。
ローカルマシーンとPythonが64ビットで動作している場合、「npm install msnodesql」コマンドで、64ビットバージョンのmsnodesqlをインストールすればいいです。

しかし、Windows Azure Web Sitesではアプリケーションはx86で動作しているので、x86版のmsnodesqlが必要になります。
NPMでx86版をインストールするか、コンパイルバージョンをダウンロードできます。
Windows Azure Web Sitesのすべてのウェブサイトは、すべてIISのx86 WOWモードでホストされています。

情報源

SQL Azure

Windows Azure Teamから、「SQLデータベース メンテナンスのお知らせ」というメールがきました。

お客様各位

SQL データベースのパフォーマンスを最適化するための継続的な取り組みの一環として、東南アジアデータセンターのネットワーク インフラストラクチャをアップグレードします。

本アップグレードの影響を最小限に抑えるため、お客様がご利用している地域におけるSQL データベースの利用状況を確認したうえでメンテナンスに最適な時間帯を決定させていただきました。
お客様のご利用している地域でのアップグレードスケジュールは下記のとおりです。下記の時刻より約 2 分間にわたりサービスが中断される予定です。
東南アジアデータセンター
2013年2月6日 午前6:00[日本時間］、協定世界時(UTC) 2月5日 午後9時

予定されているメンテナンスの最新状況については、 Windows Azure サービス ダッシュボードにアクセスしてください。

ネットワークの強化を実施するのにサービスダウンを伴うようです。
ピークオフの時間であるAM6時で実施することになったそうです。

ユーザーは、2/6に備えて準備をしましょう。

SQL Azure

以前、表題のような質問を受けました。

Windows Azure SQL Databaseは、SQL Serverとコードを共有していて高い互換性を持っているのに、何故SQL Serverのバックアップファイルをリストアできないの？

未サポートのデータ型/T-SQLがある

これの理由を考えるときに参考になるのが、
Windows Azure Import/Export サービスの改善によるExportに失敗する可能性が増加した理由
です。

Windows Azure SQL Databaseは、SQL Serverと高い互換性を持っていますが、サポートしていないデータ型や機能があります。
データ型やT-SQLのサポート状況については、次のドキュメントを確認してください。

サポートしていないデータ型などが含まれていると、たとえバックアップファイルをリストアできる機能があったとしても、サポートされていないものが含まれているとリストアに失敗してしまいます。
バックアップファイルの代わりに使用できるデータ層アプリケーション（DAC Framework）では、サポート状況をチェックしておりリストアに失敗しにくくなっています。

バイナリファイルのリストアによる弊害

SQL Serverのバックアップファイルをリストアすると、バックアップ元のデータベースのデータファイルサイズとデータファイル個数、トランザクションログサイズ、バックアップモードなどを忠実に再現します。

Windows Azure SQL Databaseでは、データファイルの個数やサイズなどのデータベースの物理設計はAzureで担保/管理している部分なので、バックアップファイルをリストアすると色々と弊害があるのです。
リストアした後、データファイル個数を変更して、データファイルサイズを変更してっと実行すべきオペレーションが多くあり、その間サーバーリソースを消費してしまいます。

今後も提供されないの？

個人的推測ですが、バックアップファイルのリストアは今後も提供されないと思います。
バックアップファイルに対応したとしても、Windows Azure SQL Databaseを使用するユーザー体験は向上しないことのほうが多いからです。

バックアップファイルをリストアしたのに、エラーが発生してリストアできなかった。
これをゼロにする術が無い状況では、提供しにくいと思います。
「確実にリストアできることを担保したい！」っと開発チームが考えているのは、
「Windows Azure Import/Export サービスの改善によるExportに失敗する可能性が増加した理由」からも明らかです。

例えば、次期SQL Serverでバックアップの仕様を根本的に見直すなどの大きめの対応が実施されて、バックアップ時にWindows Azure SQL Databaseとの互換性チェックを実施するとか、そんなことが無い限りは提供されないと思います。

当面は、オンプレミスのSQL ServerとクラウドのWindows Azure SQL Databaseの架け橋は、データ層アプリケーション（DAC Framework）が担っていくと思われます。
データ層アプリケーションの取得には、SQL Server Management Studio 2012を使用するか、SQL Server Data Toolsを使用するか、Windows Azure管理ポータルを使用すると良いです。