SQL PASS Summit 2011 at Seattle

今年もシアトルでSQL PASS Summit 2011が開催され、世界52カ国から5,108人のSQLに携わる人が集まりました。セッションは170以上設けられ、Denaliの新機能やSQL AzureのDBサイズ制限が現在の50GBから3倍の150GBまで増加される予定も発表されました。Bob Ward の Inside TempDB は3時間のコースで目玉でした。Tempdbのファイル数が物理CPUの数と一致した場合に劇的なTempDBのパフォーマンスの向上が見られることは以前から知られていましたが、具体的に個数を変化させてパフォーマンス計測を行った結果と、トレースフラグ-T1118を組み合わせた場合ついての考察が紹介されました。(トレース フラグ –T1118 を使うことでExtentの割り当て方法を変更させることができます。詳細はここをご覧ください。) また、Microsoftカスタマー・サービスでは毎年開催しているSQL関連何でも質問コーナー:SQL Clinicを今年も設けました。参加者なら無料で何回でも質問できるので、今年もたくさんの人がERRORLOGやダンプファイル持参で訪れました。SQL Clinicについては、Bob Wardの下記の記事もご覧ください。 Inside SQL Clinic さらにSQL Server MVPによるノウハウが満載な本も紹介されました。SQL Server MVP Deep Dives SQL Server MVP Deep Dives, Volume 2  PASSについての詳細はhttp://www.sqlpass.org/ をご覧ください。なお、来年のPASS Summit 2012 はNov 6-9, 2012 にシアトルで開催される予定です。——Kayoko GraySenior Support Escalation Engineer

0

実行プランを読む – 基本編 (その 3)

  神谷 雅紀 Escalation Engineer   ビューカウントが少なかったので途中終了した「実行プランを読む」ですが、一部の方々からもうしばらく続けて欲しいという要望がありましたので、再開することにしました。 実行プランを見て、そのクエリがどのように実行されているのかを確認する際に、Stop and Go オペレータとともに注意する必要のある動きが Rebind と Rewind です。実行プランを読む – 基本編 (その 1), 実行プランを読む – 基本編 (その 2) に加えて、今回の内容を知っていれば、実行プランを見ることでクエリがどのように動くのかを理解することができるようになると思います。   Rebind と Rewind Rewind とは、データセット内の現在位置を最初の行に戻す動作です。その名の通り、巻き戻し (rewind) です。これに対して Rebind は、ある条件でオペレータが実行された後、再度別の新しい条件で実行されるとともに、行位置を新しい条件によるデータセットの最初の行に移動する動作です。オペレータに新しいパラメータを結び付け直し (rebind)、再実行します。Rebind と Rewind は、どちらも Nested Loops の inner input (実行プラン表示の下側の入力) のみで行われる動きです。   Rebind/Rewind 回数の確認方法 SET SHOWPLAN_XML や SET STATISTICS PROFILE…

1

断片化について

  神谷 雅紀 Escalation Engineer   断片化とは? 一般的に、断片化と言われる状況は、平均ページ密度 (average page density) が低い状況か、または、論理スキャンフラグメンテーション (logical scan fragmentation) の値が高い状況です。   平均ページ密度とは? 平均ページ密度とは、あるテーブルもしくはインデックスに関して、1 ページ (8KB) に、平均どの程度データが詰まっているのかを表しています。値が小さいほど断片化の度合いが大きいことを示しています。 例えば、平均ページ密度が 90% であれば、1 ページ 8KB の 90%、つまり、約 7.2KB はデータを格納するために使用されており、残りの 0.8KB が空きということになります。この場合、1 行のサイズが 0.8KB 未満であれば、このページにもう 1 行入る可能性がありますが、それ以上の大きさであれば、このページにはもう新しい行は入らないので、ページ密度は 90% が最大ということになります。このように、平均ページ密度は、必ずしも 100% にはなりません。 平均ページ密度は、DBCC SHOWCONTIG コマンドの出力に含まれている「平均ページ密度 (Avg. Page Density)」、または sys.dm_db_index_physical_stats のavg_page_space_used_in_percent で確認することができます。 尚、ページ密度は、インデックスを新規作成したり、再構築したりする場合であれば、FILLFACTOR によって指定可能な値です。   平均ページ密度が低いと何が起こるのか?…

1

ODBC API を使用して mdb ファイルからメモ型データを取得する方法

  高橋 理香 SQL Developer Support Eascalation Engineer 今回は最近見つかった、mdb ファイルからのデータ読み取りの問題の対応についてご紹介したいと思います。 1. 基本事項 – ODBC API によるデータの取得方法 ODBC API を使用してデータを取得する最も単純な方法として次のような関数シーケンスで実行する方法があります。   1) SQLExecDirect で SELECT 文を実行する。 2) SQLFetch で結果セットからレコードをフェッチする。 3) SQLGetData で取得したレコード内の列データを取得する。   ※各種 API の詳細はリファレンスをご覧ください。 ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562(v=VS.85).aspx   2. 発生しうる問題 次のような条件で、データの一部が欠ける問題が発生します。 – mdb からのデータ取得である。 – データには日本語 (DBCS) がデータに含まれている。 – データをバイナリ形式 (SQL_C_BINARY) で受け取る。 -…

0

実行プランを読む – 基本編 (その 2)

  神谷 雅紀 Escalation Engineer   実行プランを読む – 基本編 (その 1) では、制御フローとデータフローの話をしました。今回は、若干特殊な動きをするオペレータの話をしたいと思います。   Stop And Go オペレータ 実行プランを読む – 基本編 (その 1) の例のように、ほとんどのオペレータは、自分の Open が呼ばれたら、下位オペレータの Open を呼び出し、Fetch が呼ばれたら、下位オペレータの Fetch を呼び出します。しかし、Stop And Go オペレータと呼ばれるオペレータは、それとは異なる動きをします。 代表的な Stop And Go オペレータが Sort です。Sort は、ご存知のとおり、指定されている順番に行を並び替えるオペレータです。行を順番に並び替えた後でないと、最初の行を上位オペレータに返せません。そのため、Sort は、Open の間にそのほとんどの仕事をします。具体的には、以下のような動きをします。 Open 上位オペレータから Open が呼び出される。 下位オペレータの Open を呼び出す。 下位オペレータの Open 呼び出しが復帰する。 下位オペレータの Fetch…

1

実行プランを読む – 基本編 (その 1)

  神谷 雅紀 Escalation Engineer   前回 CXPACKET 待ちは悪いことか?で、クエリの実行について触れました。クエリがどのように実行されているのかを知るためには、実行プランを見る必要がありますが、実行プランの見方について解説している文書があまりないため、今回は、実行プランの基本的な見方について説明したいと思います。   実行プランとは 実行プランとは、SQL Server がクエリの結果を得るために、そのクエリをどのように処理するのかを表したものです。例えば、select c1, c2 from tabA where c3=1 というクエリの結果を得るために、tabA テーブルの非クラスタ化インデックス ind_tabA を検索して行を絞り込み、その絞り込んだ行をクラスタ化インデックスから読み取り、読み取った行の中から c1, c2 の 2 列の値を取り出す、といったような、クエリ結果を得るためのプロセスを表しています。 実行プランは、内部的には、tree 構造を持つメモリ上のオブジェクトです。SQL Server で表現される場合は、tree 構造の表現として一般的に使われる、上から下へ伸びていく形ではなく、下の図のように、左上にルートを置き、右側に伸びていく形で表現されます。     制御フローとデータフロー この制御フローとデータフローという表現は、Microsoft 社内では聞いたことはありません。この言葉は、数年前にシアトルで開催されていた PASS Conference (PASS = SQL Server ユーザー会) のあるセッションで使われていた言葉ですが、分かりやすい表現だと思いますので、ここでもこの言葉を使いたいと思います。 実行プラン内の各オペレータ (上の例では、Nested Loops や Index Seek) は、3 つの主要なメソッドを持っています。それは、Open,…

1

CXPACKET 待ちは悪いことか?

  神谷 雅紀 Escalation Engineer   パフォーマンスの問題が発生した場合などに、sys.dm_exec_requests.wait_type や sys.dm_os_wait_stats.wait_type を確認することは多いかと思います。これら DMV の結果に示される待機状態の中に CXPACKET というものがあります。この CXPACKET での待機時間が長いことが問題として着目される場合がありますが、その多くは、実際には問題を示してはいません。Books Online sys.dm_os_wait_stats (Transact-SQL) の説明が非常にあっさりとしていることも原因のひとつかもしれませんが、CXPACKET 待ちが悪いことのように誤解されている場面をよく見かけるため、今回は、この CXPACKET 待ちについて説明します。   CXPACKET とは? CXPACKET とは、並列クエリを実行するスレッド間のデータ受け渡しに使用されるパケット (Exchange Packet) のことです。では、待機状態が CXPACKET とはどういった状態でしょうか?並列クエリを実行するスレッドが、パケットを待っている状態です。この状態には 2 種類あります。空のパケットを待っている場合とデータに入ったパケットを待っている場合です。 では、それがどのように発生するのか、具体的に見ていきましょう。   並列クエリにおけるスレッド間のデータ受け渡しがどのように行われるのか この図は、Books Online から抜粋した並列クエリの処理例です。   「ワークフロー」の矢印は、データの渡される方向を示しています。データは下から上に渡され、途中、フィルタされたり、結合されたり、加工されたりしながら、最上位のオペレータである Stream Aggregate まで渡されます。Stream Aggregate の演算結果が、クエリの最終結果となります。 この中には、3 つの並列 (Parallelism) オペレータがあります。Gather Streams が 1…

1

DO’s&DONT’s #9: やらない方がいいこと – ディメンションのキー属性として末尾に全角スペースが格納される恐れがあるカラムを利用する。

小林 真治SQL Developer Support Escalation Engineer SQL Server 2005/2008/2008 R2 を利用した際に、ディメンションキーの末尾に全角スペースがあるために、以下の様なエラーでキューブ処理が失敗することがあります。 エラー——OLAP ストレージ エンジン エラー: 属性キーが見つかりません—— これは、データ末尾に全角スペースが存在する/しない同一のデータが存在し(例えば、「リンゴ」、「リンゴ△」(△が全角スペース)といったデータを想定してください)、その データがディメンション属性のプロパティである KeyColumns カラムとして設定されている場合に、ディメンション処理時に Analysis Services 内部で実行される下記 2 つの各クエリをもとにしたスペースの取扱い方が異なる事に起因し発生します。  a) ディメンションの属性キー取得のために発行されるソースデータベースへのクエリソースデータベースより返された結果をもとに Analysis Services 内部では全角スペースが trim した形で扱われ、そのデータを元に Analysis Services はディメンションを作成します。 b) キューブ処理時にデータソースのファクト テーブルからレコード取得のために発行されるクエリデータ末尾に全角スペースが存在するものと存在しないデータがそれぞれ Analysis Services に返されます。 上記の結果、 Analysis Services にてディメンション属性キーとメジャーのマッピングを行う際に、全角スペースを含む値は、全角スペースを含まない属性キーと異なるデータと判断されます。この動作に起因してデータが不一致となるために、エラーが発生しキューブ処理が失敗します。 この現象の対処策としては、下記の方法が一例として考えられます。 ■Analysis Services のデータソース上のデータをクレンジングする。こちらの対処策は Analysis Services のデータソース上のデータを作成する段階で全角スペースデータをクレンジングする方法となります。末尾の全角スペースを取り除く、または、半角スペースにリプレースする方法があります。 ■Analysis Services のディメンションの…

0

Known Issue: SQL Server 2008/SQL Server 2008 R2 インストール時に "Visual Studio – VsTemplate" の警告イベントが記録される。

高橋 理香SQL Developer Support Eascalation Engineer   今回は SQL Server 2008 または SQL Server 2008 R2 をインストールする際に記録される警告についての情報をご紹介します。    1. 関連テクノロジー SQL Server 2008 SQL Server 2008 R2   2. 発生する問題 SQL Server 2008 もしくは SQL Server 2008 R2 のインストール中、インストールするコンポーネントとして Business Intelligence Development Studio (BIDS) を選択した場合、アプリケーションログに下記のような警告イベントが多数記録されます。 イベント ID: 1 イベントの種類: 警告 イベント ソース: Visual Studio -…

0

DO’s&DONT’s #8: やってはいけないこと – インデックス再構築 (REBUILD) 後のインデックス統計情報更新 (UPDATE STATISTICS)

神谷 雅紀 SQL Server Escalation Engineer   DO’s&DONT’s #7: やらない方がいいこと – インデックス再構築 (REBUILD) 後のデータファイル圧縮 (SHRINK) で、インデックス再構築後のデータベース圧縮を話題にしましたが、似たようなものとして、インデックス再構築後のインデックス統計情報更新があります。 インデックス再構築後に、再構築したインデックスの統計情報を更新すると、それは意味がないか、統計情報の精度を落とします。   なぜ?   DO’s&DONT’s #7: やらない方がいいこと – インデックス再構築 (REBUILD) 後のデータファイル圧縮 (SHRINK)  でも触れていますが、インデックスの再構築によりインデックスは再作成されます。インデックスが再構築される時、同時にそのインデックスの統計情報も作成されます。ここで作成される統計情報は、データサンプル率 100% で作成されます。インデックス作成時には、すべての行が読み取られるため、その読み取られた行を使って、同時に統計情報も作成されるためです。 これは、テーブルにデータがある状態で、新規にインデックスを作成した場合も同様です。 この状態で再度統計情報を更新することは、仮に 100% のサンプル率で更新したとしても、同じことを繰り返す分だけ無駄です。また、統計情報の更新 (UPDATE STATISTICS や sp_updatestats の実行) を行う時、統計を作成するために参照されるデータは、明示的にサンプル率 100% と指定していない限り、既定では、ランダムに読み取られた少数のデータです。ある程度大きなテーブルでは、テーブル全体の行の数パーセントです。せっかく全データを使って作成された統計情報を破棄してまで、少数のデータで統計情報を作り直す必要はありません。サンプルデータは多い方が精度の高い統計になります。 尚、インデックス再構築によって更新される統計は、更新対象インデックスの統計であって、それ以外の統計 (更新対象ではないインデックスや列の統計) は更新されません。   実際に見てみましょう       use tempdb go –…

2