[SQL Azure] プライマリ キーを削除できない

こんにちは、Windows Azure サポートチームです。 SQL Azure に関するお問い合わせの中で、よくあるお問い合わせの一つを紹介したいと思います。   [質問] SQL Server Management Studio から SQL Azure 上のデータベースに接続し、該当テーブル上のプライマリ キーを変更するため、一旦 プライマリ キーを削除しようとしたところ、エラー 40054 “Tables without a clustered index are not supported in this version of SQL Server.” というエラーが発生し、プライマリ キーを削除することができないのは何故? エラー 40054 “Tables without a clustered index are not supported in this version of SQL Server.” というエラーが発生し、プライマリ キーの削除に失敗しました。  …


[SQL Azure] ”インデックスが配列の境界外です。” エラーが発生

こんにちは、Windows Azure サポートチームです。 SQL Azure に関するお問い合わせの中で、よくあるお問い合わせの一つを紹介したいと思います。   [質問] SQL Server Management Studio から SQL Azure 上のデータベースに接続し、該当テーブルをスクリプト化した場合に“インデックスが配列の境界外です。“というエラーが発生し、正常に該当テーブルをスクリプト化できないのは何故? SQL Server Management Studio より、SQL Azure 上のデータベースに接続し、テーブル “dbo.tab1” をスクリプト化します。 “インデックスが配列の境界外です。“というエラーが発生し、テーブルのスクリプト化に失敗しました。   [解決策] ご使用されている SQL Server Management Studio に、SQL Server 2008 R2 Service Pack 1 を適用します。   Microsoft SQL Server 2008 R2 Service Pack 1 http://www.microsoft.com/downloads/ja-jp/details.aspx?familyid=b9aa2dba-7f20-4c0c-9afd-1eebee5a94ea   SQL Server 2008…


[SQL Azure] 管理ポータルに接続できない

こんにちは、Windows Azure サポートチームです。 SQL Azure に関するお問い合わせの中で、よくあるお問い合わせの一つを紹介したいと思います。   [質問] Windows Azure Platform 管理ポータル上より、SQL Azure 上の該当データベースに対して接続のテストは正常に完了するのに、SQL Azure 管理ポータル上で、該当のデータベースに接続できないのは何故? 接続のテストを選択します。 SQL Azure 上の TEST データベースに正常に接続ができることを確認します。 SQL Azure 管理ポータルを開きます。 ユーザー名、パスワードは正しいのにログインに失敗しました。   [解決策] ファイア ウォール 規則に接続元クライアントの IP アドレスを追加します。 エラーを確認すると、IP アドレス **.**.**.19 から、SQL Azure に対する接続が許可されていないことが確認できます。 ファイアウォール規則設定を確認すると、該当の IP アドレス **.**.**.19 が許可されていないことが確認できます。 該当の IP アドレス **.**.**.19 をファイアウォール規則に追加します。 ファイアウォール規則を追加することにより、SQL Azure管理ポータルに接続ができることが確認できました。 ※ 本Blogの内容は、2011年11月30日現在の内容となっております。 — Support…


[SQL Azure] CSS SQL Azure Diagnostics (CSAD)toolのご紹介

  こんにちは、Windows Azure サポートチームです。 今回は、CSS SQL Azure Diagnostics tool をご紹介します。   このツールはSQL Azure のパフォーマンス・チューニングを行う際に便利です。 確認できる内容は以下の5つになります。(具体的な画面例はこのBlogの後半にあります。) 1. Top 10 CPU consumers (もっともCPUが使用されているクエリTop10) 2. Top 10 Duration (もっとも長く実行されているクエリTop10) 3. Top 10 Logical I/O (もっとも多く論理I/Oが実行されているクエリTop10) 4. Top 10 Physical I/O (もっとも多く物理I/Oが実行されているクエリTop10) 5. Recommended missing indexes(インデックスが適切かどうかの診断 ※現在一部開発中) このツールを使うのに必要なプログラムは以下になります。 ・Windows Installer 3.1 / 4.5 ・Microsoft .NET Framework 4 Client Profile…


[SQL Azure] SQL Azure Reporting Previewを使ってみよう

こんにちは、Windows Azure サポートチームです。 今回は先日リリースされた、SQL Azure Reporting Preview をご紹介します。 メインの特徴は以下になります。 ・Report Managerは Windows Azure Platform Management Portal を使います。 ・データソースはSQL Azureを使います。 ・Reporting Serverに接続するためにはWindows Azure Platform Management Portal で設定したアカウントを使います。 サンプルとしてSQL Azure上に作成したデータを参照する下記のようなレポートを作成します。 作業に必要なアイテム すでにSQL Azureをご利用であることを前提としています。 1.SQL Azure Reporting Server の作成先の Windows Azure Subscription 2.SQL Azure上に存在する20MB程度の小さなサンプルテーブルを作成できる領域が確保できるデータベース 3.レポート作成ツール。ここでは下記からダウンロードできるReport Builder 3.0を使います。 Report Builder 3.0 SQL Azure Reporting Serverを作成する まず既存のWindows AzureのアカウントでWindows Azure Platform…


[SQL Azure] 頻繁に実行されるクエリのパフォーマンスを監視する便利なスクリプト

こんにちは、Windows Azure サポートチームです。今回は SQL Azure の頻繁に実行されるクエリのパフォーマンスを監視する便利なスクリプトについてご案内します。 SQL Azureに限らず SQL Server でも使えるスクリプトですが、プロファイラを現在使うことのできない SQL Azureでは下記のスクリプトが便利です。このスクリプトを使うと、頻繁に実行されるクエリをその頻度の順番で最大10個まで出力させることができます。(ただし、データベースごとの出力内容となります。) パフォーマンスを監視するクエリ  SQL Azureに限らず SQL Server でも使えるスクリプトですが、プロファイラを現在使うことのできない SQL Azureでは下記のスクリプトが便利です。このスクリプトを使うと、頻繁に実行されるクエリをその頻度の順番で最大10個まで出力させることができます。(ただし、データベースごとの出力内容となります。) create table #t ( query_hash varbinary(64), query_plan_hash varbinary(64), num_cache_entries bigint, execution_count bigint, min_creation_time datetime, max_last_execution_time datetime, total_worker_time bigint, min_worker_time bigint, max_worker_time bigint, avg_worker_time float ) go insert into #t select top 10 query_hash, query_plan_hash,…


[SQL Azure] データベースの分離レベル(Isolation Levels)について

こんにちは、Windows Azure デベロッパー サポート チームです。本日は、SQL Azure の分離レベルについてご紹介します。 Read-Committed-Snapshot(RCSI)が既定 SQL Azureの ガイドラインと制限事項 に紹介されているように、SQL Azure のデータベースの分離レベルはSQL Server 2005から追加された機能の一つである、行レベルのバージョン管理に基づく分離レベルが採用されており、データベース作成時にREAD_COMMITTED_SNAPSHOT データベースオプションと、ALLOW_SNAPSHOT_ISOLATION データベースオプションは両方とも ON に設定されます。また、SQL Azure では ALTER DATABASE 句を使用し、SET <snapshot_option> を実行することがサポートされないため、ユーザーはこの設定を変更することができません。 行レベルのバージョン管理に基づく分離レベルを採用することのメリット トランザクションによりデータが読み取られるとき、読み取り操作では、読み取るデータに対して共有 (S) ロックが獲得されないので、データを変更しているトランザクションはブロックされません。そのため、読み取りの同時実行性が向上します。また、行のバージョン管理を使用によりデータの読み取りの一貫性をステートメントレベルまたはトランザクションレベルで保証されます。つまり、データ読み取りの一貫性を保ちつつ、変更中のデータに対して読み取りの同時アクセスが可能になります。詳細は 行のバージョン管理に基づく分離レベルの利点 をご覧ください。 行レベルのバージョン管理に基づく分離レベルが採用される際のコスト 行レベルのバージョン管理に基づく分離を使用する場合は、行バージョンの管理と読み取りに必要なリソース使用量が増加というオーバーヘッドがあります。このオーバーヘッドの1つに、データベース行に行のバージョン管理情報を格納するための格納領域の確保(行のサイズの増加)があります。その他の詳細については、行のバージョン管理に基づく分離レベルのコストをご覧ください。 SQL Azureでは、このオーバーヘッドに関するコストよりも、一貫性を保ちつつロックを最小限に抑えるという同時実行の利点の方が上回っていると考えられ、行レベルのバージョン管理が採用されています。 なお、SQL Azureでは、ユーザー データベース のみ課金対象となるので、バージョン ストア 用に利用されるTempDBのデータベースの使用量は課金されません。しかし、一つのセッションによるTempDBの使用量が‘5GBを超える場合、そのセッションはサーバーにより切断されるので、アプリケーションの設計には留意が必要です。(詳細は SQL Azureの高可用性を保持するための仕組み をご覧ください。) 行のサイズの増加はどれくらい見積もったらいい? SQL Azureではデータベース量に基づくエディションやデータベース最大容量の選択を行い、使用量に応じて課金されます。したがってデータベースのサイズは事前にある程度見積もっておく必要がありますが、行レベルのバージョン管理による行のサイズの増加をどのように見積もったらいいでしょうか。 SQL Server 2008 R2 を使って、実際に検証してみましょう。まず、データベース SnapShotisolationTest…


[SQL Azure] 高可用性を保持するための仕組み

SQL Azure の高可用性の仕組み マイクロソフトはService Level Agreement (SLA) にて SQL Azure の月間稼働時間のサービスレベルを99%(2011年3月時点)以上を保つことを定義しています。つまりダウンタイムは月間稼働時間の1%の範囲を超えないことを定義しています。 どうやってダウンタイムの縮小を図っているのでしょうか。様々な工夫がなされていますが、その工夫の一つにマルチテナントと呼ばれる仕組みがあります。SQL Azure では データベースはいくつかのパーティションに分けられ、いくつかの物理的なサーバーに分散して存在しています。またその3つのコピーデータベース(プライマリと2つのレプリカ)も同様にいくつかのパーティションに分けられ、いくつかの物理的なサーバーに分散して格納されます。このように物理的なリソースを複数利用することにより、ハードウェア故障の問題が発生してもデータの損失がないよう、またサービスを提供し続けることができるように設計されています。もちろん、ユーザーはデータがいくつかの物理リソースにまたがって存在することは意識することなく利用することができます。 それでは、1つの物理サーバーに注目するとどんなことが起こっているのでしょうか。1つの物理サーバーにはそれぞれ別々のユーザーのデータがパーティションとして同居していることになります。そのそれぞれのユーザーが、それぞれのデータに対して処理を行っていることになります。例えて言うと、いろんな人が同居するマンションのようなイメージです。そのような状況でサービスレベルをある一定の水準に保つにはいくつかのルールが必要になってきます。例えば、温水が限られているマンションで、ある特定の人がシャワーをとても長い時間利用することがあるとします。当然一人の人が使い続ければ、他の人が使えなくなることが予想できます。みんながある程度一緒に使えるようにするには、使用量の閾値を決める必要性がでてきます。 SQL Azureでも同じように、様々な閾値が設定され、セッションやトランザクションのライフサイクルの管理が行われています。接続先のサーバーのリソースに十分な余裕がある場合には、そのリソースをフルに活用することができますが、リソース不足が検知されると、閾値を越えてリソースを消費するセッションの見直しが図られ、すべてのユーザーが常に一定の水準でサービスを利用できるように設計されています。とくに、長い時間実行されているクエリや、CPUやメモリなどを長時間多く消費する処理などは、ある一定の閾値を超えるとサーバー側で接続を切断します。これをThrottlingといいます。次に具体的にどんな閾値があるのか見ていきましょう。 閾値例 ロック: セッションが1,000,000個を超えるロックを消費すると、そのセッションはサーバーにより切断されます。このとき、エラーコード 40550 が戻されます。ロックがどれくらい消費されているかをリアルタイムに確認するには、sys.dm_tran_locks ビューを確認します。 ログ領域: 単一のトランザクションが1GBを超えてログ領域を消費するとそのトランザクションはサーバーにより終了させられます。このとき、エラーコード 40552 が戻されます。 未コミットのトランザクション: 未コミットのトランザクションが消費するログ領域が、最初のLSNから最後尾のLSN(Current LSN)がログファイルの全サイズの20%を超えた場合、そのトランザクションはサーバーにより終了させられます。トランザクションはロールバックされます。このとき、エラーコード40552が戻されます。 TempDB の使用領域サイズ: セッションが5GBを超えてtempdb 領域を使用した場合、そのセッションはサーバーにより切断されます。このとき、エラーコード40551 が戻されます。 メモリの消費: セッションが16MB を超えるメモリを20秒を超えて使用し続けた場合、そのセッションはサーバーにより切断されます。このとき、エラーコード 40553 が戻されます。 データベースのサイズ: データベースは作成時にMAXSIZEがユーザーにより選択され、設定されます。データベースがこのMAXSIZEに到達すると、データベースは Read-Only となり、トランザクションからの Update/Insert は失敗します。このとき、エラーコード 40544 が戻されます。なお、MAXSIZEは ALTER DATABASE コマンドにより変更できます。 アイドル状態のセッション: SQL Azureデータベースへの接続がアイドル状態になってから30分以上経過すると、このセッションはサーバーにより切断されます。アクティブなリクエストがないので、サーバーはクライアント側にエラーを戻しません。…


[SQL Azure] 接続系の問題に対処する編:アプリケーションのエラーハンドリングへの考慮事項

SQL Server を利用していた際には、アプリケーションからSQL Serverへの接続に関する問題に対し、トレースを仕掛けるなど、様々なトラブルシューティングの手法が用意されていました。SQL Azureでは、SQL Azureのサーバーはマイクロソフトのデータセンターに配置されており、現在個々サーバートレースを仕掛けて調査を行うことはできません。したがって従来のトラブルシューティングの手法とは違う考慮が必要になってきます。ここでは、Activity IDを取得することで、接続系のトラブルに備える方法を紹介します。 Activity IDとは 例えば、SQL Azureのサーバーを作成しようとしたときに、たまたま以下のようなエラーに遭遇して作成できなかったとします。 上記のエラーの詳細情報(赤字の情報)にある activity id ‘fF1b03f47-ddd0-40d8-c13-26b5cc6143f1’ が Activity IDと呼ばれるものになります。この Activity IDは、全てのSQL Azureの接続時に生成されるユニークな GUID で、セッション コンテキスト 情報、トレースID、またはセッショントレースIDとも呼ばれることがあります。マイクロソフトのSQL Azure Developerサポートは、このActivity IDを追跡して、エラーの発生した理由を探ることができる場合があります。その際には、以下の情報もわかる範囲でお知らせください。 Activity ID エラーの発生時刻(上記の例ではUTC Timestampで表記されている時刻となります。) 利用しているデータセンター名 SQL Azureのサーバー名(取得済みである場合) SQL Azure に接続を実施したユーザー名 SQL Azure 上の接続先のデータベース名 Activity IDはSQL Server Management Studioでどうやってみることができる? 上記の図のように、CONTEXT_INFO()関数を使って、現在のセッションのActivity IDを確認することができます。Activity IDは、現在の接続に関するプロパティでは、Session Tracing ID(黄色でハイライトした部分)として表示されています。 アプリケーション内でActivity IDを取得する例 以下はコードサンプルになりますが、黄色でハイライトした部分を実行することにより、ログに記録することができます。アプリケーションを設計する際には、エラーハンドリングを考慮する必要がありますが、Activity IDの取得をアプリケーションの実行ログに記録するようにすることで、トラブルシューティングに備えることができます。…