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":[]}
 

Windows Azure SQL Database には、これまで監査機能が提供されておらず、監査ログを取得したい場合にはトリガーなどで作りこむ必要がありました。
でも、全エディション（Basic、Standard、Premium）に対して、監査機能がPreview版での提供が始まりました！
SIerとかの人にはうれしい機能ですね。

記録できるイベント

以下のイベントを必要なものだけ選択して収集することができます。

• データへのアクセス
• スキーマーの変更（DDL）
• データの変更（DML）
• アカウント、ロール、権限（DCL）
• セキュリティ例外

機能の有効化方法

監査機能を有効かするには、Azure Preview Portalを使用します。

1. 監査機能の有効化：https://account.windowsazure.com/PreviewFeatures?fid=datasecurity
2. Azure Preview Portalにアクセスする：https://portal.azure.com
3. 監査したいデータベースを選択し、[Auditing Preview]を有効化し、監査設定ブレードを表示する

4. ログの格納先ストレージを選択する
   
5. 記録したいイベント種類を選択する

監査ログを記録する方法

監査ログを記録するには、アプリケーションの接続文字列を専用の文字列に変更する必要があります。

通常の接続文字列：<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を使用してログを参照できます。または独自のレポートソリューションを開発したり、既存のソリューションに統合することができます。

監査ログテーブルフィールド

• PartitionKey
• RowKey
• TimeStamp
• EventTime
• ServerName
• DatabaseName
• ApplicationName
• ClientIP
• EventID
• EventType
• ActionSuccess
• ActionStatus
• FailureReason
• statement
• PrincipalName
• AffectedRows
• ConnectionGuid
• SchemaVersion
• Origin
• ActionId
• ClassType
• ObjectType

Event Types

• LoginSuccess
• LoginFailed
• SchemaChanges
• DataAccess
• DataChanges
• GrantRevoke
• StoredProcedure
• BeginTransaction
• CommitTransaction
• RollbackTransaction
• CancelBatch
• SecurityException（ログインに失敗、セキュリティレベル14のSQL実行エラーの時）

参考情報

Get started with SQL database auditing

Azure SQL Database Elastic Scale のプレビューが発表されました！
何かと言うと、Azure SQL Database の組み込みのシャーディング（データ分割、分散）サービスです。

同様のサービスとして、Azure SQL Database Federation がありました。
Federation は正直失敗だった。
だから、Azure SQL Database Federation は、新しい提供モデルでは廃止されることが発表されていました。

なのに、今再びのシャーディングサービス。
でも、Federationでの失敗、およびAzure SQL Database の支援を通して培った経験を元に、
今度は期待できるサービスとなっています。

Federationと何が違うの？

結構、いろいろあるのですが個人的に大きい！っと思うものをピックアップ。

1. ライブラリ提供

Federationではライブラリが提供されておらず、各自でFederation用の中間コードを書く必要があり、使い勝手が悪かったのです。そのため、Federationサービスを使用せず、各自でシャーディングロジックを書くケースがありました。
Federationの成功可否は、ライブラリ提供！っと思っていました。

今回は初めから提供されています！
まずは、APIインターフェイスがあるのが大きい。
APIがあるので、クライアントライブラリがる。

Nugetで、Azure SQL Database Elastic Scale Clientが公開されています。
また管理用に、PowerShell（Shard Elastic PowerShellファイル）がサンプルですが提供されています。つまり、Azure Automationサービスとの組み合わせが可能。

2. 参照テーブルのレプリケーション

FederationでもElastic Scaleでも、参照テーブルが提供されます。
マスターテーブルなどシャーディング不要、もしくはシャーディングしたいくないテーブルは、参照用テーブルとして各分散データベースに配置することができました。

Federationでは、splitした後に参照用テーブルを更新するには、全シャーディングデータベースの参照用テーブルに対して更新する必要がありました。

Elastic Scale の参照テーブルでは、レプリケーションされます！素敵！
（レプリケーション頻度や、パフォーマンス、同期レプリケーションにできるのかは要確認）

10/3 11:12 修正：勘違い。そんな機能無かった…。

3. 複数シャードへのクエリ発行

Federationでは、特定シャードへのクエリ発行しかサポートされていませんでした。
複数のシャードにまたがるクエリを発行したい場合は、
アプリケーション側で、それぞれのシャードに個別にクエリを発行し取得した結果をアプリケーション側でマージする必要がありました。
ライブラリも提供されていないので、ユーザーが作りこむ必要がありました。

Elastic Scale では複数シャードへのクエリ発行がサポートされます！
UNION ALLを使用して結果セットを返してくれるので、とても楽になりましたね。

4. シャーディングルールがRangeに加えListも可能

Federationで提供されていたシャーディングルールは、Rangeだけでした。
Rangeパーティションですね。
シャーディングキー何番から何番までっと区切っていく方法ですね。

Elastic Scale では、リストシャードマップを作成できます。
何番と何番は、データベースAみたいに指定できるようになり、柔軟なシャーディングが実現できるようになりましたね。

5. シャーディングのセキュリティ強化

Elastic Scale では、シャーディングの実行（マージやスプリット）をできるユーザー、
シャーディングマップを参照だけできるユーザーというように、セキュリティ制御できるようになりました。

Azure SQL Database modified server quota policyが、発表されました。

各論理サーバーにデフォルトで作成できるデータベースの合計DTUが1600に制限されました。
サービスクラス、サービスレベルごとにDTUが定義されています。
そのDTUが合計で、1600までとなりました。

１つのサーバー（ここでいうサーバーは、xxxx.database.windows.netで表現できる論理サーバー）毎に、Basic（DTU5）だと320個までとなりました。
ちなみに、Web、Businessエディションのデータベースは従来の150個が存続しています。

ポータルで使用状況を確認することができます。
上記図の矢印部分で、いくつのDTUを使用しているのかが表示されます。

クリックするとさらに詳細が表示されます。

2014年10月4日（土）に、日本マイクロソフト株式会社品川オフィス31FセミナールームAにて、Japan Azure User Group主催で開催する「SQL Server収穫祭」に登壇しました。

SQL Server 収穫祭

食欲の秋、実りの秋、そして SQL Server / SQL Database の秋です。
Azure で SQL Server / SQL Database の利用に興味のある方、
この機会に情報をがっつり収穫してみませんか!!

今回は SQL Server サポートチームの方をお招きし、セッションを実施していただく機会を設けることができました。
Azure MVP / SQL Server MVP にも登壇いただき、SQL Server / SQL Database 尽くしの一日でお送りいたします。

Azure SQL Database 入門 2014年10月版

Azure SQL Database の新しいサービス層の性能を定義するのに使用されているAzure SQL Database Benchmarkツール。一体、どんなツールで、どうやって計測されているのでしょうか？
そんな裏側の仕組みが気になる方は、ぜひ、「Azure SQL Database for Business-Critical Cloud Applications: (04) Azure SQL Database Benchmark」を視聴してください。約1時間にわたって解説してくれています。

Azure SQL Database Benchmark ツールで、スループットを計測して、その数字をもとにDTUを決定しています。上記画像が、実際のAzure SQL Database Benchmark ツールのスクリーンショットです。

DTUは、ベンチマークパフォーマンスで計測した数字そのものが、使用されていることがわかります。

Azure SQL Databaseでは、フェイルオーバーしていても性能劣化が表に出にくい。ベンチマークツールで計測中に、フェイルオーバーさせたがグラフ上表れにくい。

ベンチマークで使用するテーブル構成のお話。

SQL Server PASS Summitで、Azure SQL Databaseに関する大きな発表がありました。

今年（2014年）中に、Azure SQL Databaseの新しいバージョンのプレビューを始めます。
アプリケーションを簡単にクラウドに移行、拡張できるように次のような機能を提供します。

• オンラインインデックス
• 並列クエリ（プレミアム・エディションのみ）
• テーブルパーティショニング
• ALTERデータベースコマンド
• 共通言語ランタイムとT-SQLの改善（Windows関数）
• XMLインデックス
• 拡張イベントによるモニタリング、トラブルシューティング
• インメモリ列ストアへの対応（プレミアム・エディションのみ）

参考情報

Preview for greater SQL Server compatibility coming soon to Azure SQL Database

Microsoft announces major update to Azure SQL Database, adds free tier to Azure Machine Learning

Azure SQL Databaseのデータベースの状況をモニタリングするためのアプリケーションを開発したときに、使用するデータベースのログイン（ユーザー）についてのお話です。

モニタリング用なので、データベースからユーザーデータが読めたり、データベースの設定をいじれたりしないように、安心でセキュアで信頼できるように最小の権限で設定したいので、最小にする方法が知りたいですよね？
調べた結果をMSDN Blog「Setting up Logins to monitor Azure SQL Databases」に投稿されていたので紹介します。

手順

手順１：LOGINの作成

Create LOGIN APPLOGIN with password=’abcd123?’

手順２：Msterデータベースにユーザー作成

CREATE USER [APPUSER] FOR LOGIN [APPLOGIN] WITH DEFAULT_SCHEMA=[guest]

手順３：対象データベースにユーザー作成

CREATE USER [APPUSER] FOR LOGIN [APPLOGIN] WITH DEFAULT_SCHEMA=[guest]

手順４：対象データベースのユーザーに権限付与

GRANT VIEW DATABASE STATE TO APPUSER

結論

これで、APPLOGINでログインして上げれば、対象のデータベースの動的管理ビューなどは参照できるけど、ユーザーテーブルは参照できないというミニマム権限のモニタリング用ログイン（ユーザー）が作成できました。

次のようなクエリも流せるよ！

データベースサイズのモニタリング

SELECT SUM(reserved_page_count)*8.0/1024
FROM sys.dm_db_partition_stats;
GO

SELECT SUM(reserved_page_count)*8.0/1024
FROM sys.dm_db_partition_stats;
GO

トップ５クエリの抽出

SELECT TOP 5 query_stats.query_hash AS "Query Hash",
SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
MIN(query_stats.statement_text) AS "Statement Text"
FROM
(SELECT QS.*,
SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE QS.statement_end_offset END
- QS.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS QS
CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;
GO

SQL DatabaseからストレージにデータをエクスポートしているとDTUの上限にまで達してしまうのだけど、どうしたらいい？っとstackoverflowで質問されていました。

回答しては、2015年1月段階では次のような状況とのこと。

トランザクション的にデータをエクスポートするには、バックグラウンド大量のクエリを発行する必要があり、フルバックアップが完了するまではクエリが発行され続ける。大きなデータベースだと、そのクエリが原因でDTUの上限に達してしまう。

この問題の解決策としては2つのアプローチが考えられる。

1つ目は、

• 一時的に上位のサービス帯にアップグレードし、エクスポートをする
• エクスポートが完了したら、サービス帯を戻す。

2つ目は、

• ポイントタイムリストア機能を使用して、最も最近のコピーを新しいデータベースにリストアする
• 新しいデータベースからエクスポートをする（既存のアプリケーションに影響を与えずにすむ）
• エクスポートが完了したら新しいデータベースを削除する

2つ目の方法がパフォーマンス上優位な対応。

Microsoft Azure SQL Data Warehouseは、クラウドで提供されるフルマネージドサービスです。柔軟に、性能とストレージをスケールアップ＆スケールダウンさせることができます。

リソースは、ストレージとコンピューティングに分かれており、どちらも必要に応じて日次で増やしたり減らしたりすることができます。

管理画面のサンプル

管理ポータルのUXイメージは次の図。

DWUっという表記があるので、Azure SQL DatabaseのDTUと似たようなイメージで、性能を相対表記する単位を用意し、それでリソース制御する予定。

DWU（Data Warehouse Unit）

DWUは、データのスキャンとデータのロード、テーブル複製の組み合わせで性能測定されている。1B行をスキャンすると、100DWUで297秒、1600DWUで19秒っとほぼ数字通りスケールはする模様。

一時停止機能（Pause）

一時停止機能が用意されている。

データウェアハウスなので、格納するデータは当然膨大となる。使用しない時には削除しておきたいところだけど、削除すると再格納に時間がかかりすぎて無駄。
そこで、一時停止機能。

この機能を使用すると、データの再ロードや再格納が不要でデータを保管しておける。
一時停止中は、クラウドストレージは最少コストで済む。

PowerShell/Rest API経由で自動処理できるようになっているので、スケジュール処理することが可能。

料金体系

気になる料金体系は、性能種別でストレージ単価も変動する仕組みを採用している。

SQL Serverとの互換性

SQL Serverとの互換性はばっちりで、ユーザー定義関数やストアドプロシージャ、テーブルパーティショニング、照合順序、カラムストア（インデックスなど）技術にも対応している。

Polybase/T-SQL経由で非構造型データのクエリ発行

リレーショナルデータベースでもHadoopでも、T-SQLクエリを発行可能。
Polybaseは、マイクロソフトのMPP（Massively Parallel Processing）製品を統合するテクノロジーで、HadoopとSQL Server間をクエリで総合に連携させることができます。

T-SQLのクエリサンプル

まず、データを取得するときの認証情報として、証明書を作成します。

データソースを指定します。

まとめ

いろんなシステムと連携させましょう！

参考情報

• https://channel9.msdn.com/Events/Ignite/2015/BRK2571
• http://azure.microsoft.com/en-us/campaigns/sql-data-warehouse/

投稿Microsoft Azure SQL Data Warehouseの概要は蒼の王座の最初に登場しました。

SQL Database Elastic Pool (Preview)に関しての情報は、だいたい以下のところで把握することができます。

今のところ一番詳細情報を公開しているのがIgnite 2015のセッション「Microsoft Azure SQL Database – New ISV Resource Pooling Model Drilldown: The What, Why and How」です。
続いて、料金体系と性能、実際の使用感に関して、われらがムッシュ金麦が書いているSEの雑記「Elastic Pool Preview を触ってみる その 1」です。
あとは、MSDNライブラリで情報公開されているみたいです。

Elastic Database Poolが必要な背景

アプリケーションの性能向上を目的として、複数のデータベースに分割することがあります。コスト最適化のためにデータベースの特性に応じて、それぞれのデータベースのサイズを決定します。
たとえば、マスターデータベースや普段あまり使用されない機能のためのデータベースは性能が低めのデータベースにし、負荷がかかりやすいデータベースは性能が高めのデータベースにします。（まぁ実際には、「SaaSアプリケーションを想定していて、テナント毎にデータベースを持ち、テナントの負荷別にDBの性能を選択する。普段、使用者が少ないテナントのデータベースに唐突にユーザーが集まってアプリケーションの性能が劣化してしまう」というのが想定しなおリオみたい）

しかし、次の図のようにたまに不幸なことが起こります。
各データベースの性能は問題ないのに、低めに設定していたデータベースに何らかの原因で急に負荷が高まると、そこが性能ボトルネックとなりアプリケーション性能に深刻な影響を与えることがあります。

そこで登場するのが、Elastic Database Poolです。
Elastic Database Poolでは、性能の下限と上限を選択し、突発的な負荷にも対応できるように柔軟な性能を得ることができます。

Elastic Database Poolの課金

Elastic Database Poolは、複数のデータベースでDTUを共有しようというモデルです。
ですので課金のキーポイントの1つがPoolに割り当てるeDTU(Elastic Database Througut Unit)に応じた課金です。
次に、Poolに格納するデータベース数に応じた課金です。データベースの個数に応じて課金されます。

つまり、Elastic Database Poolの料金は次の式で求められます。

227.46円/月/1eDTU × 共有するDTU（eDTU） + 128.52円/月/1DB × DB数

ドキュメントにも書かれていますが、通常のSQL DatabaseのDTUよりも、Elastic Database PooleのeDTUの法が価格単価は高くなっています。（200DTUが17340円で、200eDTUが45492円）

Elastic Database Poolと通常のデータベースを使ったときの料金比較

たまに100DTU近く使うけど、普段は低使用率のデータベースが複数個ある場合をシミュレーションします。

左上が1個のとき、右上が20個のデータベースでは黒線の使用率に収まっている（合計200eDTU）シミュレーション、左下が4個の時。それらをElastic Database PoolとSQL Databaseで料金比較したグラフ。

100DTUのデータベース1個と、200eDTU（DB1個）
100DTUのデータベース2個と、200eDTU（DB2個）
100DTUのデータベース3個と、200eDTU（DB3個）
100DTUのデータベース4個と、200eDTU（DB4個）
100DTUのデータベース10個と、200eDTU（DB10個）
100DTUのデータベース20個と、200eDTU（DB20個）
の料金をマッピングしたときのグラフです。

たまに、100DTUにはねるけど、ほとんどは低使用率のDBをたくさんかき集められたら、圧倒的にElastic Database Poolが有利。でも、DB数が少ないときには、個別に作ったほうが有利となる。

なので、SaaS利用が主体とマイクロソフトは考えている（MSDNドキュメントもメニューにSaaS developer Solutionって書いちゃうぐらい）。

Elastic Poolで登場する係数

次の図のようなサービス帯になっている。
現時点のPreviewで提供されているのは、Standardのみ。

Poolに格納できるDB数

1つのPoolに格納できるのは、最大100個まで。
でも、次の計算式が優先される。

選択したeDTU / データベース毎の最少DTU

たとえば、eDTUを400にし、データベース毎の最少DTUを20としたら、
400/20=20となり、20個のデータベースまで格納することができることになる。

The pool must have room for the database (cannot already contain the maximum number of databases). http://azure.microsoft.com/ja-jp/documentation/articles/sql-database-elastic-pool-portal/

DB毎の最少DTU

DB毎に設定する最少DTU。
これは格納できるDTU数に影響を与える係数となっている。

ここの設定値の推奨は、データベース毎の平均使用DTUに設定すべき。
設定すると、プール内のすべてのデータベースにDTUが付与される。

DB毎の最大DTU

推奨値は、データベースのピーク使用数を設定すべき。
たとえば、100個のデータベースの内、20%がピークで50DTU使用する場合、DB毎の最大DTUは50DTUを設定すればOK。そして、eDTUは1000にすればOK。

ストレージ

ストレージもElastic Database Poolで共有する。
1eDTUにつき1GB付与される。

ワーカー数とセッション数の制限

次の表のように制限があるので注意。

画面構成

プールのeDTU、プールのストレージ使用料

最大DTU数、平均DTU、最大DTUを確認することができる。

実際に使ってみよう！

われらがムッシュ金麦が書いているSEの雑記「Elastic Pool Preview を触ってみる その 1」で説明されているので、それで十分！

今後の計画

• BasicとPremiumのサービス帯を準備する予定
• プール毎に格納できるデータベース数は増やす予定
• プール毎のストレージとDTU数は増やす予定
• プールのデータベース作成と取り外しは、T-SQLで実施できるようにする予定
• V11からV12のPoolに移行できるようにする予定

投稿Azure SQL DB – Elastic Database Poolについては蒼の王座の最初に登場しました。

Channel 9で「Azure SQL DB Transactional Replication」が紹介されていました。
この機能は、SQL Server 2016（Version13）とAzure SQL DB（Version13）、およびSQL Server 2012/2014とAzure SQL DB（Version13）のデータベース移行をスムーズに実現します。

トランザクションレプリケーションによるサブスクライバー機能です。
ダウンタイム無しで、オンプレミスのSQL ServerからクラウドのAzure SQL DBにデータ移行するための機能です。

今のところ、SQL Server 13シリーズで提供される予定。
ちなみにSQL Server 2016は今年の後半提供予定の模様。

レプリケーションオブジェクトがあり、ここから設定していきます。
パブリケーション種類で、「Transaction publication」を選択。

これらを設定すると、同期トリガーとしては、SQL Server Agent jobが使用されるみたい。

これまでは大きなデータベースを移行しようと思うと、ダウンタイムがどうしても長くなりがちだったけど、この機能がリリースされると、移行ハードルが多少下がりますね！

投稿オンプレミスのSQL ServerからAzure SQL DBへの移行用機能「Azure SQL DB Transactional Replication」の紹介（未リリース）は蒼の王座の最初に登場しました。

「Preview: Azure SQL Database Query Store」で、Azure SQL DatabaseでQuery Storeが利用できるようになったことが発表されました。

Query Storeとは

Query Storeは、クエリ履歴とプラン、実行統計情報を自動的に記録します。
この機能を使用することで、クエリプランの変更により発生するパフォーマンス劣化を簡単に特定し、性能問題のトラブルシューティングを簡単にできるようになります。

有効化と使用方法

早速、使用してみましょう（ドキュメントを参照します）。
私用に当たっては、SQL Server 2016 CTP 2.0のSQL Server Management Studioを使用する必要があります。

Azure SQL DatabaseにSSMS 2016 CTP 2.0で接続します。
次に、Query Storeを有効化するために、データベースのプロパティを開いて、有効化をTrueに設定します。

Azure SQL Databaseで、Query Storeを有効化するとオブジェクトエクスプローラーに、クエリストアが表示されます。

追跡したクエリを開き、クエリIDを指定すると次のように実行された時間と、実行計画が表示されます。

投稿Azure SQL Database Query Storeのプレビュー版が公開は蒼の王座の最初に登場しました。

MSDNブログで、「New service update available for SQL Data Sync!」という記事が投稿されました。

最後に、SQL Data Syncのアップデートを発表してから3年以上経過した増したが、その間も顧客の問題に対応するため、バックエンドサービスを継続的にアップデートをデプロイし続けていました。
フィードバックを受け、最近のサービスの変更と新しいSQL Data Syncエージェントのリリースについて発表できてうれしいです。2つの大きな機能強化を含んでいます。

１．テーブル照合順序の動機をサポート

• ハブまたはメンバーデータベースに、まだ同期するテーブルスキーマが存在しない場合、同期グループ上にデプロイすると、SQL Data Syncは自動的に選択した同期スキーマと同じ照合順序の設定で空のデータベースにテーブルと列を作成します。
• ハブにもメンバーデータベースにもすでに同期するテーブルが作成されている場合、同期グループのデプロイが成功するためには、SQL Data Syncはハブ/メンバーデータベース間で同じ照合順序をプライマリキーに持つ必要があります。

２．性能と正常実行力の改善

• 同期元と同期先への変更転送バッチが強化され、同期スループットが速くなっていることを確認できます。
• 転送元からのデータ読み取りや、転送先への書き込み時、エラーハンドリングロジックを改善しました。

新しいSQL Data Syncエージェント

新しいバージョンのSQL Data Syncエージェントは、ダウンロードセンターで入手できます。

それぞれ次のドキュメントを確認し対応してください。

新規インストール：https://msdn.microsoft.com/en-us/library/azure/jj823137.aspx

アップグレード：https://msdn.microsoft.com/en-us/library/azure/hh667308.aspx

古いバージョンのSQL Data Syncエージェントは、期限が切れる2015/8/18までは使用し続けられます。

投稿SQL Data Syncのサービスアップデートの提供については蒼の王座の最初に登場しました。

フォーラムで次のような類似した質問があがっていました。

• SSMSやVisual Studioなしで、Windows Azure上でT-SQLコマンドを実行する方法
• Azure SQL Database管理URL

これに対して、中の人の回答は次の通り。

V11までのAzure SQL Database用には、Azure Management PortalからSQL Serverを管理するための機能が提供されています。
しかし、Azure SQL Databaseの新しいバージョン（v12）用にはまだ提供されていないのです。

なので、ポータル上からもリンクが無いのです。残念。
あとはSilverlightなので、今後を考えると何らかのツールに置き換わるのか、HTML5で実装しなおされていると想像しています。（注：別に非公開情報で知ったとかではなく、推測なので、このままDisconする可能性もあったり…）

投稿Azure SQL Database v12用のWeb上のSQL管理ツールは、まだサポート外は蒼の王座の最初に登場しました。

フォーラムで興味深い情報がMicrosoftの中の人から回答されていたので紹介します。

Azure ポータルで、Azure SQL Databaseのスケールの情報を参照すると次のような記載がされています。

スケール アップに利用可能な DTU 2000 (サーバーで利用できる 1995 + 現在のパフォーマンス レベルに関連付けられている 5)

これの意味について、中の人の解説。

Azure SQL Databaseにはロジカルサーバーの概念があります。
ロジカルサーバーは、物理リージョンでデータベースの集合体です。
それぞれのロジカルサーバー（もしくはデータベースの物理的なグルーピング）には、データベースが接続された特定サーバーによってDTU数が制限されています。

上のスクリーンショットの例では、サーバーで2000DTUが提供されていて、そこから現在5DTUを使用している状態です。つまり、このサーバー上では、残り1995DTUを使用して1つ以上のデータベースを作成できます。
たとえば、ほかにP3（1000DTU）のデータベースと39個のBasicデータベース（Basic1つあたり25DTU）をサーバー上のキャパシティーで使用可能です。

所感

負荷が高まったら、DBをスケールアップさせようと計画している場合は、事前にここの数値を確認し、サーバー上でスケールアップさせる余地が残っているか確認したほうがよさそうですね。

投稿Azure SLQ Databaseの「スケール アップに利用可能な DTU」の意味は蒼の王座の最初に登場しました。

SQL Database Elastic Poolは、POOL DTUに応じてストレージ容量が割り当てられます。
１DTUにつき１GBのストレージが付与されています。

Create and manage a SQL Database elastic pool (preview)

ストレージ容量が上限にまで達すると、Pool内のすべてのデータベースが読み取り専用になります。この状態になった場合は、DTUを増やすか、1つ以上のデータベースを削除するか、Poolから除外するかして対応することになります。

Poolストレージの上限に達してしまうのを防ぐには、ポータルでストレージの容量が閾値を超えたらアラートを飛ばすように設定してください。

元ネタ

SQL Database elastic database pool reference (preview)

投稿SQL Database Elastic Poolのストレージ上限を超えた時の仕様は蒼の王座の最初に登場しました。

2015年9月12日に、V11サーバーと呼称される、Microsoft Azure SQL DatabaseサービスのWeb、Businessエディションの提供が終了すると発表されていました。
今までは、9月12日に、V11サーバーに何が起こるのか明確になっていませんでした。

今朝届いたAzureチームからのアナウンスで明確になりましたね！

自動アップグレードされます

V11（Web、Businessエディション）のAzure SQL Databaseは、
自動的にV12（Basic、Standard、Premiumエディション）に移行されます。

これは自動処理なので、処理が実施される14日前に個別に対象となったユーザーに通知されるようです。

移行は、課金ベースで考えられており、毎月の課金が増えないように設計されています。
その為、データベース容量を元にアップグレード先が決定しています。

つまり性能ベースではないので、移行先によっては、自動アップグレードと同時に
深刻な性能問題に遭遇する可能性もあります。

性能やV12サーバーの機能については、ムッシュ金麦先生がde:code 2015で発表しているので、そちらを見ておくとばっちりです！

具体的な移行先の確認方法

自動移行先の詳細を確認する方法が提供されています。

1. 使用量と課金から課金根拠のResource GUIDを確認します。
2. GUID Migration for SQL Databaseから、１で確認したGUIDを探します。
   見つけたら、新しい移行先を表で確認します。

自動アップグレードの延期（9/12まで）

9月12日に向けて計画してたんだから、勝手にアップグレードするなよ！っと起こりたくなる方もいますよね？

ご安心を。
MSさん、自動アップグレードを9月12日までは猶予する選択肢を提供しています。

メールには、「2015年9月12日まで、このアップグレードを拒否するオプションがあります。」とのこと。 詳細は不明…。

V11でできて、V12でできないこと

• (http://yourservername.database.windows.net)
  Azure SQL Database Management portalが、V12では現在使用することができません。
• SQL Server Management Studio 2014 CU6を使いましょう

最新情報は英語

英語ドキュメントはGithubを使って随時アップデートされているので、
日本語翻訳が間に合っていないので英語を見ましょう。

• Plan and prepare to upgrade to SQL Database V12

メール画像

ポータル画像

投稿9/12までにWeb、BusinessエディションのAzure SQL Databaseは、Basic、Standard、Premiumに移行しよう。自動移行も予告されています、は蒼の王座の最初に登場しました。

SQL Server Management Studio のアップデートがリリースされました。
今回は、SQL Server Management Studio July 2015 となります。

詳細は次のサイトを参照してください。

• SQL Server Management Studio のダウンロード
• SQL Server Management Studio のリリースノート

SQL Server Management Studio July 2015

SSMS バージョン番号：13.0.400.91

1. Azure SQL Databasesで、データベースダイアグラムに対応しました。
   データベースダイアグラムによって、簡単にキー、リレーションシップ、列、テーブルの作成変更が簡単にできます。
2. DacFxライブラリが、最近のAzure SQL Databaseの機能、Azure Active Directory認証と行レベルセキュリティ機能に対応しました。
3. インテリセンスが改良されて、SQL Server 2016の新しい機能Temporal Table（詳細はムッシュBlogで。）に対応しました。
4. 「Check for Update」UIのバグが修正されました。

SQL Server Management Studio June 2015

1. 新しい軽量なWebインストーラーが提供されます。
   
2. 新しい更新の自動確認機能が提供されます。
   

3. 顧客への要望に対応しました。
   ・オブジェクトエクスプローラーで、テーブルとビューの上位200行の編集が可能になりました
   ・Azure SQL Database V12用にテーブルデザイナーが提供されます。
   ・Azure SQL Database V12用のデータベースとテーブルのプロパティダイアログが提供されます。
4. T-SQLの保存確認ダイアログのスキップ機能が提供されました。
   
5. Azure SQL Databaseの新しいサービス帯にImport/Exportウィザードが対応しました。

投稿SQL Server Management Studio July 2015 リリースは蒼の王座の最初に登場しました。

Azure SQL Database は、9/12にWeb、Businessエディションのサービス提供が終了します。新しいサービス帯であるBasic、Standard、Premiumに移行しなければなりません。V11からV12への自動移行も予告されています。

自動アップグレードについては、ポータルにも次のように表示されます。

アップグレードの延期方法

アップグレードを延期するための方法として、PowerShellコマンドレットが提供されています。このコマンドレットは、Azure Resource Managerを使用します。

PS C:\> Switch-AzureMode -Name AzureResourceManager

次に、サブスクリプションへのアクセスを設定します。もっとも簡単な方法は、Add-AzureAccountコマンドレットを使用することです。

設定方法は、ここを参考にしてください。

自動アップグレード関係のコマンドレットを確認してみましょう。

PS C:\> get-help *-AzureSqlServerUpgrade | select -Property Name

Name

—-

Stop-AzureSqlServerUpgrade

Start-AzureSqlServerUpgrade

Get-AzureSqlServerUpgrade

アップグレード日付を変更してみましょう。

変更するには、引数にサーバー名とリソースグループを指定する必要があります。

自動アップグレードの日付を変更し、アップグレードを延期します。

PS C:\> Start-AzureSqlServerUpgrade -ServerName w5axll7xap -ResourceGroupName Default-SQL-SouthCentralUS -ServerVersion 12.0 -ScheduleUpgradeAfterUtcDateTime 2015-06-12

ResourceGroupName               : Default-SQL-SouthCentralUS

ServerName                      : w5axll7xap

ServerVersion                   : 12.0

ScheduleUpgradeAfterUtcDateTime : 6/12/2015 12:00:00 AM

DatabaseCollection              :

アップグレードのキャンセル

キャンセルする方法は2種類用意されています。

ポータルでキャンセルボタンをクリックすることでキャンセルできます。

もしくは、PowerShellコマンドレットもできます。

まずは現在の状態を確認してみます。

PS C:\> Get-AzureSqlServerUpgrade -ServerName w5axll7xap -ResourceGroupName Default-SQL-SouthCentralUS |Format-Table

ResourceGroupName              SerrverName                     Status

—————–              ———-                      ——

Default-SQL-SouthCentralUS     w5axll7xap                      InProgress

アップグレードをキャンセルしてみます。

PS C:\> Stop-AzureSqlServerUpgrade -ServerName w5axll7xap -ResourceGroupName Default-SQL-SouthCentralUS

ResourceGroupName              SerrverName                     Status

—————–              ———-                      ——

Default-SQL-SouthCentralUS     w5axll7xap                      Cancelling

キャンセルが完了し、自動アップグレードが停止した状況を確認してみましょう。

PS C:\> Get-AzureSqlServerUpgrade -ServerName w5axll7xap -ResourceGroupName Default-SQL-SouthCentralUS |Format-Table

ResourceGroupName              SerrverName                     Status

—————–              ———-                      ——

Default-SQL-SouthCentralUS     w5axll7xap                      Stopped

参照元

Azure SQL DatabaseのサポートチームBlogに投稿された「Stopping or Postponing an upgrade to SQL Database V12」をざっくり意訳した投稿です。

投稿SQL Database 自動アップグレードの停止と延期方法（V11からV12へ）は蒼の王座の最初に登場しました。