SQL Azure と Cosmos DB をメインにWindows Azureの情報を発信
Azure SQL Database modified server quota policyが、発表されました。
各論理サーバーにデフォルトで作成できるデータベースの合計DTUが1600に制限されました。
サービスクラス、サービスレベルごとにDTUが定義されています。
そのDTUが合計で、1600までとなりました。
１つのサーバー（ここでいうサーバーは、xxxx.database.windows.netで表現できる論理サーバー）毎に、Basic（DTU5）だと320個までとなりました。
ちなみに、Web、Businessエディションのデータベースは従来の150個が存続しています。
ポータルで使用状況を確認することができます。
上記図の矢印部分で、いくつのDTUを使用しているのかが表示されます。
クリックするとさらに詳細が表示されます。
Azure SQL Database Elastic Scale のプレビューが発表されました！
何かと言うと、Azure SQL Database の組み込みのシャーディング（データ分割、分散）サービスです。
同様のサービスとして、Azure SQL Database Federation がありました。
Federation は正直失敗だった。
だから、Azure SQL Database Federation は、新しい提供モデルでは廃止されることが発表されていました。
なのに、今再びのシャーディングサービス。
でも、Federationでの失敗、およびAzure SQL Database の支援を通して培った経験を元に、
今度は期待できるサービスとなっています。
結構、いろいろあるのですが個人的に大きい！っと思うものをピックアップ。
Federationではライブラリが提供されておらず、各自でFederation用の中間コードを書く必要があり、使い勝手が悪かったのです。そのため、Federationサービスを使用せず、各自でシャーディングロジックを書くケースがありました。
Federationの成功可否は、ライブラリ提供！っと思っていました。
今回は初めから提供されています！
まずは、APIインターフェイスがあるのが大きい。
APIがあるので、クライアントライブラリがる。
Nugetで、Azure SQL Database Elastic Scale Clientが公開されています。
また管理用に、PowerShell（Shard Elastic PowerShellファイル）がサンプルですが提供されています。つまり、Azure Automationサービスとの組み合わせが可能。
FederationでもElastic Scaleでも、参照テーブルが提供されます。
マスターテーブルなどシャーディング不要、もしくはシャーディングしたいくないテーブルは、参照用テーブルとして各分散データベースに配置することができました。
Federationでは、splitした後に参照用テーブルを更新するには、全シャーディングデータベースの参照用テーブルに対して更新する必要がありました。
Elastic Scale の参照テーブルでは、レプリケーションされます！素敵！
（レプリケーション頻度や、パフォーマンス、同期レプリケーションにできるのかは要確認）
10/3 11:12 修正：勘違い。そんな機能無かった…。
Federationでは、特定シャードへのクエリ発行しかサポートされていませんでした。
複数のシャードにまたがるクエリを発行したい場合は、
アプリケーション側で、それぞれのシャードに個別にクエリを発行し取得した結果をアプリケーション側でマージする必要がありました。
ライブラリも提供されていないので、ユーザーが作りこむ必要がありました。
Elastic Scale では複数シャードへのクエリ発行がサポートされます！
UNION ALLを使用して結果セットを返してくれるので、とても楽になりましたね。
Federationで提供されていたシャーディングルールは、Rangeだけでした。
Rangeパーティションですね。
シャーディングキー何番から何番までっと区切っていく方法ですね。
Elastic Scale では、リストシャードマップを作成できます。
何番と何番は、データベースAみたいに指定できるようになり、柔軟なシャーディングが実現できるようになりましたね。
Elastic Scale では、シャーディングの実行（マージやスプリット）をできるユーザー、
シャーディングマップを参照だけできるユーザーというように、セキュリティ制御できるようになりました。
Windows Azure SQL Database には、これまで監査機能が提供されておらず、監査ログを取得したい場合にはトリガーなどで作りこむ必要がありました。
でも、全エディション（Basic、Standard、Premium）に対して、監査機能がPreview版での提供が始まりました！
SIerとかの人にはうれしい機能ですね。
以下のイベントを必要なものだけ選択して収集することができます。
監査機能を有効かするには、Azure Preview Portalを使用します。
監査ログを記録するには、アプリケーションの接続文字列を専用の文字列に変更する必要があります。
通常の接続文字列：<server name>.database.windows.net
監査ログを記録する接続文字列：<server name>.database.secure.windows.net
ログデータを素早く分析するのを支援するために、予めてダッシュボードレポートテンプレートを設定したExcelスプレッドシートをダウンロードします。自分の監査ログでテンプレートを使用するために、Excel 2013とPower Queryが必要です。テンプレートは、Azure Sotrageアカウントから直接監査ログをインポートして、Power Queryが処理されます。
ポータル上では、次のような管理ビューで表示されます。
監査ログは、Azure ストレージアカウントのAuditLogsという名前の１つのAzure Storage Tableに格納されます。（将来的には複数のTableに分割できるようになります。）
顧客は、Azure Storage Explorerや、Excel 2010/2013でPower Queryを使用して直接Azure Tableからデータをインポートしたり、提供するReport Templateを使用してログを参照できます。または独自のレポートソリューションを開発したり、既存のソリューションに統合することができます。
Azure SQL Database のサーバーを作成すると、昔はシステムによってランダムな文字列が付与される味気ないサーバー名となっていました。
こんなサーバー名は正直覚えられません。すっごく不便。名前を自由につけさせて欲しい！って数年ぐらい思っていました。
今日、知ったのですが、Azure SQL Databases のサーバー名をユーザーが指定できるようになっています。新しいプレビュー版のポータルで。
SQL Databaseのサーバー作成画面を開きます。
そーすると、サーバー名を入力できるようになっています！
まだ、あまり知られていないみたいなので、結構メジャーな単語でもデータベース作成できますよ！
ちなみに名前の存在チェックは微妙に動作していないので、azure.database.windows.netが作成できそうだったので、作成したらすでに存在しているとエラーが発生するという…。ご注意をｗ
statusCode:Conflict
statusMessage:{"code":"60080","message":"Server name 'azure' has already been used.","target":null,"details":[{"code":"60080","message":"Server name 'azure' has already been used.","target":null,"severity":"16"}],"innererror":[]}
モバイルサービスを作成して、スケジューラーを作成してジョブを実行する。
たとえば次のようなコードを実行する。
function Execute_Process_Request() {
console.log("Executing ExecuteDataRequest...");
mssql.query('Exec dbo.ExecuteDataRequest',{
success: function(results){
console.log("Finished the Process Request job.");
},
error: function(err) {
console.log("error is: " + err);
}
});
}
身も蓋もない話ですが、オンプレミスのSQL ServerのSQL Agent ジョブを使用して、敵ジョブを実行する方法ですね。
これには、sqlcmdツールを使用して、Azure SQL Databasesに対してクエリを実行します。
もしくは、オンプレミスじゃなくて、Azure IaaS（仮想マシン）上のSQL ServerのSQL Agentジョブを使っても良いですね。