※ (追加情報 2011/07/25) SQL Azure データベースの課金に関して、米国本社の担当者も交え、最終的な確認を行いました。結論としては、定義上の最大容量(MAXSIZE)ではなく、実際のデータ容量(Current Size)に基づく課金が行われるという、当初通りの情報が正しい、ということになりました。弊社内の一部の担当者が誤解しており、社内で情報が錯綜したのが誤りの原因でした。謹んでお詫びすると共に、修正した情報を以下に掲載します。なお、本件については SQL Azure の課金に関する FAQ として、近日中に Windows Azure のホームページに掲載される予定です。そちらも併せてご確認ください。
[SQL Azure の課金に関する基本的なポイント]
[具体例その1]
上記のようにデータが含まれている場合の課金は、以下のようになります。
[課金の日割り計算に関するキーポイント]
[具体例その2.]
以下のような場合を考えてみます。(※ 課金サイクルが 1日~翌月 1 日であるとして説明します)
この場合の課金は、以下のようになります。
なお、この例からもわかるように、例えば Business Edition データベースについてコミットメントプランを 5 ユニット分購入しておき、20GB と 30GB のデータベースを作成して利用する、といった形も可能です。(10GB データベースを 5 個作らなければならない、というわけではありません。)
また、データベース内のデータ容量が変化するようなケースでは、適宜、ALTER DATABASE コマンドで MAXSIZE を変更しなくても大丈夫です。例えば、こちらの blog で説明されている以下のようなシナリオの場合でも、特に MAXSIZE を変更しなくても、きちんとその日のピークサイズに合わせて課金が減る仕組みになっています。
ちなみに本件なのですが、本当に社内でえらい目に遭いまして;、会う人会う人みんな言うことがちょっとずつ違う、というひどい状況に遭いました;。最終的に上記の情報にたどり着くまでに 2 ヶ月近くもかかってしまう、という事態になり、皆様には本当にご迷惑をおかけしました。やり取りしたメールスレッドが 100 通超えてるってどうよ……状態です;。ホントに;;。
なにはともあれ、一時的とはいえ誤った情報で皆様を混乱させてしまったこと、本当に申し訳ありませんでした。謹んでお詫びすると共に、上記の通り訂正します。オフィシャルな情報としての FAQ への掲載については、現在、弊社製品部が対応中ですので、今しばらくお待ちください。よろしくお願いいたします。