SQL Azure

現象

Windows Azure SQL Databaseにデータ層アプリケーション（DACフレームワーク）.bacpacをインポートすると、データベースが制限サービスの対象になることがあります。
インポート処理は成功しているように見えるかもしれません。しかし、データベースには、DACのすべてのレコードが含まれていないかもしれません。

解決策

SQL Server 2012 SP1のCU1で修正されています。

情報源

FIX: Data loss when you import a data-tier application from a .bacpac package file to Windows Azure SQL Database

SQL Azure

SQL Data Sync 2012年12月のサービスアップデートがリリースされました。主な更新内容は次の通りです。

  • Windows Azure ポータルにSQL Data Syncがリリースされました。
  • データセンター間の同期性能を改善しました。
  • 全体的な内部処理の性能を改善しました。

徐々に、旧ポータルを使用しなくても困らないように準備が進んでいますね！素敵素敵。

Windows Azureポータルでの操作

SQLデータベースの中に、ヘッダメニューに「SYNC」とボトムメニューに「同期の追加」というメニューと、「新しい同期グループ」、「新しい同期エージェント」というサブメニューが用意されています。

image

同期サーバーと同期グループの追加（クラウドとクラウド）

image

image

image

同期エージェント（クラウドとオンプレミス）

image

 

情報源

New in SQL Data Sync

SQL Azure

SQL Server 2012 データ層アプリケーションフレームワーク（DACFx V3）で提供されているWindows Azure Import/ExportサービスはWindows Azure SQL Databasesの移行や論理バックアップ・リストアをするためのクラウドサービスです。この機能は、Windows Azure 管理ポータルとHTTPエンドポイント経由で使用できます。

最近、このサービスのアップデートで、Export処理時のバリデーションチェックを強化しました。
エクスポートしたBACPACsをAzure上の新しいデータベースにインポート（リストア）できることを保証するためにバリデーションを改善しました。しかし、このバリデーションの改善の影響で、エクスポートの失敗を見る機会が増えるかもしれません。オブジェクトの定義に、3つの識別子の定義名(DBName.dbo.myTableみたいなの)を使用していると失敗します。

シナリオ

HTTPエンドポイントやWindows Azure管理ポータルからImport/Exportサービスを使用してWindows Azure SQL Databasesをエクスポートすると失敗する。

現象

エクスポート処理に失敗し次のようなエラーメッセージが表示される。

“Exception Microsoft.SqlServer.Management.Dac.Services.ServiceException: Error encountered during the service operation. Inner exception Microsoft.SqlServer.Dac.DacServicesException: Validation of the schema model for data package failed. Error SQL71562: Procedure: [dbo].[SampleProcedure] has an unresolved reference to object [MyDB].[dbo].[TestTable]. External references are not supported when creating a package from this platform.”

原因

オブジェクト定義で、3つの識別子の参照名を含んでいると、データベースのエクスポートがバリデーションチェックではじかれて失敗します。

理由

DACFxは、オブジェクト定義（ビューやプロシージャなど）に外部参照を含んているとエクスポート処理を停止します。Azure SQL Databasesはデータベースを跨る外部参照を許可していません。3つの識別子名を含んでいるとデータベースエクスポートを停止します。
もし3つの識別子名を含んだままエクスポートに成功してしまうと、エクスポートしたBACPACをインポートする際に必ずインポートに失敗してしまいます。

3部構成名

SQL Serverではオブジェクトを参照する際に、次のような定義をすることができます。

データベース名.スキーマ.オブジェクト名
(例) AdventureWorks.dbo.userinfo

データベース名とスキーマとオブジェクト名を指定して、オブジェクトを参照します。
この場合、データベース名は同じデータベースでも、外部のデータベースでも指定できます。
しかし、Azure SQL Databasesでは、データベースをまたがった参照はできないので、次のような定義をする必要があります。2つの識別子名

スキーマ.オブジェクト名

詳細は、「オブジェクト名としての識別子の使用」を参照してください

解決方法

データベーススキーマーを変更し、すべての3部構成名を削除し、2つの識別子名に変更します。

外部参照を削除してスキーマーを修正するための多くのツールや手段があります。
たとえば、SQL Server Data Tools（SSDT）を使用することも可能です。SSDTでは、Azure Databaseからデータベースプロジェクトを作成すると、対象プロジェクトにSQL Azureを設定します。Azure用のスキーマバリデーションチェックをし、外部参照に3部構成名を使用しているとエラーとしてエラー一覧に表示されます。

情報源

Windows Azure Import/Export Service and External References

SQL Azure

次期Entity Framework 6で搭載予定の機能に

Windows Azure SQL Databaseのようなクラウド環境で動作するデータベースとの接続が切断されてしまった際に自動的に再接続することでコネクションの弾力性を向上させる

が上がっています。

素敵ですね！
逆に言うと、Entity Framewaork 5までは、自分で作りこむ必要があるのですね！
知らなかった！

情報源

赤副ガスリー副社長のMSDNブログ「Entity Framework 6: Alpha2 Now Available」
搭載予定だから、今回のα2には入ってないのかな。

SQL Azure

Windows Azure SQL Reportingを使用しているとき、レポートの性能改善をするTipsがあります。

レポートがデータセンターをまたがって通信をしているとして、それを確認する方法とそれによる性能への影響を計測することができます。

まずレポートの実行ログを確認します。
Windows Azure管理ポータルを開き、Reportをクリックし、レポートサーバーを選択し、「Download Execution Log」ボタンをクリックします。

ログを確認すると、「Data Retrieval time」が異常に長く見えます。
たとえば、AdeventureWorksを使用して、単純なチャートレポートを生成するレポートを実行したときのログです。

Daata Retrieval timeが、processing/rendering timeよりもとても長くなっています。

ログをよく見ると、レポートではWindows Azure SQL databaseのlet8c0j2n7.database.windows.netを呼び出しています。レポートサーバーは、gejqh25dat.reporting.windows.netです。

Windows Azure管理ポータルで、それぞれを確認すると次のようになっています。

他にロケーションの違いを確認する方法としては、pingを使用する方法があります。

地理的に離れた場所にデータストアとレポートサーバーが設置されていることがわかりました。
香港とアイルランド間のNW遅延が影響して、Data Retrievalが長く（3.3秒）なっていました。

データストアとレポートサーバーを同じデータセンターに配置すると、次の結果のように3.3秒から49ミリ秒に改善しました。

参考

MSDNブログ「A tip on how to improve performance using Windows Azure SQL Reporting」を意訳した投稿です。

実行ログとレポート実行のボトルネックについては次のサイトが参考になります。