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

  • [アーティクル]

レポート可能なフィールドの属性セットがチーム プロジェクト コレクション間で異なる場合に、スキーマの競合が発生します。 スキーマ競合が発生すると、競合していないフィールドは通常どおりに処理されますが、競合しているフィールドは、競合を解決し、通常どおりに処理するまで、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 つの配置内の複数のプロジェクト コレクションで定義されているフィールドの属性値を確認するしかありません。

複数のプロジェクト コレクションにおいて、あるフィールドの参照名またはレポート内参照名のいずれかが同じであり、かつ、そのフィールドに対する次の属性の 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

スキーマ競合

型

文字列

Integer

データ型が一致しません。

ReportingName

アクティビティ

Common Activity

レポート名が一致しません。

レポート可能

詳細

ディメンション

レポートの種類が一致しません。

スキーマ競合の解決

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

  1. すべてのプロジェクト コレクション内で、そのフィールドに割り当てられている属性値を調べます。 witadmin listfields コマンドを使用できます。構文は次のとおりです。

    witadmin listfields /collection:CollectionURL /n:RefName [/unused]

    詳細については、「作業項目フィールドの管理 [witadmin]」を参照してください。

  2. 次のどの方法でスキーマ競合を解決するかを決めます。

    • あるプロジェクト コレクション内のそのフィールドの属性値を、他のプロジェクト コレクション内で割り当てられている属性値に合わせて修正する。 この操作が推奨されるのは、そのフィールドが類似レポート内で同じ使われ方をしている場合、または、そのフィールドがプロジェクト間レポートで使用されている場合です。

    • 競合するフィールドのレポート参照名を修正する。 この操作が推奨されるのは、そのフィールドが異なる使われ方をしている場合、または、別のフィールドを維持する必要がある場合です。 この場合、プロジェクト間レポートの異なるプロジェクト コレクションで作業するチームには、このフィールドは使用されません。

      詳細については、「レポート作成をサポートするための作業項目フィールドの追加および変更」を参照してください。

    • そのフィールドを 1 つ以上のコレクションに対して、レポート不能として設定する。 この操作が推奨されるのは、そのフィールドがそれらのプロジェクト コレクションのレポートで使用されていない場合です。

    • そのフィールドをチーム プロジェクト コレクションから削除する。 この方法が推奨されるのは、そのフィールドがどのチーム プロジェクトでも、また、どのレポートでも使用されていない場合です。

      注意

      レポートで使用されているフィールドを削除した場合、そのレポートは正しく表示されなくなります。

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

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

  4. プロジェクト コレクションからフィールドを削除するには、witadmin deletefield コマンドを使用できます。構文は次のとおりです。

    witadmin deletefield /collection:CollectionURL /n:RefName

    重要

    フィールドを完全に削除するには、そのフィールドとそのフィールドに格納されているすべてのデータをデータ ストレージから削除します。

スキーマ競合の解決の確認

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

注意

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

  1. WarehouseControlService の ProcessWarehouse 操作を使用して、リレーショナル データ ウェアハウスをオンデマンドで処理します。

  2. WarehouseControlService の ProcessAnalysisDatabase 操作を使用して、キューブをオンデマンドで処理します。

  3. ダッシュボードまたはレポート マネージャーを開き、レポートが更新されているかどうかを確認します。 詳細については、「プロジェクト ポータル ダッシュボード」または「レポート (SQL Server Reporting Services)」を参照してください。

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

参照

関連項目

作業項目フィールドの管理 [witadmin]

概念

レポート作成をサポートするための作業項目フィールドの追加および変更

Visual Studio ALM のグラフ、ダッシュボード、およびレポート

その他の技術情報

Team Foundation Server で使用するデータ ウェアハウスおよび Analysis Services キューブの手動処理