SharePoint 2010 RTM のメインストリーム サポートが 2012 年 7 月 10 日をもって終了となりました。

これにより、ビルド番号が 14.0.6123.5003 以降の CU (2012 年 8 月以降の CU) ではすべて SharePoint 2010 SP1 を適用していることが必須となりますのでご注意ください。

今後新たに環境を構築される際には、SharePoint 2010 SP1 を忘れず適用するようにしましょう！

補足：MOSS 2007 のメインストーリーム サポートはあと 3 か月ですね。メインストーリーム サポートの終了後はセキュリティ更新プログラム以外の修正プログラムがリリースされませんのでご注意ください。SharePoint 2010 への乗り換えはお早めに！！

<参考>
タイトル：マイクロソフト サポート ライフサイクル
URL：http://support.microsoft.com/lifecycle/?ln=ja

皆さんこんにちは。

SharePoint サポートチームの荒川です。

前回に引き続き、今回は、障害が発生したクエリコンポーネントの復旧についてお話ししたいと思います。

クエリ コンポーネントがダウンすると、MinimumReadyQueryComponentsPerPartition の設定次第では、クロールが中断されることになります。また、仮に MinimumReadyQueryComponentsPerPartition の許容範囲内であったとしても、ユーザーに定期的に「内部サーバーエラー」が返されてしまうのは健全な状態とは言えないため、できる限り早く問題を解決しなければなりません。

前回お話ししたように複数台で構成されたクエリコンポーネントのうち、1 台が停止している状態でクロールを実施した場合、TimeBeforeAbandoningQueryComponent で指定された時間が経過すると、アクセスできないクエリ コンポーネントが使用不可としてマークされ、"無効" と設定されます。

"無効" とマークされたクエリ コンポーネントについては、そのまま放っておいても自然に復旧することはありませんので、後述の PowerShell コマンドレット (Restart-SPEnterpriseSearchQueryComponent) を使用して、回復させるか、一旦クエリ コンポーネントをトポロジから取り除き、再構成を行う必要があります。

図1：クロール処理中に1台のクエリサーバーを強制的にシャットダウンした状況。クエリ サーバーから応答が返されないため伝達状態では「クエリ サーバーから応答なし」と表示される。

図2：アクセスできないクエリ コンポーネントが無効としてマークされた状態。

■クエリコンポーネントの復旧手順

クエリ コンポーネントの復旧手順は大きく分けて 2 通りの方法があります。

1. クエリ コンポーネントを明示的に無効に設定する/再起動する

2. クエリ コンポーネントをトポロジから除去/復旧する

1 の方法では比較的簡単に復旧ができますが、障害の種類によっては 2 の方法によりクエリ コンポーネントを再構築する必要があります。

1. クエリ コンポーネントを明示的に無効に設定する/再起動する

ネットワーク障害や明示的なシャットダウン等により、クエリコンポーネントが一時的に使用不可としてマークされただけで実際にハードウェア障害などのデータ損失が生じていない場合には、クエリ コンポーネントを再起動するだけで復旧できる場合があります。

a) クエリ コンポーネントを明示的に無効に設定する方法

1) SharePoint 2010 管理シェルを管理ユーザーで起動します。

2) 以下のコマンドを 1 行ずつ実施します。

$ssa =  Get-SPEnterpriseSearchServiceApplication -Identity "<Service Service Application 名>" (例 : -Identity "SSA1" 等)

$qc = $ssa | Get-SPEnterpriseSearchQueryTopology -Active | Get-SPEnterpriseSearchQueryComponent

$component = $qc | where {$_.ServerName -eq "<無効にするクエリ コンポーネントが構成されているServer名>" } (例 : where {$_.ServerName ?eq "SP2010-2" })

$component.SetOffline

b) クエリ コンポーネントを再起動する方法

1) SharePoint 2010 管理シェルを管理ユーザーで起動します。

2) 以下のコマンドを 1 行ずつ実施します。

$ssa =  Get-SPEnterpriseSearchServiceApplication -Identity "<Service Service Application 名>" (例 : -Identity "SSA1" 等)

$qc = $ssa | Get-SPEnterpriseSearchQueryTopology -Active | Get-SPEnterpriseSearchQueryComponent

$component = $qc | where {$_.ServerName -eq "<再起動するクエリ コンポーネントが構成されているServer名>" } (例 : where {$_.ServerName ?eq "SP2010-2" })

$component | Restart-SPEnterpriseSearchQueryComponent

2. クエリ コンポーネントをトポロジから除去/復旧する

クエリ コンポーネントを実施するサーバーがダウンした場合など、単にコンポーネントを再起動するだけでは対応できない場合には、一旦クエリコンポーネントをトポロジから削除して、再構成する必要があります。

a) クエリ コンポーネントの除去

1) サーバーの全体管理画面から、"アプリケーション構成の管理" セクションにある [サービス アプリケーションの管理] をクリックします。

2) [Search Service Application] を選択して、[管理] をクリックします。

3) [検索管理] 画面の "検索アプリケーションのトポロジ" セクションにおいて、[変更] をクリックします。

4) 削除するクエリ コンポーネントのメニューから、[削除] を選択し、[トポロジの変更を適用] をクリックします。

5) トポロジの変更の適用処理が実施されます。

6) "Search Service アプリケーション <サービスアプリケーション名> の構成変更に成功しました" というメッセージが表示されることを確認し、[OK] をクリックします。

b) クエリ コンポーネントの復旧

1) サーバーの全体管理画面から、"アプリケーション構成の管理" セクションにある [サービス アプリケーションの管理] をクリックします。

2) [Search Service Application] を選択して、[管理] をクリックします。

3) [検索管理] 画面の "検索アプリケーションのトポロジ" セクションにおいて、[変更] をクリックします。

4) 現在存在するクエリ コンポーネントのメニューから、[ミラーの追加] をクリックします。

5) "ミラー クエリ コンポーネントの追加" 画面において、"クエリ コンポーネントを追加するサーバー"、"インデックスの場所" を指定して、[OK] をクリックします。ここでは問題が発生しており、復帰したサーバーを指定します。

6) [トポロジの変更を適用] をクリックすると、トポロジの変更の適用処理が実施されます。

7) "Search Service アプリケーション <サービスアプリケーション名> の構成変更に成功しました" というメッセージが表示されることを確認し、[OK] をクリックします。

補足：復帰したサーバーに、削除済みのクエリコンポーネントのインデックスフォルダが残っている場合、該当のサーバーから削除します。

  例)

  追加されたクエリ コンポーネント : クエリ コンポーネント 3

  削除したクエリ コンポーネント : クエリ コンポーネント 1

上記の場合、該当のサーバーに削除済みクエリコンポーネントのインデックス フォルダを削除します。

インデックスフォルダ(既定) : C:\Program Files\Microsoft Office Servers\14.0\Data\Office Server\Applications\<GUID>-query-<数字(1)>

今回はシリーズ 2 回にわたって SharePoint 2010 における検索サーバーの冗長構成についてお話してきましたが、検索コンポーネントの冗長構成については、SharePoint 2010 で大幅に改善された仕組みであり、うまく活用することでシステムの可用性が大幅に改善するものです。この記事を参考に、是非上手に活用していただければ幸いです。

皆さんこんにちは。

SharePoint サポートチームの荒川です。

今回は SharePoint 2010 における検索サーバーの冗長構成について、前半と後半の 2 回に分けてお話ししたいと思います。

SharePoint 2010 では従来のバージョンと比較して、より柔軟性に富んだ検索トポロジを設計できるようになりました。

従来のようなインデックスサーバー、クエリ サーバーという概念は無くなり、各役割はコンポーネント化され、検索サーバー上で柔軟なトポロジ構成を取れるようになりました。

クロール コンポーネントが実行される検索サーバー (従来でいうところのインデックスサーバー) で作成された一時検索インデックス ファイルは、クエリ コンポーネントが実行される検索サーバー (従来でいうところのクエリ サーバー) にコピーされた後に適宜削除され、クロール コンポーネント上には検索インデックスを蓄積しません。このため、クロールコンポーネントは純粋にコンテンツをクロールする目的にのみ利用されるようになり、従来のようにインデックス サーバーが単一の障害ポイントになることは無くなりました。

この変更により、検索インデックスファイルは、クエリ コンポーネント側で保持されることになります。もちろん、クエリ コンポーネントの検索インデックスの完全なコピーを複数のクエリ コンポーネントで保持することができ (ミラー化) いずれか 1 台のクエリ コンポーネントがダウンした場合であっても、既存の検索インデックスが完全に失われることを防止できます。さらに、検索インデックスの持ち方についても柔軟性に富んだ構成をとることが可能で、例えばクエリコンポーネントに格納される検索インデックスを複数のパーティションに分割し、1台のクエリ サーバーにすべてのインデックスを保持するのではなく、複数のクエリサーバーに分散して保持させることも可能です。(この辺りはまた別の機会に詳しく解説したいと思います。)

このようなトポロジモデルの変更により、複数のインデックス サーバーを用いてクロールを実行するなど、従来は行えなかった柔軟な運用管理が行えるようになりました。このあたりの詳しい解説は、以下の検索アーキテクチャモデルに関する資料に記載がありますので、ご参考いただけると幸いです。

さて、トポロジの設計および設定自体は管理 UI から比較的簡単に行えますが、実際に障害が発生した際には管理者側で行わなければならないいくつかのタスクがあります。このあたりは、まだ詳しく書かれた資料が少ないように思いますので、今回はこの部分にフォーカスした話を展開していきたいと思います。

■運用中にクエリコンポーネントで障害が発生したシナリオを考える

実際に運用中にクエリコンポーネントで障害��発生した場合どのような動作が生じるのでしょうか。

ユーザーの検索クエリへの影響

ファームに複数台存在するクエリコンポーネントのいずれか 1 台がダウンした場合、ユーザーが検索を実行するタイミングによって、検索クエリ要求がダウンしたクエリ コンポーネントに送信される可能性があります。この場合、ユーザーには「内部サーバーエラー」が返され検索に失敗します。

検索に一度失敗すると、失敗したクエリコンポーネントはバッド リスト (Load Balancer サービスのキャッシュ) に登録され、以後のクエリには使用されなくなります。このため、エラーが恒久的に続くことはありませんが、バッドリスト キャッシュの有効期限は既定で 10 分なので、10 分経過後には再び検索クエリ要求がダウンしたクエリコンポーネントに送信される可能性があります。再び検索に失敗すると、再度バッド リストに 10 分間エントリが登録される仕組みです。

この動作はダウンしたクエリコンポーネントが復旧されるか、検索トポロジからクエリ コンポーネントが削除されるまで続きます。

したがって、ユーザー側には、概ね検索は成功するが、ごく稀に検索時に「内部サーバーエラー」が返される状況が、クエリサーバーが復旧されるまで続くことになります。

失敗したクエリサーバーはバッド リストに保持される期間は、BadListPeriod パラメータにより変更できます。

クロールへの影響

クエリ コンポーネントの障害は、検索クエリだけでなく、クロール動作にも影響を及ぼします。

SharePoint 製品とテクノロジの以前のバージョンである MOSS 2007 では、ファームのいずれか 1 台のクエリ サーバーがダウンすると、進行中のクロールは中断され、管理者により明示的にクエリ サーバーが復旧されるまで、クロールが進行しませんでした。これは、インデックスサーバーで作成されたインデックスがファームのすべてのクエリ サーバーに等しく伝達 (プロパゲート) され、整合性を保持して管理される必要があったためです。このため、通常はダウンしたクエリ サーバーをファームから取り除くか、再構成して再度利用できるようにするまで、クロールを再開することができませんでした。

これに比べて SharePoint 2010 では、事前に管理者により、ファームで最低限稼働する必要があるクエリコンポーネントの数を指定できるようになりました。最低限の数が満たされている限り、クエリ サーバーがダウンした場合でも残りのクエリ サーバーに対してインデックスを伝達できるため、クロール処理そのものが停止することはありません。

具体的には、TimeBeforeAbandoningQueryComponent と MinimumReadyQueryComponentsPerPartition の設定値が、この動作に影響します。

SharePoint Server 2010 のクロール処理ではクロール コンポーネントにより作成された検索インデックスが、クロール中に継続的にクエリ サーバーに伝達されます。クロール処理が実行されている際にクエリサーバーがダウンしていた場合、伝達処理が失敗し、5 分おきに再試行されます。伝達処理が再試行されている間は、クロール処理が中断されます。伝達処理の再試行は、伝達処理が正常に完了するか、TimeBeforeAbandoningQueryComponent で指定された時間 (既定値は 60 分) が経過して対象のクエリ サーバーが使用不可としてマークされるまで続きます。

クエリ サーバーが使用不可としてマークされた後、クロールが再開されるかどうかは、MinimumReadyQueryComponentsPerPartition の設定値により変わります。MinimumReadyQueryComponentsPerPartition は、インデックス パーティションごとに最低限稼働していなければならないクエリ コンポーネントの数が指定されており、使用可能なクエリ サーバーの台数が MinimumReadyQueryComponentsPerPartition で指定された数 (既定値は 2) を満たす場合には使用不可としてマークされたクエリ サーバーは無視してクロールが再開され、使用可能なクエリサーバーの台数が MinimumReadyQueryComponentsPerPartition で指定された数に満たない場合には、管理者によりクエリコンポーネントが復旧されるまでクロールが中断したままとなります。

例えば、クエリサーバー 2 台構成の環境においていずれか 1 台のクエリ サーバーがダウンした場合にクロール処理を継続するためには、MinimumReadyQueryComponentsPerPartition の値を 1 に変更する必要があります。TimeBeforeAbandoningQueryComponent の値の変更は必須ではありませんが、クロールの中断時間を短くしたい場合には、15 分程度に設定しても問題ありません。あまりに短い時間を設定するとパフォーマンスに影響する可能性があるので注意が必要です。

■運用中にクロールコンポーネントで障害が発生したシナリオを考える

クロール コンポーネントについてはクエリコンポーネントよりも単純です。

クロール コンポーネントが複数のサーバーに割り当てられている場合、サービスアプリケーション内で個々のクロール コンポーネントのステータスが定期的に確認され、"オンライン" の状態のクロールコンポーネントが使用されてクロールが行われます。ファームに複数台存在するクエリ サーバーのいずれか 1 台がダウンした場合、クロールコンポーネントと通信できない状況が一定時間継続すると、使用できないクロール コンポーネントを使用不可とマークし、"応答なし" と設定します。その後、"応答なし" 以外のクロール コンポーネントでクロールが継続されるようになります。

なお、障害が発生したクロールコンポーネントが復旧して通信できるようになった際には、通常は 1、2 分で程度で "オンライン" に変更されます。

クロール コンポーネントが使用不可としてマークされるまでの時間は、クロールコンポーネントが動作する各サーバー上のレジストリにて変更できます。ただし、あまりに短い時間を設定するとパフォーマンスに影響する可能性があるので注意が必要です。

(後編に続く)

皆さんこんにちは

SharePoint サポートチームの荒川です。

前回、前々回に引き続き、SharePoint と SQL ブロッキングの話をします。これで一応最後です。

■イベントログから発生の有無を診断できるのか

前回説明したとおり、実際にブロッキングが起きたかどうかを後から正確に判断する術はありません。しかし、私は多くの経験のなかから、ブロッキング問題が発生した際によく見かける特徴的なイベントを見つけていますので、これがヒントになるかもしれません。

ブロッキング問題が起きた際には、多くの場合 Web サーバーのイベント ログに以下のイベント ID 2262 が記録されます。

注意したいのは、このイベントが記録されたからと言って、必ずしもブロッキング問題が発生していることを示すものでは無いということです。また、逆に、このイベントが出ていないからブロッキングが起きていないと判断することも適切ではありません。

上記イベントログは、ASP.NET のデッドロック検知機能が動作した事を示します。このイベント ログが記録された後、該当の w3wp.exe は IIS によって自動的に再起動されます。このイベントログは、後述の条件を満たした事によって ASP.NET がデッドロックが発生している疑いを検知した事を示し、実際に何らかのデータや内部変数等がデッドロックしている事を ASP.NET が認識した事を示すものではありません。

ASP.NET が自身の状態をデッドロックではないかと検知する条件は以下の二つです。

・リクエストの処理 (ユーザーコード) に responseDeadlockInterval (既定値 3 分) 以上、かかっているリクエストが存在する

・同時実行処理数が上限 (既定値 12 x CPU 数) に達している

以上の条件が双方とも満たされると、ASP.NET はデッドロックが発生していると判断します。発生シナリオの一例として以下が考えられます。

1) アプリケーションのリクエスト処理が何らかの要因によってハングする。

2) 後続のリクエスト処理が 1) に依存 (処理終了待ちなど) していて、それらもハングする。

3) 3 分が経過、かつ、後続のハングしたリクエスト数が 12 x CPU 数 を超えた時点で ASP.NET はデッドロックを検知した旨イベントログに発報してプロセスを不健全とマークする。

4) W3SVC は ある w3wp.exe が不健全とマークされた事を確認してプロセスに対して終了依頼する。

5) 終了依頼 (ExitProcess) に応じない場合、[ワーカープロセスをシャットダウンする時間] の設定値だけ待機した後、TerminateProcess を発行して強制終了する。その際、TerminateProcess した事をイベントログに発報する。

つまり、バックエンド SQL Server でブロッキングが発生し、さらに多数のユーザーがリクエストを試みている状況においては、上記イベントに遭遇する確率が高くなるわけです。

何度も言いますが、上記イベントはあくまで指標であって、実際にこのイベントとブロッキング問題を直結することは適切ではありません。しかし、過去事例の実績ベースでみると、多くの場合 SQL ブロッキングの結果として上記イベントが記録されるパターンが多いことも事実です。

■ロックエスカレーションの有無を確認する方法

ブロッキングと同様に、ロックエスカレーションが実際に発生したかどうかを後から確認する方法はありません。ただし、事前に SQL プロファイラ―を仕掛けておくことで、ロックエスカレーションの発生の瞬間をとらえることは可能です。

大抵の場合、一度ブロッキングが発生した環境は、以降も引き続き発生する可能性が高いと言えます。原因を特定せず、いきなりトレースフラグの設定を行うことが好ましくない状況では、先述のブロッキングの確認方法と併せて以下の方法でロックエスカレーションが発生したことを裏付けてから対応を検討するとよいでしょう。

SQL プロファイラーの詳細な解説についてはここでは触れませんが、簡単な確認方法を参考まで、紹介しておきます。(SQL プロファイラーの詳細について知りたい方は SQL Server の Books オンラインやヘルプ ドキュメントをご参照ください。)

ロックエスカレーションのイベントを記録するには、「Locks - Lock:Escaration」イベントを記録するようにトレースを設定します。

※他のイベントも併せて記録しても構いませんが、SQL プロファイラーによるトレースログの採取は SQL Server に大きな負担をかけますので、運用環境下での実施は避けたほうが良いでしょう。「Locks - Lock:Escaration」イベント程度であれば、それほど大量にログが出力されることは無いでしょうから、パフォーマンスへの極端な影響は無いものと思われます。

これで実際にロックエスカレーションが発生した際には、以下のようにロック エスカレーション イベントが記録されます。

上記で確認したデータベース名と、オブジェクト ID から以下のようにエスカレーションが発生したテーブルを特定することができます。

SELECT object_name(53575229)

サーバートレースを長期間仕掛けておく場合には、以下の手順を実行します。これによりファイルにログを出力することができます。

-----------------------------

サーバ トレース採取手順概要：

サーバー トレースの使用は、大きく分けて以下の 3 つの作業に分けられます。

i) スクリプト生成

ii) トレース実行

iii) トレース停止

それぞれの作業について説明いたします。

i) スクリプト生成

~~~~~~~~~~~~

以下の手順で、スクリプトを生成します。

1) スタート メニューから [Microsoft SQL Server 2005] - [パフォーマンスツール] - [SQL Server Profiler] を起動し、[ファイル] - [新しいトレース] を選択します。

2) 対象のデータベース インスタンスに接続します。

3) 「トレースのプロパティ」 画面の [全般] タブにおいて、[ファイルに保存する] をチェックし、保存するトレースファイルを UNC パスで指定します。(*1)

4) [最大ファイル サイズを設定 (MB) ] を、100 MB に変更します。 (*2)

5) [ファイルロールオーバーを有効にする] をチェックします。

6) [サーバが SQL Server トレースデータを処理する] をチェックします。

7) [イベントの選択] タブで、[すべてのイベントを表示する] オプションと[すべての列を表示する] オプションをチェックします。

8) 以下のイベントのすべての列を追加します。また、それ以外の既定のチェックを外します。

   Locks - Lock:Escaration

9) 一旦プロファイラを実行し、すぐに停止します。(停止 (四角) ボタンをクリックします。)

10) [ファイル] - [エクスポート] - [トレース定義のスクリプト] - [SQL Server 2005] で、任意のファイル名でトレース スクリプトを保存します。

*1) 指定するイベントとサーバで実行される処理量、監視期間によって大量のデータがファイルに出力される可能性があるため、十分余裕のあるディスクに対して保存を行うようにします。また、SQL プロファイラのトレースを出力するファイルは、可能であれば、SQL Server のデータベースが配置されているディスクとは別の物理ディスク (別の物理ディスクがない場合には別の論理ドライブ) への配置を検討してください。

*2) ファイルサイズについては、任意のサイズを指定します。サイズが小さすぎるとファイル数が増え、トレース追跡が困難になる場合があります。また、サイズが大きすぎると、ファイルを開くことが困難になる場合があります。

ii) トレース実行

~~~~~~~~~~~~

［スクリプト生成］で作成したスクリプトを、Management Studio で開きます。

スクリプトの先頭には下記のような記述があります。

例)

**********<抜粋 ここから>**********

-- Create a Queue

declare @rc int

declare @TraceID int

declare @maxfilesize bigint

set @maxfilesize = 100

exec @rc = sp_trace_create @TraceID output, 0, N'<InsertFileNameHere>', @maxfilesize, NULL if (@rc != 0) goto error

**********<抜粋 ここまで>**********

@maxfilesize にファイルサイズを指定します。上記の例では 100 MB に指定しております。

上記 '<InsertFileNameHere>' の箇所に、トレース結果を保存する任意のファイル パスを指定します。この際、既存のトレースファイル名を指定するとエラーになるので、別の任意の名前を指定してください。

また、下記 sp_trace_create の第二引数が 2 になっていることを確認し、2 になっていない場合には 2 に変更します。

例) 保存先を c:\\testtrace にする場合

exec @rc = sp_trace_create @TraceID output, 2, N'c:\\testtrace', @maxfilesize, NULL if (@rc != 0) goto error

変更後、書き換えたスクリプトを実行します。

このスクリプトを実行した時点からトレースが実行され、指定したイベントがキャプチャされます。

なお、実行の際に TraceID が返されるので記録します。スクリプトの停止を行う際に必要となります。

iii) トレース停止

~~~~~~~~~~~~

必要な情報を採取し終わった後、以下のクエリを実行して、トレースを停止、サーバーから削除します。

なお、下記のコマンド内の {TraceID} はスクリプトの実行時に返される値です。c で記録した値を、{TraceID}{TraceID}と置き換えてください。

EXEC sp_trace_setstatus {TraceID},0

go

EXEC sp_trace_setstatus {TraceID},2

go

トレースを停止し、サーバーから削除することで、まだファイルに書き込まれていないすべてのイベントが、最新のトレースファイルに書き込まれます。

TraceID が不明な場合、次のコマンドで実行中のトレースの一覧を出力させることができます。

SELECT * FROM ::fn_trace_getinfo(default)

表示されたトレース情報のファイル名等から、目的のTraceIDを特定します。

※1 サーバー トレースは結果を直接ファイルに書き出しますが、ファイルバッファを持っているため書き込みデータが一定のサイズになるまでトレースファイルに書き出しが行われません。

※2 サーバー トレースのスクリプトを介した際に Error 12 を受け取った場合は、出力先のトレース ファイルが既に存在している可能性があります。

-----------------------------

全3回のシリーズでSharePoint と SQL ブロッキングの話についてお届けしてまいりましたが、先に述べたとおり、最近になってこの現象に関するサポートへのお問い合わせが増えてきているように感じます。恐らく SharePoint を長期運用されているユーザーが増えてきたことで、システムに格納されるデータ量が増えてきたことが一つの要因ではないかと思います。SharePoint では、キャパシティプランニングやパフォーマンス検証の資料において、リストに大量のアイテムを格納しないといったガイドラインがありますが、これらのガイドを守らなくとも、通常の動作には支障が無いケースもあります。ただし、一度に大量のデータを削除したり、更新したるするようなオペレーションが合わさることで突発的に問題が発生するケースもありますので、この記事の例のように、状況に応じた対策を行う必要が生じることもあるでしょう。運用において、最近データ量が増えてきたな、と感じられることがあれば、問題を未然に防止するための予防措置として、トレースフラグ 1224 の設定を検討してみてはいかがでしょうか。

皆さんこんにちは

SharePoint サポートチームの荒川です。

前回に引き続き、SharePoint と SQL ブロッキングの話をします。

ここから先はさらに詳しい解説となります。Community Open Day の限られた時間内に収められなかった部分でもありますので、技術的により深い内容を得たい方はご参考いただければ幸いです。

■どのようなシナリオでブロッキングが発生し得るのか

私が手元で再現して実際に動作を確認しのは、以下のパターンです。先述の Community Open Day セッションのデモでもこちらの例を使用しています。

・大量のアイテムが格納されているライブラリの親フォルダ名の変更

・大量のアイテムを含むサイトデータのごみ箱からの削除

上記以外に、過去のユーザー事例から、以下のような状況でもブロッキングが発生する可能性があることを確認しています。詳細な条件等は残念ながら確認できておらず、点在する情報からの判断となります。

・ワークフローによる大量のアイテム更新

・大量のコンテンツに複雑な権限を付与した環境での権限の継承、切断

■ブロッキングの有無を確認する方法

実際に問題が起きた後で、ブロッキングの有無を確認する方法はあるのでしょうか？

答えとしては、ありません。残念ながら既に問題が起きた後、ブロッキングが原因でサイトの応答が停止していたことを断定する手段は無いのです。

したがって、問題を特定するには、サイトの応答が停止している時、つまり SQL Server でブロッキングが起きている最中に、SQL Server 側で利用状況モニターを確認する必要があります。

利用状況モニターの詳細な解説についてはここでは触れませんが、簡単な確認方法を参考まで、紹介しておきます。(利用状況モニターの詳細について知りたい方は SQL Server の Books オンラインやヘルプ ドキュメントをご参照ください。)

今回は SQL Server 2005 の例で説明しますが SQL Server 2008 でも同様の方法で確認できます。

まず、ブロッキングが発生している際に利用状況モニターを起動して、ブロッキングカラムでソートすると、以下のような情報が参照できます。

上記の例では、ブロックチェーンの先頭ブロックが SPID 58 の処理であることがわかります。この処理の内容を見てみましょう。

Management Studio で以下のクエリを実行します。

DBCC INPUTBUFFER(58)

EventInfo の内容を確認すると、以下のような情報が得られました。

詳細なことは直ぐにはわかりませんが、内容からヒントになる情報が得られることもあります。実は、今回は大量のコンテンツが存在するライブラリのフォルダをリネームするというオペレーションを実施して、意図的にブロッキングを発生させました。フォルダ名が変わると、AllDocs というユーザーデータ テーブルのエントリが持つ URL カラムの内容を書き換える必要が生じるため、レコード数が多いとロックエスカレーションが発生します。

次に、同様にブロッキングの影響を受けている SPID 91 の処理の内容を見てみましょう。

皆さんには馴染みが薄いと思いますが、我々 SharePoint のサポートエンジニアにとって、このストアドプロシージャ proc_FetchDocForHttpGet は頻繁に目にするものです。

このストアドプロシージャは、主に AllDocs テーブルから SharePoint コンテンツの情報を取得するために使用されます。

これらの結果より、AllDocs テーブルのレコードに対する INSERT コマンドがブロッキングを引き起こし、恐らく後続の処理であるサイトの閲覧を阻害しているであろうことが推測できます。

それでは、さらに高度な分析をしてみましょう。例えば、Web サーバーが複数存在する環境において、また、Web アプリケーションが複数存在する環境において、いったいどの Web サーバーのどのサイトからの通信がブロッキングを引き起こしているのでしょうか。

Management Studio で master データベースに対して以下のクエリを実行してみましょう。

SELECT hostname,program_name,hostprocess FROM sysprocesses WHERE spid = 58

上記のクエリ結果から、ホスト名が MOSS、プロセス ID 552 のプロセスからの通信であることが特定できます。

では、サーバー MOSS でプロセス ID 552 のプロセスを見てみましょう。

PID 552 は、IIS のワーカープロセス (w3wp.exe) であることが特定できました。

さらに追跡します。

Windows 2003 の場合、%SystemRoot%\system32 ディレクトリに移動し、以下のコマンドを実行します。

>cscript iisapp.vbs

※Windows 2008 以降では、%SystemRoot%\system32\inetsrv ディレクトリに移動し、以下のコマンドを実行します

>appcmd list wp

コマンドが成功すると以下のようにアプリケーションプールに紐づけられたプロセス ID の結果が出力されます。

この結��から、アプリケーションプール「SharePoint - 80」で実行されている Web アプリケーションからの処理が原因となっていることが特定できました。

上記の例において何よりも問題の解決を優先される場合には、Web フロントエンドサーバー MOSS のアプリケーション プール「SharePoint - 80」を強制的にリサイクルするか、IIS リセットすることで処理を中断し、SQL Server 側で実行中の処理をロールバックすることができます。この場合、当然アプリケーション側の処理であるフォルダのリネーム処理は失敗することになります。

(Part 3 に続く)

皆さんこんにちは

SharePoint サポートチームの荒川です。

先日 Community Open Day というコミュニティ主催のイベントで登壇させていたき、SharePoit のパフォーマンス問題についてお話しさせていただきました。

内容は、以前にこちらのブログで公開したセキュリティクロールのお話と、最近になってサポートへのお問い合わせが増えてきた SQL ブロッキングのお話しだったのですが、SQL ブロッキングについては、最近、この問題に関連するサポートへのお問い合わせが増えてきましたので、こちらのブログでも内容をまとめておきたいと思います。

このブログの内容を簡単に確認されたい方は、Community Open Day で登壇した際の私のセッション動画 (USTREAM) をご参照ください。セッションでは概要部分を図解とデモを交えてお話ししていますので視覚的にもよりわかりやすいと思います。

■現象

突然サイトにアクセスしても応答が返されず、砂時計表示のままページが閲覧できません。

複数のユーザーで同じ現象が発生している状況です。

■特徴

現象発生中に Web サーバーで IIS リセットをすると回避します。

また、数分から数十分程度で自然復旧することもあります。

■原因

一度に大量のレコードが更新された際に SQL Server のロックエスカレーションが発生し、コンテンツデータベース内のユーザーデータテーブルが長時間ロックされ、その間の後続の処理がブロックされることによりこの問題が発生します。

■解説

SQL Server にはメモリを節約するための機能としてロック エスカレーションという機能があります。 SQL Server の既定の設定では、1 つの Transact-SQL ステートメントで 5000 個以上のロックを取得した場合、メモリを節約するために、ロックをより粒度が大きい少数のロックにエスカレーションします。例えば、一度に数万件のレコードを更新するような処理をした際に、行ロックがテーブルロックにエスカレーションされることがあります。

SharePoint ではユーザーデータをコンテンツ データベースの 1 つのテーブルで一元管理していますので、データ量が多い時に、大量のレコードの更新を発生させるような処理を行うと、SQL Server の仕組みとしてロックエスカレーションが発生することがあります。これが発生すると、ユーザーデータが格納されたテーブルがロックされてしまいますので、同じテーブルを参照する後続の処理がロックの解放まで待たされる状況 (ブロッキング) が発生します。当然、ユーザーデータを参照するサイトの閲覧処理もこの影響を受けますので、結果としてサイトの閲覧ができなくなる (砂時計で待たされる) という状況が発生します。

この問題は必ず発生するものではありませんが、データ量が多い環境では比較的発生しやすいようです。ユーザーが長時間サイトを閲覧できなくなることから、かなりインパクトの大きな問題と言えるでしょう。

■対処方法

ブロッキングがロックエスカレーションによって発生しているのであれば、ロック エスカレーションの発生条件を緩和するための SQL Server チューニングが有効です。これにはトレース フラグ 1224 を使用します。SQL Server でロックエスカレーションが発生する条件は、ロックの数と、ロックに伴うメモリの使用量です。トレースフラグ 1224 を設定することで、このうちの「数」に関する条件を取り払うことができます。従って、大量の行ロックが発生した場合でもロックエスカレーションされなくなりますので、使用メモリは増加するものの、ブロッキングによりサイトの閲覧ができなくなるといった致命的な問題は回避することができます。

注意(2012/12/18 更新)：トレースフラグ T1224 の設定は SQL Server のインスタンス全体で有効になることに注意する必要があります。たとえば、検索データベースとコンテンツ データベースが同一インスタンスで構成されている場合、本設定の影響により、クロールに伴う検索データベースの大量の更新がロック エスカレーションされず、結果として SQL Server のメモリを大量に消費してしまう可能性があります。そうなると、メモリ負荷により SQL Server でキャッシュ済みのクエリプランがメモリ上から削除され、結果的にクエリのコンパイル待ちによるブロッキングやパフォーマンス劣化が発生する可能性があります。たとえば、T1224 の設定により一時的に問題が解消されるものの、クロールのタイミングで今度はシステム全体のパフォーマンス劣化が生じるといった別の問題が起きるといったケースが想定されます。

トレースフラグ T1224 の設定を行う場合、事前に十分な検証を行っていっただき、可能であれば別途専用の SQL Server インスタンスを用意して、そこに問題のコンテンツデータベースのみを移してから実装していただくことをお勧めします。

実は、最近になってこの現象に関するサポートへのお問い合わせが増えてきているように感じます。恐らく SharePoint を長期運用されているユーザーが増えてきたことで、システムに格納されるデータ量が増えてきたことがその原因ではないかと考察しています。

SharePoint では、キャパシティプランニングやパフォーマンス検証の資料において、リストに大量のアイテムを格納しないといったガイドラインがありますが、これらのガイドを守らなくとも、通常の動作には支障が無いケースもあります。ただし、一度に大量のデータを削除したり、更新したるするようなオペレーションが合わさることで突発的に問題が発生するケースもありますので、この記事の例のように、状況に応じた対策を行う必要が出てくることもあるでしょう。

勿論、事前の検証は必要ですが、サイトが閲覧できなくなるという、最悪の事態を防ぐために、データ量の増加が見込まれる環境においては予めトレースフラグ 1224 の設定を検討することをお勧めします。

次回は、Community Open Day の限られた時間内に収められなかった、技術的により深い内容について掘り下げてお話ししたいと思います。

(Part 2 に続く)