SQL Azure

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

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

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

image

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

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

image

image

SQL Azure

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 では、シャーディングの実行(マージやスプリット)をできるユーザー、
シャーディングマップを参照だけできるユーザーというように、セキュリティ制御できるようになりました。

SQL Azure

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

image

記録できるイベント

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

  • データへのアクセス
  • スキーマーの変更(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]を有効化し、監査設定ブレードを表示する

    image

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

監査ログを記録する方法

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

通常の接続文字列:<server name>.database.windows.net

監査ログを記録する接続文字列:<server name>.database.secure.windows.net

監査ログの分析とレポート

ログデータを素早く分析するのを支援するために、予めてダッシュボードレポートテンプレートを設定したExcelスプレッドシートをダウンロードします。自分の監査ログでテンプレートを使用するために、Excel 2013とPower Queryが必要です。テンプレートは、Azure Sotrageアカウントから直接監査ログをインポートして、Power Queryが処理されます。

 

image

ポータル上では、次のような管理ビューで表示されます。

image

 

ログフォーマット

監査ログは、Azure ストレージアカウントのAuditLogsという名前の1つの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

SQL Azure

Azure SQL Database のサーバーを作成すると、昔はシステムによってランダムな文字列が付与される味気ないサーバー名となっていました。

image

こんなサーバー名は正直覚えられません。すっごく不便。名前を自由につけさせて欲しい!って数年ぐらい思っていました。
今日、知ったのですが、Azure SQL Databases のサーバー名をユーザーが指定できるようになっています。新しいプレビュー版のポータルで。

 

SQL Databaseのサーバー作成画面を開きます。

image

 

そーすると、サーバー名を入力できるようになっています!

image

 

まだ、あまり知られていないみたいなので、結構メジャーな単語でもデータベース作成できますよ!

image

ちなみに名前の存在チェックは微妙に動作していないので、azure.database.windows.netが作成できそうだったので、作成したらすでに存在しているとエラーが発生するという…。ご注意をw

image

image

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

SQL Azure

1. Azureモバイルサービスでスケジューラーを提供

モバイルサービスを作成して、スケジューラーを作成してジョブを実行する。
たとえば次のようなコードを実行する。

 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);
         }
     });
 }

2. オンプレミスのデータベースサーバー上のSQLジョブを作成する

身も蓋もない話ですが、オンプレミスのSQL ServerのSQL Agent ジョブを使用して、敵ジョブを実行する方法ですね。

これには、sqlcmdツールを使用して、Azure SQL Databasesに対してクエリを実行します。

もしくは、オンプレミスじゃなくて、Azure IaaS(仮想マシン)上のSQL ServerのSQL Agentジョブを使っても良いですね。

 

元ネタ:Scheduling job on SQL Azure