Необходимо пояснение, что влияет на размер таблицы «Архив ошибок устройств». Такого сочетания слов я не нашёл в руководстве пользователя.
Что повлияло на размер этой таблицы, почему она больше суммы суточных и часовых значений? Прочие данные в этой системе несущественны.
Пожалуйста, ознакомьтесь с соответствующим разделом документации Архив ошибок. Под этим архивом подразумевается именно он. Просто в отчете использовано более подробное описание, что не меняет сути хранимых в данном архиве данных.
Не могу понять почему вы сравниваете размер таблицы архива ошибок с суммой суточного и часового архива? Мы никогда не заявляли о каком либо подобном равенстве. Это совершенно разные таблицы, у которых совершенно разный набор полей, не связанных друг с другом.
Вес данной таблицы зависит исключительно от количества записей в ней.
В таблице с данными просто отображается сводная информация архива ошибок и архивных данных (суточных, часовых, месячных), но в БД архив ошибок хранится в отдельной таблице, поэтому в отчете о состоянии системы она фигурирует отдельно.
Не согласен с определением «просто». Вы используете внутри ПО очень похожие термины для обозначения разных элементов программы. Не стоит упрощать, так как для правильного понимания вашего упрощения нужно «жить внутри программы», пользователи так не делают. Вот что выдает система поиска при наборе «архив ошибок устройств»:
Вы сами ответили на вопрос, почему я сравниваю размеры таблиц данных и архива ошибок. Для меня это две колонки в таблице данных. Отдельной таблицы в интерфейсе я не вижу. Количество строк таблицы ошибок не превышает количество строк данных, а размер для менее значимой информации (архива ошибок) больше. Поэтому и вопрос.
После запуска диспетчерского контроля с опросом раз 15 мин нескольких десятков узлов, стала стремительно расти именно эта таблица. А планируют опрашивать 1 раз в 5 мин. Большинство записей архива ошибок устройств пустые. В конкретной описываемой ситуации архив ошибок устройств вообще не нужная информация.
Я сравнивил с аналогичными системами.
вот пример 3.58.5 - размер архив ошибок устройств значительно меньше размера данных. Количество объектов в обоих системах +/- такое же, приборы и график опроса такие же, отличие в отсутсвие опроса 12 объектов каждые 15 минут
И на один вопрос в первом посте все еще нет ответа: Как я могу повлиять на размер обсуждаемой таблицы?
С интерфейса никак, только ограничить хранение архивов суточных и часовых потреблений.
Эта таблица весьма близко к структуре БД в первую очередь для нас в случае если нужно разобраться с проблемой клиента.
Ваш ответ сначала обрадовал, но цифры омрачают картину. Таблица «Архив ошибок устройств» мною не была замечена в версиях 3.56 и 3.57 (специально проверил).
В версии 3.58 она занимает примерно 10%. У меня есть две достаточно разные системы. В одной (около 300 объектов) 80% абонентского учёта опрашивается ежечасно (часовой и суточный архив) только в рабочие часы (14 часов в сутки), остальное — 1 раз в сутки (суточный). Общий размер базы данных — 4595 МБ, размер таблицы «Архив ошибок устройств» — 425 МБ (9,2%). Во второй системе более 800 объектов, из которых около 170 опрашиваются каждые 15 минут круглосуточно, остальные — аналогично первой системе. Размер базы данных — 37017 МБ, размер таблицы «Архив ошибок устройств» — 3772,1 МБ (10,2%).
В версии 3.59.4 обсуждаемая таблица занимает уже 31,61%! Размер таблицы — 1929,1 МБ, размер базы — 6103 МБ. При этом есть система 3.59.3, где эта цифра составляет 5,3%.
Сравнение всех этих цифр не совсем корректно, так как системы разные, но других данных у меня нет. И на основании этих данных я уже могу делать выводы.
Кроме того, моё предположение о существенном влиянии частоты опроса на размер таблицы оказалось неверным.
Вот что я увидел:
В проблемной системе (3.59.4) системе было два обновления: до 3.58.5 — 04/11 и до 3.59.4 — 23/11. Диспетчерский опрос был запущен 15/11 (всего 12 объектов, 1 раз в 15 минут, круглые стуки и хранение текущих 3 мес.), в тот же день немного оптимизировали автоопрос, уменьшив количество запрашиваемых данных целиком по системе.
График изменения размера базы данных этой системы (скриншот из первого поста поста соответсвует этому графику):
Вот список рассылок отчетов о состоянии системы
Последние 4 точки я отметил отдельно и указал даты
Первые 3 точки показывают естественный небольшой рост из-за увеличения количества опросов. А вот резкий рост с 21/11 по 25/11 (примерно на 400 МБ или на 7%) объясняется только обновлением. В системе ничего значимого, влияющего на размер базу данных, не происходило.
Создаётся ощущение, что с такой заботой «ребёнка» задушите 
Если серьёзно, то хочется управлять размером этой таблицы. Недопустимо, чтобы обновление ПО приводило к ухудшению быстродействия системы и необходимости перехода на другую базу данных
Вы сделали неверенй вывод относительно этой таблицы. Она появилась далеко не в 3.58, ей уже лет 10. До этого она просто не отображалась в отчёте. Рост базы связан, скорее всего, не с ней, а с другими причинами.
Размер таблицц кроме всего прочего сильно зависит от модели опрашивемых приборов.
Таблица является частью суточных и часовых архивов и очистить ее можно только вместе с ними.
Уточню. Эта база данных существовала и раньше, но вы стали отображать её только в версии 58?
И на размер этой таблицы влияют только суточные и часовые архивы, текущие данные не влияют?
В этой системе практически все приборы — СПТ94х всех поколений и модификаций. Коды ошибок из приборов не используются, диагностика ведётся только на уровне ЛЭРС Учёта.
При этом рост размера базы данных на 7% сразу после обновления связан с самим обновлением. Что именно могло повлиять?
А также смущают, что 31% базы занимают данные с непонятными рычагами управления. Хотелось бы больше информации и способов управления размером этой таблицы.
Верно.
Скорее всего это индексы, которые мы иногда добавляем для того, чтобы ускорить выборку из базы там, где это возможно.
Я уже говорил, что это часть суточных/часовых/месячных архивов и управляются вместе с ними. То есть, нужно настроить очистку архивов и эти данные тоже будут удалены.
Кстати, очень хорошо, что вы подняли эту тему. Сейчас посмотрел на механизм очистки этого архива и увидел, что как раз часовые и суточные данные в нём могут не очищаться при еженочном обслуживании базы. Внесём правки в 3.59.5. После этого дождитесь ночного обсkуживания, сожмите базу инструкции из этой статьи и снова проверьте размер этой таблицы.
Добрый день!
Обновление 3.59.5 (сборка 35910) от 27.11.2024 доступно для установки.
Уточните, пожалуйста, какие параметры обслуживания базы данных у вас настроены? Покажите скриншот данных настроек. Есть ли записи какого либо типа данных из перечня обслуживаемых, которые вышли за срок хранения, заданный в вышеописанных настройках, но не были удалены? Если да, покажите их скриншот.
Сейчас так.
Вчера срок хранения часовых архивов был изменён с 24 месяцев до 12. Таким образом, скриншоты в предыдущем сообщении отражают настройку 24 месяцев.
На сегодня размер базы данных составляет:
Ситуация стала ещё непонятнее. Общий размер базы данных уменьшился на 11%, таблица с часовыми данными — на 53%, однако обсуждаемая таблица увеличилась на 14% (на 275 МБ).
Это утверждение, следовательно, неверно.
В настоящее время размер обсуждаемой таблицы составляет более 40% от размера всей базы данных. Непонятно, как это регулируется.
Пожалуйста, включите отладку Сервера ЛЭРС УЧЕТ, запустите очистку БД вручную из Системных параметров и дождитесь окончания ее выполнения. После этого отладку можно выключить. Пришлите журнал работы Сервера за день выполнения вышеописанных шагов.
Как по мне таблицу MeasurePointDeviceErrors, можно чистить и без удаления основных данных. Нам по работе этот архив не сильно нужен (разве что за ближайшие пару дней), а размеры у него могут быть приличные, зависит от приборов. У нас 2 сервера ЛЭРС, в одном эта таблица пустая, а в другом 26 гигов весит.
PS: Я не отношусь к фирме пользователя Kvashnin если что.
Если я правильно вас понял, то вы подразумеваете удаление из соответствующей таблицы архива ошибок вручную при помощи скрипта. Это конечно возможно, но мы не рекомендуем так делать. Подобные действия стоит выполнять с максимальной осторожностью.
Я скорее намекаю, что можно эту таблицу добавить в “Обслуживание базы данных” отдельно.
Запущу в субботу - покажу результат.
ага, ну или иные, внятные рычаги управления
Хорошо, ожидаем.
Это требует отдельного обсуждения с нашими разработчиками, поэтому вам стоит создать по этому поводу соответствующее предложение по улучшению.
