Поделиться через


Разрешение конфликтов схемы, возникающих в хранилище данных

Конфликты схем возникают, когда набор атрибутов включаемых в отчеты полей является различным в различных коллекциях командных проектов. При возникновении конфликта схемы данные, связанные с этой схемой, не могут быть перемещены в хранилище данных и в куб данных служб аналитики SQL Server. Чтобы разблокировать обработку связанных данных для хранилища и обеспечить возможность отображения текущих данных в отчетах, необходимо устранить все конфликты схемы.

Важно!

Если происходят конфликты схемы, можно разблокировать хранилище данных, установив пакет обновления 1 (SP1) для Visual Studio Team Foundation Server 2010.При установленном пакете обновления 1 (SP1) поля, которые не находятся в конфликте, обрабатываются обычным образом.Конфликтующим полям присваиваются значения Null до разрешения конфликтов, после чего поля обрабатываются обычным образом.

Кроме того, для каждого обнаруживаемого конфликта система создает событие уведомления.Подписавшись на такое событие, можно получать оповещения при возникновении конфликтов схемы для любого командного проекта, определенного для коллекции.

Все включаемые в отчеты данные из всех командных проектов, определенных во всех коллекциях проектов развертывания Visual Studio Team Foundation Server, записываются в одну реляционную базу данных. Данные из этого хранилища затем обрабатываются и записываются в куб. Сбор данных в едином хранилище позволяет создавать отчеты сразу по нескольким коллекциям командных проектов. Однако, поскольку работа с полями в каждой коллекции проектов происходит по-разному, при назначении разных определений одному или нескольким атрибутам поля, имеющего одно и то же отчетное ссылочное имя, могут возникать конфликты схемы.

Содержание раздела

  • Сообщения об ошибках, указывающие на конфликты схемы

  • Источники конфликтов схемы

  • Разрешение конфликтов схемы

  • Проверка разрешения конфликтов схемы

Сообщения об ошибках, указывающие на конфликты схемы

При возникновении конфликта схемы появляется сообщение об ошибке в следующих местах:

  • в журнале событий сервера уровня приложений;

    Примечание

    Team Foundation Server записывает сообщение об ошибке в журнале событий каждый день, пока конфликта данных не будут разрешен.

  • в отчете, входящем в состав шаблонов процессов MSF и просматриваемых через диспетчер отчетов;

  • на панели мониторинга, входящей в состав шаблонов процессов MSF и просматриваемых через портал проекта.

    Примечание

    Определить, когда шаблон или панель мониторинга обновлялись в последний раз, можно по метке времени Дата последнего обновления в нижнем правом углу каждого отчета и панели мониторинга.Метка времени указывает время последнего успешного завершения обработки каждого запланированного к выполнению задания адаптера хранилища для каждой коллекции проектов.При вычислении метки времени учитываются задания пользовательских адаптеров и игнорируются задания адаптеров, блокируемых от запуска веб-службы управления хранилищем.

    Если конфликт схемы блокирует попадание данных в хранилище данных для отчета, метка времени для отчета обновлена не будет.

Помимо вышеперечисленных сообщений, можно получить дополнительные сведения с помощью операции GetProcessingStatus веб-службы управления хранилищем. Дополнительные сведения см. в разделе Обработка хранилища данных и куба служб аналитики вручную для Team Foundation Server.

Источники конфликтов схемы

Конфликты схемы могут возникать, когда администратор проекта выполняет одно из следующих действий:

  • добавляет включаемое в отчеты поле в тип рабочего элемента в одной коллекции проектов, причем назначенные этому полю атрибуты не соответствуют его атрибутам в других коллекциях проектов;

  • изменяет назначенный полю рабочего элемента атрибут, который используется в нескольких коллекциях проекта, причем эти изменения конфликтуют с назначениями в других коллекциях.

    Примечание

    Избежать описанных выше ошибок администратор может только путем просмотра назначений атрибутов полям, определенным в различных коллекциях проектов в развертывании.

Ошибки проявляются, когда поле имеет либо одинаковое ссылочное имя, либо одинаковое отчетное ссылочное имя в нескольких коллекциях проектов, и один или несколько из следующих атрибутов для этого поля не совпадают в двух или более коллекциях:

  • name: понятное имя поля, отображаемое в качестве варианта при создании запроса рабочего элемента;

  • reportingname: имя, отображаемое в отчетах. Если значение не задано, используется значение, присвоенное атрибуту name;

  • reportable/reportingtype: указывает, доступны ли данные из поля для включения в отчеты и если да, указывает отчетный тип (например, None, Detail, Dimension или Measure);

    Примечание

    В элементе FIELD использовался атрибут reportable, а в команде witadmin changefield используется атрибут reportingtype.Эти атрибуты определяют одну и ту же информацию.

  • type: тип данных, принимаемый полем (например, Integer, HTML, String, Double или DateTime).

В следующей таблице приведены примеры назначений атрибутов, которые вызовут конфликты схемы. Отчетное ссылочное имя и отчетное имя в этих примерах не присвоены.

Атрибут

Коллекция проектов 1

Коллекция проектов 2

Конфликт схемы

Type

String

Integer

Типы данных не совпадают.

ReportingName

Действие

Типовое действие

Отчетные имена не совпадают.

Reportable

Detail

Dimension

Отчетные типы не совпадают.

Разрешение конфликтов схемы

Для получения дополнительных сведений о поле, вызывающем конфликт схемы, можно просмотреть журнал событий на сервере уровня приложений. Определив, какое поле или поля вызывают конфликт, необходимо выполнить следующие действия.

  1. Просмотрите атрибуты, назначенные полю, во всех коллекциях проектов. Можно использовать команду witadmin listfields, имеющую следующий синтаксис:

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

    Дополнительные сведения см. в разделе Управление полями рабочих элементов [witadmin].

  2. Выберите один из следующих способов разрешения конфликта.

    • Изменить атрибут для поля в одной коллекции проектов в соответствии с назначениями, сделанными в других коллекциях проектов. Пользоваться этим способом следует, когда команды используют поле аналогичным образом в аналогичных отчетах или для межпроектной отчетности.

    • Изменить отчетное ссылочное имя конфликтного поля. Пользоваться этим способом следует, когда поля используются по-разному или необходимо сохранить разные поля. В этом случае поле не используется командами, работающими в разных коллекциях проектов для межпроектной отчетности.

      Дополнительные сведения см. в разделе Добавление и изменение полей рабочих элементов для поддержки отчетов.

    • Пометить поле как не являющееся отчетным для одной или нескольких коллекций. Пользоваться этим способом следует, когда поле не используется для отчетов об этих коллекциях проектов.

    • Удалить поле из коллекции командных проектов. Пользоваться этим способом следует, если поле не используется ни в каких командных проектах или отчетах.

      Примечание

      Если удалить поле, используемое в отчете, отчет более не будет отображаться корректно.

  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
    

    Важно!

    При удалении поля без возможности восстановления вместе с полем удаляются связанные с ним данные из хранилища данных.

Проверка разрешения конфликтов схемы

Проверить, разрешены ли конфликты схемы, можно, обработав по запросу хранилища данных и затем проверив отчеты на предмет того, были ли они обновлены. Другой вариант — подождать выполнения заданий адаптеров хранилища в соответствии с их графиком по умолчанию. По умолчанию реляционная база данных обрабатывается каждые несколько минут. Куб служб аналитики, однако, по умолчанию обрабатывается каждые два часа.

Примечание

Дополнительные сведения о веб-службе управления хранилищем см. в разделе Обработка хранилища данных и куба служб аналитики вручную для Team Foundation Server.

  1. Обработайте по запросу реляционное хранилище данных с помощью операции ProcessWarehouse службы WarehouseControlService.

  2. Обработайте по запросу куб с помощью операции ProcessAnalysisDatabase службы WarehouseControlService.

  3. Откройте панель мониторинга или диспетчер отчетов и проверьте, обновлены ли отчеты. Дополнительные сведения см. в разделе Панели мониторинга (гибкая разработка) или Отчеты (гибкая разработка).

Если сообщения об ошибках продолжают появляться, получить дополнительные сведения о конфликте данных и соответствующих блокируемых адаптеров можно, выполнив операцию GetProcessingStatus службы WarehouseControlService.

См. также

Ссылки

Управление полями рабочих элементов [witadmin]

Основные понятия

Создание и настройка отчетов для Visual Studio ALM, а также управление ими

Другие ресурсы

Добавление и изменение полей рабочих элементов для поддержки отчетов

Обработка хранилища данных и куба служб аналитики вручную для Team Foundation Server