データ ウェアハウスで発生しているスキーマ競合の解消
レポート可能なフィールドの属性セットがチーム プロジェクト コレクション間で異なる場合に、スキーマの競合が発生します。 スキーマ競合が発生すると、競合を解決し、通常どおりに処理するまでは競合通常どおりに処理されるわけではありませんが、フィールドは null 値が割り当てられる競合しているフィールド。 また、システムによって検出される競合ごとに通知イベントが生成されます。 イベントをサブスクライブすると、スキーマ競合がコレクションに対して定義されているチーム プロジェクトに対して発生時に通知を受け取ることができます。 関連データをデータ ウェアハウスの処理のブロックを解除し、関連付けられたレポートを最新のデータを表示できるように、すべてのスキーマの競合を解決する必要があります。
Visual Studio Team Foundation Server の 1 つの配置内の各プロジェクト コレクションで定義されている全チーム プロジェクトのレポート可能データは、すべて 1 つのリレーショナル データ ウェアハウスに書き込まれます。 データ ウェアハウスに書き込まれたデータは、処理されてキューブに書き込まれます。 このようにデータを 1 つのデータ ウェアハウスに集めることで、複数のチーム プロジェクト コレクション間にまたがるレポートを作成できます。 ただし、フィールドはプロジェクト コレクションごとに別々に管理されるので、同じレポート内参照名を割り当てられているフィールドの属性値がプロジェクト コレクション間で異なる場合、スキーマ競合が発生する可能性があります。
このトピックの内容
スキーマの競合を警告するエラー メッセージ
スキーマ競合の原因
スキーマ競合の解決
スキーマ競合の解決の確認
スキーマの競合を警告するエラー メッセージ
スキーマ競合が発生している場合、次の場所にエラー メッセージが表示されます。
アプリケーション層サーバーのイベント ログ。
注意
データ競合が解決されるまで、Team Foundation Server によって 1 日に 1 回エラー メッセージがイベント ログに記録されます。
MSF プロセス テンプレートで定義され、レポート マネージャーに表示されるレポート。
MSF プロセス テンプレートで定義され、プロジェクト ポータルに表示されるダッシュボード。
注意
レポートまたはダッシュボードの右下隅に表示されている [最終更新日] のタイム スタンプを見れば、そのレポートまたはダッシュボードの最終更新日がわかります。このタイム スタンプは、各プロジェクト コレクションに対してスケジューリングされた各ウェアハウス アダプター ジョブが前回完了した日を表しています。タイム スタンプの計算時、カスタム アダプター ジョブは対象となりますが、ウェアハウス コントロール Web サービスの実行をブロックされているアダプター ジョブは無視されます。
スキーマの競合が原因で、レポート作成用のデータ ウェアハウスにデータを移動できない場合、そのレポートのタイム スタンプは更新されません。
ウェアハウス コントロール Web サービスの GetProcessingStatus 操作を使用すると、前述のメッセージに加え、さらに詳しい情報を取得できます。 詳細については、参照します 手動で Team Foundation Server の Data Warehouse and Analysis Services Cube を処理します。。
スキーマ競合の原因
スキーマ競合が発生するのは、プロジェクト管理者が次のいずれかの作業を行った場合です。
あるプロジェクト コレクション内のある作業項目の種類にレポート可能フィールドを追加したが、そのフィールドに割り当てられた属性値が他のプロジェクト コレクション内のフィールドの属性値と一致しない場合。
複数のプロジェクト コレクション内で使用されている作業項目フィールドの属性値を変更したが、変更後の属性値が他のコレクション内で割り当てられている属性値と競合する場合。
注意
プロジェクト管理者がこれらのエラーを回避するには、1 つの配置内の複数のプロジェクト コレクションで定義されているフィールドの属性値を確認するしかありません。
複数のプロジェクト コレクションにおいて、あるフィールドの参照名またはレポート内参照名のいずれかが同じであり、かつ、そのフィールドに対する次の属性の値のいずれかが 2 つ以上のプロジェクト コレクション間で一致していない場合、エラーが発生します。
name: フィールドの表示名。この属性は、作業項目クエリ作成時にオプションとして表示されます。
reportingname: レポートに表示される名前。 値を指定しない場合は、name 属性に割り当てられた値が使用されます。
reportable/reportingtype: フィールドのデータをレポートに含めることができるかどうか。また、含めることができる場合、レポート可能タイプ (例: None、Detail、Dimension、Measure)。
注意
FIELD 要素では reportable 属性が使用され、witadmin changefield コマンドでは reportingtype 属性が使用されます。この 2 つの属性は、同じ情報を定義しています。
type: フィールドに設定できるデータの種類 (例: Integer、HTML、String、Double、DateTime)。
次の表に、スキーマ競合が発生する属性値割り当ての例を示します。 これらの例では、レポート参照名とレポート名は割り当てられていません。
Attribute |
プロジェクト コレクション 1 |
プロジェクト コレクション 2 |
スキーマ競合 |
|---|---|---|---|
型 |
String |
Integer |
データ型が一致しません。 |
ReportingName |
アクティビティ |
Common Activity |
レポート名が一致しません。 |
Reportable |
Detail |
ディメンション |
レポートの種類が一致しません。 |
スキーマ競合の解決
アプリケーション層サーバーのイベント ログを調べることにより、スキーマ競合の原因となっているフィールドに関する詳細情報を取得できます。 スキーマ競合の原因となっているフィールドを特定したら、次の手順を実行します。
すべてのプロジェクト コレクション内で、そのフィールドに割り当てられている属性値を調べます。 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 サービスの詳細については、「TFS データ ウェアハウスと Analysis Services キューブの手動処理」を参照してください。
WarehouseControlService の ProcessWarehouse 操作を使用して、リレーショナル データ ウェアハウスをオンデマンドで処理します。
WarehouseControlService の ProcessAnalysisDatabase 操作を使用して、キューブをオンデマンドで処理します。
ダッシュボードまたはレポート マネージャーを開き、レポートのデータが更新されているかどうかを確認します。 詳細については、「ダッシュボード」または「レポート (SQL Server Reporting Services)」を参照してください。
エラー メッセージがまだ表示される場合は、WarehouseControlService の GetProcessingStatus 操作を実行することにより、データ競合およびブロックされているアダプターに関する詳細情報を取得できます。
参照
関連項目
概念
レポート作成をサポートするための作業項目フィールドの追加および変更
Visual Studio ALM のレポートの作成、カスタマイズ、および管理