SQL Azure Team Blog

Microsoft Project Code-Named “Houston” CTP 1 (August 2010 Update) – SQL Azure Team Blog – Site Home – MSDN Blogsをざっくりと紹介したエントリーです。

マイクロソフトのプロジェクトコード名”Houston"はSQL Azure用の手軽に使用できるデータベース管理ツールです。

今回の更新を含むHoustonの大きな特徴は、以下の通りです。

  • オブジェクト検索機能を含むナビゲーションパネル
  • データベースの基本情報と使用方法とリソースへのリンクを含むインフォメーションキューブ
  • テーブルデザイナーとテーブルデータエディター
  • Viewデザイナー
  • ストアドプロシージャデザイナー
  • T-SQLエディター

8月更新内容

  • プロジェクト”Houston”は、すべてのデータセンターに配置しました。データベースがホストされているデータセンターと同じデータセンターにあるHoustonを使用することを推奨します。
  • データベースツールバーにrefreshボタンで、サーバーから最新のデータベースオブジェクトのプロパティを取得します。
  • ユーザーインターフェイスとパフォーマンスの強化

プロジェクト”Houston”の参考情報

 

下で紹介するビデオチュートリアルとドキュメントで、プロジェクト”Houston"の機能について学ぶことができます。

Link

Description

SQL Azure Labs portal

Access Project “Houston.”

Video – Tables

This video demonstrates how use Project “Houston” to create and modify a table in an existing SQL Server database.

Video Queries

This video describes how use Project “Houston” to create, modify, execute, save, and open a Transact-SQL query.

Video – Views

This video shows how use Project “Houston” to create, select, and modify views.

Video – Stored procedures

This video shows how use Project “Houston” to create, select, and modify stored procedures.

Blog

Use the SQL Azure blog to read about this Project “Houston” release, and to access the Project “Houston” application.

 

既知の問題

 

このリリースの既知の問題は以下の通りです。回避策については、元記事の英文を参照してください。

問題1:ログオンページでTerms of Useダイアログが繰り返し表示される。

問題2:Start Page上のステータスがRead-onlyと表示される。

問題3:Start Pageを一度閉じると、再表示できない。

問題4:データベースのプロパティは、ログオン時の情報が表示され、自動更新されない。

問題5:プロジェクト”Houston"のユーザーインターフェイスが、ブラウザのズーム率100%で無かった場合、表示が崩れる。

問題6:カラム名、テーブル名、ビュー名、ストアドプロシージャー名が長い場合、表示が途切れる。

問題7:テーブルデザイナーやストアドプロシージャーデザイナーのタイプ選択ドロップダウンリストに、新しく作成したエイリアスタイプが表示されない。

問題8:選択できない暗い表示のSaveボタンが、変更した後、フォーカスが当たっていないユーザーインターフェイスを選択するまで、Saveボタンを選択できるように更新されない。

問題9:オブジェクトを読み込んでいる間、ナビゲーションパネルや新しいワークスペースは正常に動作しない。

問題10:ログオン試行中、クエリ実行中にStopボタンを押しても、動作が停止しない。

問題11:矛盾した規定値が入力される。

問題12:矛盾した規定値が表示される。

問題13:テーブルデザイナーで既存の値を変更し、更新しようとするとエラーが発生する。

問題14:テーブルデザイナーで主キーの指定ができない。

問題15:テーブルデザイナーで既存の主キーの設定を変更しようとするとエラーが発生する。

問題16:エディターやビューのGUIでサポートされていないデータ型がある。binary、XML、Unique identifier、timestamp、geography、geometry

問題17:全てのdate型は、mm/dd/yyy hh:mm:ss AM/PMfで表示される。

問題18:スキーマを変更したワークスペースを閉じたとき、保存していない変更が破棄される。

問題19:ユーザーインターフェイスでは、オブジェクトの削除には対応していない。

SQL Azure Team Blog

Backing Up Your SQL Azure Database Using Database Copy – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

異なるSQL Azureサーバー間でDATABASE COPYを実行した も参照してください。

また記事内に誤りがありますので、コメント欄を参照してください。

SQL Azure Service Update 4のリリースで、SQL Azure上で動作しているデータベースのスナップショットを作成できるようになりました。

本番環境のデータベースを変更する前に簡単にバックアップを作成したり、本番環境のデータベースと同じテストデータベースを作成できるようになりました。

元のデータベースのダウンタイム無しでトランザクション・メカニズムを使用して、バックアップがSQL Azureデータセンターで実行されます。データベースは、同じデータセンター内に新しいデータベースに完全にコピーされます。同じデータセンター内の別のサーバにコピーするか、同じサーバの別のデータベース名にコピーするかを選択することができます。

コピープロセスで作成される新しいデータベースは、コピーが完了した時の時点で元のデータベースとのトランザクション一貫性があります。つまり、スナップショットのタイミングは、コピーを開始した時間では無く、コピーが終了した時間です。

事始め

次のようなT-SQLを使用します。

CREATE DATABASE destination_database_name
    AS COPY OF [source_server_name.]source_database_name

同じサーバーにAdventure Worksをコピーするために、次のようなクエリを実行します。

CREATE DATABASE [AdvetureWorksBackup] AS COPY OF [AdventureWorksLTAZ2008R2]

このコマンドは、コピー先のSQL Azureサーバーのmasterデータベースに接続して実行しなければなりません。

コピーのモニタリング

sys.dm_database_copiesと呼ばれる動的管理ビューを使用することで、データベースのコピー状況をモニタリングすることができます。クエリは次のようなものを使用します。

SELECT *
FROM sys.dm_database_copies

Adventure Worksのコピーの状況は次のように表示されます。

clip_image001

必要な権限

別のSQL Azureサーバーにデータベースをコピーするときは、コピー元のサーバーとコピー先のサーバーに、コマンドを実行するログインとパスワードが同じものが存在していなければなりません。コピー元のサーバーのログインには、db_owner権限が必要で、コピー先のサーバーのログインには、dbmanager権限が必要です。権限についての詳細情報はMSDNのドキュメント(Copying Databases in SQL Azure)を参照してください。

注意点は、コピー先のデータベースとコピー元のデータベースは同じサービスアカウント(Live ID)に所属している必要が無いということです。実際、あなたのデータベースをコピーコマンドを使用して、第三者のサーバーにコピーすることができます。

なぜ他のサーバーにコピーするのですか?

同じサーバーか、別のサーバーにデータベースをコピーした場合、同じデータセンター内で同じリソースを配分することになります。それぞれのサーバーは、同じエンドポイントですが、物理マシンは異なります。このことの詳細は、A Server Is Not a Machineにて説明しています。では、なぜ他のサーバーにコピーするのですか?その理由は2つあります。

  • 新しいデータベースでは、SQL Azureポータルの管理者アカウントを別の物にしたいときです。本番サーバーからテストサーバーにテストサーバーにデータベースをコピーした場合、テスト責任者がテストサーバーにデータベースを作成したり削除したりできるようにします。
  • 新しいデータベースの支払いを、別の支払い用のサービスアカウントに課金されるようにしたい時です。

まとめ

データベースコピーに関する追加情報は、MSDNのドキュメント(Copying Databases in SQL Azure)を参照してください。

SQL Azure Team Blog

SQL Azure Service Update 4 – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

データベースのコピー、ヘルプシステムの改善、複数のデータセンターにマイクロソフトのプロジェクトコードネーム「Houston」の展開を行うService Update 4の公開を開始しました。

データベースコピーのサポート:データベースコピーを使用すると、データセンター内の別のサーバーにデータベースのスナップショットをリアルタイムに作成することができます。
この新しいコピーの特徴は、SQL Azureのバックアップサポートの第一弾で、スキーマを作成したり、元のデータベースに変更を加える前にSQL Azureのデータベースをバックアップすることができます。簡単にSQL Azureのスナップショットを取得できるようにすることは、SQL Azureへの一番多かった要望です。
詳細については、MSDNのCopying Databases in SQL Azureと言うタイトルのドキュメントを参照してください。

MSDNドキュメントの追加:MSDNにDevelopment: How-to Topics (SQL Azure Database)と呼ばれる新しい項目を追加しました。ドキュメントは、Microsoft SQL Azureを使用した場合の共通的なプログラミングタスクの実行方法を紹介したリンク集です。

Houstonの更新マイクロソフトのプロジェクトコード名「Houston」は、SQL AzureのWebベースの手軽なデータベース管理ツールです。HoustonはWindows Azure上で動作しており、SQL AzureデータベースとHouston間の待ち時間を減らすために、複数のデータセンターに配置しました。

SQL Azure Team Blog

Security Resources for the Windows Azure Platform – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳したエントリーです。

SQL Azureのセキュリティ情報を探しているのでしたら、Security Resouces for Windows Azureを見てみてください。このMSDNライブラリの新しいトピックでは、マイクロソフトのエキスパートによって提供されたり、執筆されたWindows Azure Platformのセキュリティに関するウェブキャストや、ビデオ、ブログ、資料へのリンクを提供しています。
Windows Azure、SQL Azure、Windows Azure AppFabricのセキュリティ情報を提供しています。

Windows Azure Platform Information Experienceチームが、新たに公開されたセキュリティ情報を随時更新していく予定です。

SQL Azure Team Blog

Finding Blocking Queries in SQL Azure – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳し紹介したエントリーです。

遅かったり、長い間実行しているクエリは、過度のリソース消費を伴い、クエリのブロッキングの原因となります。つまり、パフォーマンス劣化につながります。ブロッキングの意味は、SQL ServerとSQL Azureで違いはありません。ブロッキングは、ロックによる同時実行制御を行うリレーショナル データベース マネージメントシステムでは避けることができない特徴です。

以下のクエリは、合計時間が長かったり、ほかのクエリにブロッキングされたりして、実行時間が長いクエリのトップ10を表示します。

SELECT TOP 10 r.session_id, r.plan_handle,
    r.sql_handle, r.request_id,
    r.start_time, r.status,
    r.command, r.database_id,
    r.user_id, r.wait_type,
    r.wait_time, r.last_wait_type,
    r.wait_resource, r.total_elapsed_time,
    r.cpu_time, r.transaction_isolation_level,
    r.row_count, st.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as st
WHERE r.blocking_session_id = 0 
    and r.session_id in 
    (SELECT distinct(blocking_session_id)
         FROM sys.dm_exec_requests)
GROUP BY r.session_id, r.plan_handle,
    r.sql_handle, r.request_id,
    r.start_time, r.status,
    r.command, r.database_id,
    r.user_id, r.wait_type,
    r.wait_time, r.last_wait_type,
    r.wait_resource, r.total_elapsed_time,
    r.cpu_time, r.transaction_isolation_level,
    r.row_count, st.text
ORDER BY r.total_elapsed_time desc

ブロッキングの原因は、残念なアプリケーション仕様であったり、残念な実行計画や、インデックスの不足が、ブロッキングの原因となりえます。

 

ブロッキングを理解する

 

SQL Azure上で、一つ目の接続が特定のリソースを共有ロックし、2つ目の接続が同じリソースに共有ロックと矛盾するロックを取得しようとした時にブロッキングが発生します。通常、最初の接続(共有ロック)がリソースをロックしている時間はとても短い時間です。ロックを解放したとき、二つ目の接続は、リソースにロックをかけ、プロセスを続けます。これは普通の動作で、頻繁に発生することでパフォーマンスへの影響はほとんどありません。

トランザクションの続行時間が長くなり、クエリがロックをかけ続けていると、ほかのクエリのパフォーマンスに影響が出ます。クエリがトランザクションを実行しておらず、(かつ、ロックヒント文を使用していない)場合、SELECT分はデータを読み取っている間だけ共有ロックを取得します。INSERTやUPDATEやDELETE分は、実行が終了するまでロックを取得しつづけることで、一貫性とロールバックを行うことができます。

クエリの種類や、トランザクションの分離レベルやロックヒントの使用有無などによって、クエリのロック時間や動きが変わります。詳細については、MSDNを参照してください。

まとめ

 

短くて速くて単純なクエリを多用することがブロッキングの減少につながります。長く大きなトランザクションは、ちいさな塊にし、トランザクション量を減らし、効率のいいSQLを書くようにすることがパフォーマンス観点状重要になります。一つの残念な遅いクエリがブロックすると、ほかの早いクエリまでもが遅くなってしまい全体としてパフォーマンスが劣化してしまいます。