Компоновочные блоки > Компоновочные блоки, специфичные для решения > Компоновочный блок KPI операций > Потеря доступности базы данных и связанные с этим последствия
Потеря доступности базы данных и связанные с этим последствия
В решении DPM используется две базы данных: база данных DPM, которая создается при первоначальном развертывании решения, и база данных ThingWorx. База данных может стать недоступной по многим причинам, таким как регулярное обслуживание базы данных, потеря сетевого соединения или сбой диска. В том случае, если база данных становится недоступной, существует возможность потери или дублирования данных, поступивших посредством автоматизации.
• При потере или дублировании данных, в которых содержатся порядок работы, основная запись материала или целевое количество событий, для неверных порядков работы или материалов могут быть записаны последующие события и счетчики.
• При потере или дублировании данных, в которых содержатся события количества производства или количества брака, данные для количества производства и количества брака могут стать неверными. Для переключаемых счетчиков это дает отрицательный волновой эффект. Дополнительные сведения о переключаемых счетчиках см. в разделе Настройка автоматизации данных.
В большинстве сценариев DPM и ThingWorx оснащены процессами, помогающими избежать потери или дублирования данных, если база данных становится недоступной.
• Если база данных DPM становится недоступной в какой-либо момент во время пакетной обработки, то пакетная обработка завершается в этой точке. Для свойства PTCLastProcessedEventTimestamp задано значение метки времени последнего успешно обработанного события. При следующем запуске таймера событий автоматизации для потока значений выполняется запрос о необработанных данных события. Обрабатываются все события с меткой времени, которая возникает после текущего значения свойства PTCLastProcessedEventTimestamp, включая события, которые еще не были обработаны, при завершенной ранее пакетной обработке.
• Если база данных ThingWorx становится недоступной, данные события записываются в очередь потоков значений. У ThingWorx есть механизм повторной попытки восстановления соединения с базой данных. Когда база данных становится доступной, записи из очереди потоков значений добавляются в поток значений.
В этом разделе описаны нетипичные сценарии, в которых недоступность базы данных может привести к потере или дублированию данных, а также сведения о том, что можно сделать, чтобы определить, когда произошли эти сценарии, и как устранить проблемы с данными.
Поток автоматизации данных
Чтобы лучше понять такие сценарии, полезно разобраться в потоке высокого уровня для обработки данных событий автоматизации данных. Следующий поток сопровождается каждым регулятором темпа, настроенным для автоматизации данных:
1. Данные события получены через автоматизацию данных. Данные хорошего качества записываются в очередь потоков значений. Записи из очереди добавляются в поток значений.
2. Запускается таймер событий автоматизации, и начинается пакетная обработка :
a. Поток значений выполняет запрос необработанных событий. Необработанными событиями являются события с меткой времени, произошедшие после установки текущего значения свойства PTCLastProcessedEventTimestamp.
b. Запрашиваемые события обрабатываются для каждой метки времени по порядку.
c. Количество производства и количество брака записываются в буфер для объединения подсчетов в группы для каждого счетчика.
d. Сгруппированные счетчики вставляются в базу данных DPM.
3. Свойство PTCLastProcessedEventTimestamp обновляется после успешной обработки каждого события. Для счетчиков производства и количества брака свойство PTCLastProcessedEventTimestamp не обновляется до тех пор, пока все сгруппированные счетчики не вставляются в базу данных. Последняя метка времени из всех буферизованных групп задается как PTCLastProcessedEventTimestamp значение свойства.
Сценарии
В следующей таблице описаны нетипичные сценарии, которые могут привести к потере или дублированию данных. Нужно иметь ввиду, что поток автоматизации данных присутствует в каждом регуляторе темпа, который сконфигурирован для автоматизации данных. В зависимости от времени выполнения сценария это может повлиять на некоторые регуляторы темпа.
Сценарий
Описание
Результат
База данных DPM становится недоступной при обработке нескольких событий с одинаковой меткой времени.
Для каждого события, полученного через автоматизацию данных, есть метка времени. Наличие одинаковой метки времени для нескольких событий является возможным, но это нетипичная ситуация. Когда это происходит, события с одной и той же меткой времени обрабатываются в следующем порядке: порядок работы, основная запись материала, целевое количество, доступность, и, наконец, количество производства и количество брака.
Если существует несколько событий с одной и той же меткой времени, свойство PTCLastProcessedEventTimestamp обновляется после того, как будет обработано первое событие с этой меткой времени.
Если база данных DPM становится недоступной до того, как все события с одинаковой меткой времени будут успешно обработаны, все необработанные события с этой меткой времени теряются, включая количество производства и количество брака. Это обусловлено тем, что при следующем запуске таймера событий автоматизации запросы для событий с метками времени, которые происходят после текущего свойства со значением PTCLastProcessedEventTimestamp, обрабатываются в пакетном режиме.
Все необработанные события, имеющие одинаковую метку времени со свойством PTCLastProcessedEventTimestamp, будут потеряны, включая количество производства и количество брака.
База данных ThingWorx недоступна, и очередь потоков значений заполнена.
Когда база данных ThingWorx становится недоступной, события, поступающие посредством автоматизации данных, продолжают добавляться в очередь потоков значений до тех пор, пока не будет достигнут предел размера очереди. Когда база данных снова станет доступной, очередь потоков значений обрабатывается для добавления записей в поток значений, где выполняются запросы таких записей во время пакетной обработки при следующем срабатывании таймера событий автоматизации.
Если очередь потоков значений заполнена, все новые события, поступающие посредством автоматизации данных, отклоняются.
Отклоненные события теряются.
База данных ThingWorx недоступна, и сервер ThingWorx перезапущен.
При перезапуске сервера ThingWorx все содержимое в очереди потоков значений и в очереди хранилища данных будет потеряно. Записи, которые были добавлены в поток значений, но не были обработаны, сохраняются.
Все данные в очереди потоков значений и в очереди хранилища данных будут потеряны.
База данных ThingWorx недоступна, число повторных попыток соединения использовано до конца, и ThingWorx выключен.
Если число повторных попыток, настроенное для механизма повторного входа в базу данных ThingWorx, использовано до конца, сервер ThingWorx завершает работу. Дополнительные сведения о механизме повторных попыток ThingWorx см. в разделе Сохранение данных в ThingWorx в справочном центре ThingWorx.
Все данные в очереди потоков значений и в очереди хранилища данных будут потеряны.
Все новые события, поступающие посредством автоматизации данных при завершении работы ThingWorx, будут потеряны.
База данных ThingWorx становится недоступной до тех пор, пока очередь хранилища данных не будет обработана, чтобы обновить свойство PTCLastProcessedEventTimestamp, а сервер ThingWorx - перезапущен.
Если база данных ThingWorx становится недоступной до тех пор, пока очередь хранилища данных не будет обработана, чтобы обновить свойство PTCLastProcessedEventTimestamp, а сервер ThingWorx будет перезапущен, содержимое очереди хранилища данных будет потеряно. Для свойства PTCLastProcessedEventTimestamp остается предыдущее значение. Это означает, что события с метками времени, которые происходят после того, как значения свойства PTCLastProcessedEventTimestamp были обработаны и добавлены в базу данных DPM, будут повторно обработаны и снова добавлены в базу данных.
При повторной обработке событий данные дублируются.
Идентификация инцидентов доступности базы данных
Можно определить, когда событие доступности базы данных привело к потере или дублированию данных двумя способами.
• Контроль Инструментальной панели производства во время производства. Операторы автоматизированных регуляторов темпа могут определить, когда отображаются неверные данные, на текущих производственных участках и в развернутых журналах событий.
• Просмотрите журналы ThingWorx для выявления ошибок недоступности базы данных, особенно при обслуживании базы данных или других действиях, которые могут повлиять на доступность базы данных. Установите регулятор темпа, на который произошло влияние, и проверьте имеются ли потерянные или дублированные данные на информационной панели производства.
Проблемы адресации данных
Несмотря на то, точная стратегия уклонения от таких редких ситуаций отсутствует, есть действия, которые можно выполнить для адресации результатов при их возникновении.
• Сбросьте неверное количество производства и количество брака для отдельных регуляторов темпа.
1. Остановите сервер Kepware.
2. В ThingWorx Composer перейдите в вещь регулятора темпа.
3. В разделе Свойствадобавьте строку в свойство PTCLastAutomationProcessedValues таблицы данных со следующей информацией для каждого счетчика, который требуется переустановить:
▪ propertyName: для количества производства введите PTCPoductionCount. Для счетчиков количества брака введите наименование свойства брака.
▪ value: значение, для которого требуется сбросить количество.
▪ jobOrderUid: DPM игнорирует это поле.
4. Запустите сервер Kepware.
Дополнительные сведения о количестве производства и количестве брака см. в разделе Настройка автоматизации данных.
• Вручную введите недостающие данные для отдельных регуляторов темпа на Инструментальной панели производства. Для производства, начиная с последних 24 часов, моментов потери, количества производства и количества брака, данные которых были внесены в течение последних 24 часов, можно ввести вручную для каждого регулятора темпа. Кроме того, исторические события брака могут быть можно добавить в течение недели.
• Вручную удалите дублированное количество производства для отдельных регуляторов темпа на Инструментальной панели производства. Для текущего производственного участка можно удалить количество производства с панели Запись производства на инструментальной панели производства. Чтобы удалить количество производства за последние 24 часа, можно использовать окно Учет потери времени.
Было ли это полезно?