none
Данные в базе ServiceManager отличаются от данных в DW RRS feed

  • Вопрос

  • Добрый день, Коллеги.

    Подкинули мне кейс: 

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

    Свежие инциденты в отчетах и консоли в синхронном состоянии. 

    задачи DW выполняются в штатном режиме, т.е. нет ни одной задачи в состоянии "сбой или в зависшем  состоянии "выполняется" с древней датой запуска.

    В журнале Operations Manager в текущее время отсутствуют ошибки, указывающие на проблемы с загрузкой и извлечением. 

    Я сам связываю проблему с тем, что некоторое время назад DW отвалился, т.к. при установке кто-то забыл ввести ключ продукта и у него закончился триальный период. Сколько времени длилась эта проблема пока неизвестно. 

    Но известно, что в первых числах августа проблема с триальным периодом была решена. 

    Мне необходимо понять две вещи: 

    1. какое количество инцидентов или других рабочих элементов находится в несинхронизированном состоянии? (как выполнить такое сравнение?) 

    2. как синхронизировать данные?


    14 сентября 2017 г. 11:23

Ответы

  • Изменение WI не помогло. 

    Оказалось, что изменения накапливаются в таблицах Inbound базы StagingAndConfig. У проблемных записей накапливается значение в поле RejectCount.

    Проблему решили при помощи Premier Support. Сделали сброс всех Watermark, вызвав тем самым полную синхронизацию.

    5 октября 2017 г. 3:17

Все ответы

  • Хотя один способ восстановления я наверное знаю - нужно внести какое-либо изменение в рабочий элемент и тогда в DW вероятно будет внесено изменение с актуальными данными. 

    Но остается открытым вопрос - как получить список различающихся рабочих элементов. 

    14 сентября 2017 г. 11:45
  • Привет. Похожие проблемы были. "Подвисшие" WI действительно нужно изменить и они должны переползти в DW. Насчет проверки. Есть колхозный метод. Запрос на в SQL сделать. Либо с DW либо с MS. Главное добавить в Management Studio связанный сервер. Например, для DW добавляешь связанный MS и выполняешь уже запрос с использованием базы сервера управления и архивной, в котором проверяешь различия. В статусе или еще чем. Вот пример для проверки просто наличия инцидента в оперативной базе и его отсутствия в архивной : 

    select mainIR.<Имя поля с ID на сервере MS> as Deltas_Ids
    from <имя связанного сервера MS>.[ServiceManager].[dbo].[MT_System$WorkItem$Incident] as mainIR
     left join dbo.IncidentDim as IR on mainIR.BaseManagedEntityId = IR.BaseManagedEntityId
     where ir.BaseManagedEntityId is null
     order by Deltas_Ids
    


    Алексей Марченко

    4 октября 2017 г. 7:42
  • Изменение WI не помогло. 

    Оказалось, что изменения накапливаются в таблицах Inbound базы StagingAndConfig. У проблемных записей накапливается значение в поле RejectCount.

    Проблему решили при помощи Premier Support. Сделали сброс всех Watermark, вызвав тем самым полную синхронизацию.

    5 октября 2017 г. 3:17