今回は拡張イベントでソート時の tempdb の利用を確認してみたいと思います。

■Sort Warning イベントの発生

ソート時に tempdb が利用されると実行プランに警告が表示されます。

この時、[Sort Warning] というイベントが発生しています。

tempdb を使用したソートが行われたかどうかはこのイベントを取得することで確認ができます。
確認の方法としては、SQL Server Profiler / 拡張イベントがあります。

SQL Server Profiler で確認する場合は Errors and Warnings の Sort Warnings というイベントを取得すること確認ができます。

拡張イベントの場合は、sort_warning のイベントを取得することで確認ができます。

今回は拡張イベントを使用して情報を取得してみたいと思います。
先ほどのイベントを使用した拡張イベントを作成してライブデータを取得すると以下のような情報が取得できます。

拡張イベントのデータはログに取得することができますので、後追いでどのクエリのソートで tempdb が使用されたかを確認することができます。

イベントにはほかにも種類がいくつかあり、Hash Warning というイベントもあります。
これはハッシュ結合時にワークスペース領域のメモリが不足し、tempdb が利用された場合に発生するイベントとなっています。

tempdb の負荷が高い場合は一時テーブルや行バージョニングの利用以外にも、これらの結果セットを作成するために負荷が高くなっている可能性がありますので、いろいろな見方を検討する必要が出てきます。
tempdb がどの用途で利用されているかは、sys.dm_db_file_space_usage で確認をすることができますので、定期的に確認をするとよいかもしれないですね。
Server 2008 R2 までは、上記の DMV は tempdb の情報取得用だったのですが、SQL Server 2012 では全データベースで使用ができるようになりましたので、USE tempdb やtempdb.sys.dm_db_file_space_usage というように明示的に tempdb を指定する必要がありますので少し注意が必要になってきます。
# ハッシュ結合時のハッシュテーブルの作成は、internal_object_reserved_page_count に上がってきたはずです。

他のイベントの発生条件を調べてみると状態管理の運用をする時に役に立つかもしれないですね。

今回の投稿ではこの動作についてみていきたいと思います。

■ソートと tempdb の利用について

今回は以下のようなテーブルを作成しています。

Col1 にクラスタ化インデックスを作成しています。

このテーブルには 5MB 程度のデータが格納されています。

このデータを使用してソート字の処理を確認してみたいと思います。

最初はクラスター化インデックスを使用した (ソート順もクラスター化インデックスのソート順と同じ) を実行してみます。

インデックスは特定の列によってソートされた状態でデータが格納されますので結果セットがインデックスの列だけで賄え、ソートする必要がない場合は、全件取得はソートを行わない単純なデータ取得となります。

この際に、fn_virtualfilestas のデータを実行前後で取得してみました。

データベース ID = 2 は  tempdb になるのですが、Read / Write 共に増加していない = tempdb に I/O が行われていないことが確認できます。

次に、ソートをクラスター化インデックスに含まれていないデータに対して実行してみます。

先ほどは並列クエリで実行されてはいなかったので、今回のクエリは同じ CPU の使用状況にするため、並列度を制限しています。

先ほどとは異なり実行前後で tempdb の Read / Write が増加しているのが確認できます。
それでは、実行プランを確認してみます。

今回はインデックスに含まれていない列を使用してソートしていますので、ソートのプランが含まれているのが確認できます。
Sort ですが警告マークがついています。

プランのアイコンにカーソルを合わせると以下のような情報が表示されます。

ソート時に tempdb が使用されたことがプランから確認することができます。
今回、ソートに使用しているデータは 5MB 程度の少量のデータです。
使用している SQL Server には 16GB のメモリを搭載しているため、データはメモリ上に余裕をもって格納でき、ソート時に使用される Workspace Memory も十分に確保できる状態です。

この状態でもプランによっては tempdb が使用されることがあります。

先ほどのクエリを並列度を制限しないで実行した場合はこのようになります。

警告は表示されておらず、tempdb は使用されていない状態となっています。
並列クエリで実行した場合は tempdb が使用されないかというとそういうこともなく、データのサイズと並列度の次数によっては tempdb が使用されます。

今回は SQL Server 2012 の SSMS を使用しているのですが、2008 R2 までの SSMS でも警告マークは表示されていました。

ただし、アイコンの詳細を表示した際に、tempdb が使用されていることを示すメッセージは表示されていなかったようです。

ソート時やハッシュ時には tempdb が使用されることがありますので、メモリで処理がすべて完結していると思わずに、プランを見て使用されていないかを確認するのは重要になって来るかと思います。

SQL Server 2012 ではクラスターで tempdb にローカルのディスクを使用することができます。
サーバーにディスクスロットや PCI スロットに接続ができる SSD を搭載して、tempdb を配置することで、物理構成面で最適化ができるようになりますので、tempdb 負荷が高いクラスターの環境では tempdb をローカルの高速なディスクに配置するチューニングができるかと思います。

単純な動作でも調べてみると、意識していなかったことがいろいろと見えてきます。
DB は奥が深いですね～。

Pocket Consultant は翻訳されるとオフィシャルマニュアルとして発刊されていたと思うのですが、今なら電子書籍が $15.99 で購入できるのでゲットしてみました。
# ちなみに私は英語は情けないほどできません…。

まだ、Columnstore Index のページしか眺められていないのですが、新機能についても触れられています。
ぱらぱらっと読んだ限りは、Columnstore Index については数ページにわたって記載されていたのですが、Always On についての記載はあまりなさそうですね。
Filte Table/Indirect Check Pointも紹介はされていますが、さほど記述は多くないかもしれないです。

新しい発見があると思うので時間がある時に PDF をぱらぱらと読んでいきたいと思います。

既定のユーザーは [空き時間情報] のみ参照が許可されており、実際の予定は見ることができません。
企業によっては原則として全員の予定の内容 (プライベート設定されている予定は除く) を見れることを求められることがあります。

ユーザーが自分で設定を変更することで予定表を公開することができますが、ユーザーの作業を発生させずに、管理者が一括で設定をすることを求められることがあります。

今回は予定表のアクセス権を一括で変更するための方法を見ていきたいと思います。

■PowerShell を使用して一括でアクセス権を変更

Exchange Online の操作は PowerShell を使うことができますので、PowerShell で一括変更をしてみたいと思います。

上記のスクリプトは "既定" のアクセス権を AvailabilityOnly (空き時間情報) に設定しているのでデフォルトの設定と同じにしています。

アクセス権は、

等を設定することができます。
また、ユーザー設定のアクセス権も設定ができるので [ReadItems、CreateItems、EditOwnedItems、DeleteOwnedItems、EditAllItems、DeleteAllItems、CreateSubfolders、FolderOwner、FolderContact、FolderVisible] 個別に設定することで、ユーザー指定の権限を付与することもできます。

ユーザーがメールボックスにアクセスする前は、予定表は Calendar というオブジェクト名になっているので、その対策として [予定表] で権限の設定が失敗した場合は [Calendar] に対して権限を設定するようにしています。

今回のスクリプトではメールボックスを持っているユーザーを対象としていますが、ユーザーの属性を使用してフィルタリングができますので、特定の部署の場合は権限を設定するということもできます。
# foreach 内で、条件分岐する方法をとることもできるかと。

アクセス権は以下のようなスクリプトで確認することができます。

展開時にデフォルトでどこまで予定表が見えるようにするかは悩ましいところではありますが、空き時間情報だけだと電話応対で困ることがあるかな～と思っています。
会議で離席なのか外出で離席なのかわからないと取次方法に困りますよね。

Ofice 365 の Exchange Online のベースは Exchange 2010 ですので、オンプレミスの Exchange 2010 でも使うことができるかと。
# 試せていないですが…。

このようなファイル構成の場合、どのようにデータが書き込まれるかを見てみたいと思います。

■複数データファイルで構成している場合のデータ書き込み

データファイルを複数の物理ディスクに配置することでデータを分散させることができ、ディスク負荷を抑えることができます。

このファイルに 1 レコード 700 バイトのレコードを 20 件挿入してみます。
今回は 4 つのデータファイルを使用しているので、各データファイルに 5 件ずつデータが挿入され、分散されるでしょうか??

SQL Server ではデータは 8KB のページに対して書き込みが行われますが、ページを格納するための領域はエクステントとして、64KB 領域の中に確保されます。

データの書き込みを行う場合には

1. 64KB のエクステントを特定のデータファイルに確保
2. エクステント内の 8KB ページを使用してデータを格納

という流れになります。

そのためデータの書き込みを行う際にはエクステントを確保したデータファイル内にデータの書き込みが行われます。

先ほどのデータ書き込みであれば特定のデータファイル に 20 件のレコードが格納されることになります。

10 レコードで 8KB ですので現状、64KB エクステント内の 2 ページ分の領域が使用されていることになります。
エクステント内には 8 ページ格納できますので、さらに 60 レコード (6ページ分) 挿入してファイルの使用状況を確認してみます。

エクステント内のページが使用し終わるまでは特定のファイルに対して書き込みが行われます。
今の状況で、エクステント内のページはすべて使用し終えている状態となっています。
この状態でさらに 1 レコード挿入してみます。

エクステント内のページはすべて使用が終わっているため新しいエクステントの割り当てが行われます。
この時のエクステントの割り当ては今まで使用していたファイルグループとは異なるファイルグループに対して行われます。
# スタートアップオプションや、ファイルの空き状況によっては同じファイルグループが使用されることもありますが。

ファイルグループに複数のファイルを配置した場合、エクステント単位でデータの書き込みが各ファイルグループに分散されることになります。
そのため、単純に 1 レコードの書き込み速度を上げたいという場合には、ファイルグループ内にデータファイルを増やすのではなく、データファイルに使用するディスクのスピンドル数を増やす必要が出てきます。

ストレージのディスク本数には限りがありますので、データファイル数とスピンドル数をどのようにするかは悩ましいですが、ディスク I/O の効率を考える場合にはこの辺の動作を意識しておきたいですね。

今回の投稿ではこの設定がどのように動作に影響するのかを確認してみたいと思います。

実際の環境だとデフォルトの設定のまま変更することは少ないと思いますが。

■デフォルトの設定の動作

SQL Server の PROCESS AFFINITY の設定はデフォルトでは自動になっています。

この状態では SQL Server はすべての CPU を使用可能となっています。

この状態で、以下のクエリを実行してみます。

DECLARE @i int = 0 WHILE (0=0)     SET @i += 1

単純な計算を永久ループするクエリです。
この時の CPU の使用状況ですが以下のようになっています。

特定の CPU を常に使用して処理をするのではなく、使用される CPU が分散していることが確認できると思います。

SQL Server のデフォルトの CPU の使い方はこの状態となります。
SQL Server は SQLOS のスケジューラーを使用して処理を行っています。

デフォルトの設定ではスケジューラーは特定の CPU と固定でマッピングはされておらず、CPU の利用状況に応じて柔軟に使用する CPU を切り替えて処理を進めていきます。

■PROCESS AFFINITY を設定

次に PROCESS AFFINITY を設定してみます。

すべての CPU を使用するように明示的に設定をしている状態となります。
全 CPU を使用するというのは先ほどと変わらないですね。

それではクエリを実行してみます。

先ほどとは異なり、特定の CPU のみを使用して処理がされているのが確認できます。

これが、BOL に記載されている

ハードウェア スレッドを CPU に関連付けます。

の効果になります。

スレッドが CPU 間を移動しなくなり、固定化されることによりレスポンスがあがるかは環境に依存するのできちんとテストする必要があります。
# コンテキストスイッチを減少させるために設定するという文献があった記憶がありますが。

たまにクエリを実行して CPU 負荷を上げようとした際に思った挙動にならなくてなんでだろうということになるので、動作について軽くまとめてみました。

今回はエディション/BI/会計データ/カラムストアインデックスと広いセッション内容となっております。

BI のセッションに関しましては日本マイクロソフト様のプレミアフィールドエンジニア (PFE) の方にご担当いただけることになりましたので個人的にも期待大です!!

私はSQL Server 2012で初めて実装されるカラムストアインデックス (CSI) の基本についてお話させていただく予定です。

今回は LT の募集も行っておりますので、お話しいただける方がいらっしゃいましたらぜひぜひお願いいたします。

この記事の中に

多数のクライアント接続があり、多数のリクエストを受け付けている SQL Server が生成するすべてのイベントをひとつの Profiler で受け取ることになるため、Profiler がボトルネックとなり、SQL Server 全体のパフォーマンスが著しく悪化し、実行中のクエリがタイムアウトする、ログインがタイムアウトする、場合によっては、クラスタやミラーリングのフェールオーバなどを招くこともあります。Profiler GUI は、ひとつの普通のクライアント接続を通じて、SQL Server からトレースイベントを受け取ります。当然、その接続で転送できる量は限られており、また、それをグラフィカル表示しなければならないため、SQL Server 側で生成されるイベント量が、Profiler が処理できるイベント量の限界を超える状況になると、SQL Server 側では新たなイベントを Profiler に渡せなくなり、イベントを生成している一般のクライアントは、イベント書き込み待ち状態になります。

という記載があります。

イベント書き込み待ちが発生するということは待ち事象が出ないかなと思ったので少し調べてみました。

■SQL Server Profiler と SQL Trace の待ち事象

SQL Profiler を実行している状態の待ち事象を拡張イベントで確認してみます。
今回は SQL Server 2012 を使用しているため、拡張イベントを使用した待ち事象の取得がとても楽です。

プロファイラのイベント書き込みに関する待ちは上記のような事象が発生していそうです。

それでは同じトレースを SQL Trace で実行してみます。
SQL Trace の設定方法に関してはサポートチームのブログ記事がわかりやすいです。
SQL トレーススクリプトの作成、実行 (SQL Server 2005, 2008, 2008 R2)

待ち事象を確認した結果がこちらになります。

Session ID 11 はトレース用のセッションになるようです。

SQL Server Profiler の場合は、TRACEWRITE という待ち事象が追加で発生しているようですね。
この待ち事象が何を表しているのかを sys.dm_os_wait_stats から調べてみます。

TRACEWRITE

SQL トレースの行セット トレース プロバイダーが、空きバッファーまたは処理するイベントを含むバッファーのいずれかを待機しているときに発生します。

SQL Server Profiler 特有の待ちではなさそうですが、GUI でトレースを実行した場合はこの待ち事象が多くなるのかもしれないですね。
トレース系のイベントはほかにも用意されていますで、ポリシーベースのQoS等で意図的に回線を抑える等をして SQL Server を実行している端末以外から Profiler を接続してみれば、さらに詳細な待ち事象の動きがつかめるかも。
# 今回は SQL Server 上で Profiler を実行しています。

Windows 7 とボリュームライセンス版の Office 2010 で MAK のライセンス認証をするためには管理者権限が必要になります。

今回の投稿ではライセンス認証を一般ユーザーの権限 (Users グループ) で実行するための方法をまとめてみたいと思います。

■ユーザー権限でライセンス認証を実行

Windows 7 でユーザー権限でライセンス認証を実行するためにはレジストリを変更する必要があります。
ボリュームアクティベーション展開ガイド

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform] に [UserOperations  : 1 (DWORD)] を設定することでユーザー権限でライセンス認証をすることができます。

ただし、ライセンス認証の GUI ではシールドアイコンが表示されたままで、管理者権限が必要となるようです。
一般ユーザーでライセンス認証をするためには、[slmgr.vbs] を使用します。

リテール版の Office 2010 ではライセンス認証は一般ユーザーの権限で実行することができるのですが、ボリュームライセンス版の Office 2010 の場合は、管理者権限が必要なように設定がされています。
Office 2010 のボリューム ライセンス認証を計画する

[HKEY_LOCAL_MACHINE\Software\Microsoft\OfficeSoftwareProtectionPlatform] に [UserOperations : 1 (DWORD)] を設定することでユーザー権限でライセンス認証をすることができます。

Office 2010 の場合はユーザー権限でも GUI から認証ができるようです。
ospp.vbs でも認証できるかもしれませんが検証ができていません。

MAK の場合、ハードウェア構成が変わると再ライセンス認証が必要となってしまう可能性があるので、一般ユーザーがライセンス認証をできるようにするかは考慮しておく必要があるかと思います。

Office 2010 の場合は Sysprep を実行するとライセンス認証の状態がクリアされますので、MAK を使用している場合は初回起動時は再認証が必要になります。
一般ユーザーの権限しか渡さない場合は、管理者が PC を配布する前にライセンス認証を行う等の対応が必要になりますので、ライセンス認証をどのように行うかは要件等かと。

System Center Advisor
System Center Advisor Released – Proactive Server Configuration Management

SA が必要になるのでしょうかね。

Frequently Asked Questions によると、日本でも利用できるようです。

RTW になってどのように変わったかは時間があるときに見てみたいと思います。