データウェアハウスで発生しているスキーマ競合の解消

[アーティクル]
08/09/2011

レポート可能フィールドの属性値がチームプロジェクトコレクション間で一致していないと、スキーマ競合が発生します。スキーマ競合が発生すると、そのスキーマに関連付けられているデータをデータウェアハウスおよび SQL Server Analysis Services データキューブに移動できなくなります。関連データをデータウェアハウスに移動して、関連レポートに最新データを表示できるようにするには、スキーマ競合をすべて解消する必要があります。

重要

Visual Studio Team Foundation Server 2010 の Service Pack 1 (SP1) をインストールしてスキーマ競合が発生したときは、データウェアハウスのブロックを解除できます。 SP1 がインストールされていると、競合していないフィールドは通常どおりに処理されます。競合を解決してから通常どおりに処理するまでは、競合しているフィールドに null 値が割り当てられます。

また、システムによって検出される競合ごとに通知イベントが生成されます。イベントをサブスクライブすると、コレクションに定義されたチームプロジェクトにスキーマ競合が発生したときに、警告を受信できます。

Visual Studio Team Foundation Server の 1 つの配置内の各プロジェクトコレクションで定義されている全チームプロジェクトのレポート可能データは、すべて 1 つのリレーショナルデータウェアハウスに書き込まれます。次に、このデータウェアハウスのデータは、処理されてキューブに書き込まれます。このようにデータを 1 つのデータウェアハウスに集めることで、複数のチームプロジェクトコレクション間にまたがるレポートを作成できます。ただし、フィールドはプロジェクトコレクションごとに別々に管理されるので、同じレポート内参照名を割り当てられているフィールドの属性値がプロジェクトコレクション間で異なる場合、スキーマ競合が発生する可能性があります。

このトピックの内容

スキーマの競合を警告するエラーメッセージ
スキーマ競合の原因
スキーマ競合の解決
スキーマ競合の解決の確認

スキーマの競合を警告するエラーメッセージ

スキーマ競合が発生している場合、次の場所にエラーメッセージが表示されます。

アプリケーション層サーバーのイベントログ。

注意

データ競合が解決されるまで、Team Foundation Server によって 1 日に 1 回エラーメッセージがイベントログに記録されます。
MSF プロセステンプレートで定義され、レポートマネージャーに表示されるレポート。
MSF プロセステンプレートで定義され、プロジェクトポータルに表示されるダッシュボード。

注意

レポートまたはダッシュボードの右下隅に表示されている [最終更新日] のタイムスタンプを見れば、そのレポートまたはダッシュボードの最終更新日がわかります。このタイムスタンプは、各プロジェクトコレクションに対してスケジューリングされた各ウェアハウスアダプタージョブが前回完了した日を表しています。タイムスタンプの計算時、カスタムアダプタージョブは対象となりますが、ウェアハウスコントロール Web サービスの実行をブロックされているアダプタージョブは無視されます。

スキーマの競合が原因で、レポート作成用のデータウェアハウスにデータを移動できない場合、そのレポートのタイムスタンプは更新されません。

ウェアハウスコントロール Web サービスの GetProcessingStatus 操作を使用すると、前述のメッセージに加え、さらに詳しい情報を取得できます。詳細については、「Team Foundation Server で使用するデータウェアハウスおよび Analysis Services キューブの手動処理」を参照してください。

スキーマ競合の原因

スキーマ競合が発生するのは、プロジェクト管理者が次のいずれかの作業を行った場合です。

あるプロジェクトコレクション内のある作業項目の種類にレポート可能フィールドを追加したが、そのフィールドに割り当てられた属性値が他のプロジェクトコレクション内のフィールドの属性値と一致しない場合。
複数のプロジェクトコレクション内で使用されている作業項目フィールドの属性値を変更したが、変更後の属性値が他のコレクション内で割り当てられている属性値と競合する場合。

注意

プロジェクト管理者がこれらのエラーを回避するには、1 つの配置内の複数のプロジェクトコレクションで定義されているフィールドの属性値を確認するしかありません。

複数のプロジェクトコレクションにおいて、あるフィールドの参照名またはレポート内参照名のいずれかが同じであり、かつ、そのフィールドに対する次の属性の値のいずれかが 2 つ以上のプロジェクトコレクション間で一致していない場合、エラーが発生します。

name: フィールドの表示名。この属性は、作業項目クエリ作成時にオプションとして表示されます。
reportingname: レポートに表示される名前。値を指定しなかった場合は、name 属性に割り当てられた値が使用されます。
reportable/reportingtype: フィールドのデータをレポートに含めることができるかどうか。また、含めることができる場合、レポート可能タイプ (例: None、Detail、Dimension、Measure)。

注意

FIELD 要素では reportable 属性が使用され、witadmin changefield コマンドでは reportingtype 属性が使用されます。この 2 つの属性は、同じ情報を定義しています。
type: フィールドに設定できるデータの種類 (例: Integer、HTML、String、Double、DateTime)。

次の表に、スキーマ競合が発生する属性値割り当ての例を示します。これらの例では、レポート参照名とレポート名は割り当てられていません。

属性	プロジェクトコレクション 1	プロジェクトコレクション 2	スキーマ競合
Type	String	Integer	データ型が一致しません。
ReportingName	Activity	Common Activity	レポート名が一致しません。
Reportable	Detail	Dimension	レポートの種類が一致しません。

スキーマ競合の解決

アプリケーション層サーバーのイベントログを調べることにより、スキーマ競合の原因となっているフィールドに関する詳細情報を取得できます。スキーマ競合の原因となっているフィールドを特定したら、次の手順を実行します。

すべてのプロジェクトコレクション内で、そのフィールドに割り当てられている属性値を調べます。 witadmin listfields コマンドを使用できます。構文は次のとおりです。
```
witadmin listfields /collection:CollectionURL /n:RefName [/unused]
```
詳細については、「作業項目フィールドの管理 [witadmin]」を参照してください。
次のどの方法でスキーマ競合を解決するかを決めます。
- あるプロジェクトコレクション内のそのフィールドの属性値を、他のプロジェクトコレクション内で割り当てられている属性値に合わせて修正する。この操作が推奨されるのは、そのフィールドが類似レポート内で同じ使われ方をしている場合、または、そのフィールドがプロジェクト間レポートで使用されている場合です。
- 競合するフィールドのレポート参照名を修正する。この操作が推奨されるのは、そのフィールドが異なる使われ方をしている場合、または、別のフィールドを維持する必要がある場合です。この場合、プロジェクト間レポートの異なるプロジェクトコレクションで作業するチームには、このフィールドは使用されません。
  
  詳細については、「作業項目フィールドの追加および修正とレポート作成」を参照してください。
- そのフィールドを 1 つ以上のコレクションに対して、レポート不能として設定する。この操作が推奨されるのは、そのフィールドがそれらのプロジェクトコレクションのレポートで使用されていない場合です。
- そのフィールドをチームプロジェクトコレクションから削除する。この方法が推奨されるのは、そのフィールドがどのチームプロジェクトでも、また、どのレポートでも使用されていない場合です。
  
  注意
  
  レポートで使用されているフィールドを削除した場合、そのレポートは正しく表示されなくなります。

前の手順で決めた方法に基づいて、フィールドに割り当てられた属性値を修正します。 witadmin changefield コマンドを使用できます。構文は次のとおりです。

witadmin changefield /collection:CollectionURL /n:RefName [/name:NewName] [/syncnamechanges:true | false] [/reportingname:ReportingName] [/reportingrefname:ReportingRefName] [/reportingtype:Type] [/reportingformula:Formula] [/noprompt]

プロジェクトコレクションからフィールドを削除するには、witadmin deletefield コマンドを使用できます。構文は次のとおりです。
```
witadmin deletefield /collection:CollectionURL /n:RefName
```
重要

フィールドを完全に削除するには、そのフィールド、および、そのフィールドのすべてのデータをデータストレージから削除します。

スキーマ競合が解決したかどうかを確認する

スキーマ競合が解決したかどうかを確認するには、データウェアハウスに対する処理をオンデマンドで行い、レポートを生成してデータウェアハウスが更新されているかどうかを調べます。既定のスケジュールに基づいてウェアハウスアダプタージョブが実行されるまで待ってもかまいません。既定では、リレーショナルデータベースに対する処理は数分ごとに実行されます。しかし、Analysis Services キューブに対する処理は、既定で 2 時間ごとに実行されます。

注意

ウェアハウスコントロール Web サービスの詳細については、「Team Foundation Server で使用するデータウェアハウスおよび Analysis Services キューブの手動処理」を参照してください。

WarehouseControlService の ProcessWarehouse 操作を使用して、リレーショナルデータウェアハウスをオンデマンドで処理します。
WarehouseControlService の ProcessAnalysisDatabase 操作を使用して、キューブをオンデマンドで処理します。
ダッシュボードまたはレポートマネージャーを開き、レポートのデータが更新されているかどうかを確認します。詳細については、「ダッシュボード (アジャイル)」または「レポート (アジャイル)」を参照してください。

エラーメッセージがまだ表示される場合は、WarehouseControlService の GetProcessingStatus 操作を実行することにより、データ競合およびブロックされているアダプターに関する詳細情報を取得できます。