Новая версия VOGBIT 20.5 - Новая платформа: быстрее, надёжнее, удобнее. Новая подсистема управления приоритетами в производстве. Новые возможности для участков ЧПУ. Улучшенные «цеховые терминалы». Новые возможности для совместной работы менеджеров, инженеров и производства при изготовлении уникальной продукции под заказ. И многое другое…

Последние темы на форумах VOGBIT

Карта раскроя - Общие вопросы
mansur: Добрый день, благодарю за развернутый ответ. Только я остановился на начальном этапе - кнопки ""Задания для объединения" отсутст ...
Очередность при расчете комплектации - Производство
Илья: При изучении роликов и тех. документации я понял что автоматическое определение очередности основывается на составе изделия. Т.е если у ...
Колонка материалы для окна статистика производства - Производство
Константин Чилингаров: 13 Константин Чилингаров написал: Я думаю, что Вам можно было бы поразмышлять о некоем "конфигураторе уровня учета", где пользовате ...
Невозможно запустить приложение в связи с недействительными данными активации - Активация, Деактивация, Лицензии
Константин Чилингаров: Да, похоже, есть какая-то проблема с очередным обновлением десятки. Мы уже известили о ней разработчика системы защиты (мы её купили, не с ...
Влияние Статуса - Прочее
Константин Чилингаров: Здравствуйте, С точки зрения общей логики работы программы (различные расчёты, формирование заказов на производство и т.п.) для специфи ...
Активация/деактивация - Активация, Деактивация, Лицензии
Елена Ковалева: Добрый день! Отвечено на почту.
Расчёт потребности - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, По поводу «материалов» и «комплектующих». [B Первый момент – как лучше вносить:[/B Указывать в техпроцессе, как «комп ...
добавление и удаление деталей в заказ - Состав и технология
Константин Чилингаров: Да, есть такой момент. Много «хвостов» оставляет этот старый модуль «планирования загрузки». В версии 20.5 ещё не все из них удаляются лег ...
Внесение состава изделия, состоящего из большого числа вложенных сборок. - Состав и технология
Константин Чилингаров: 19208 Ирина Хохлова написал: все таки думаю, что фасад это сборочная единица и спецификация нужна Если "фасад" это некая конструкци ...
Пустой бланк - Демо версия
Константин Чилингаров: Правильно. С точки зрения выдачи чего-то со склада на выполнение некоего производственного заказа, обеспеченности, снабжения и т.п. - во ...
"Сворачивание" терминала - Терминалы
Константин Чилингаров: Ctrl+Shift+Esc - диспетчер задач. В нём снять задачу. Нужно только предварительно в диспетчере задач поставить галочку в его настройках "пок ...
Параметры командной строки клиента - Прочее
Константин Чилингаров: Здравствуйте, Да, можно. Вот так: "C:\Program Files\Vogbit\Csdn.Vogbit.Client.exe" -s=SRERVER -d=DATA_BASE -u=USER -is=no -p=PASSWORD -al=yes
Редактирование позиций при оформлении приходной накладной - Интерфейс программы
Константин Чилингаров: Здравствуйте, Про передвижение строчек было уже. Записано в списке пожеланий. Про замену номенклатуры - запишу. P.S. в новой версии сде ...
крнструкторская спецификация - Общие вопросы
Елена Ковалева: Добрый день! Могу предположить, что колонки были случайно удалены. Документация по настройке: https://vogbit.ru/support/628/#T918 https://vogbit.ru/support/628/#T918
Не копируется материал - Состав и технология
Илья: Спасибо, очень полезная кнопочка
Как вернуть производственный заказ в производство - Производство
xoxliandiia: Спасибо большое!!!))) получилось) 
Отображения количества деталей в терминале - Интерфейс программы
1113: Все верно.  И было бы здорово иметь возможность изменять шрифт комментариях к операции.  Например, у меня большая сборочная единица, в ...
Календарный план - Производство
Константин Чилингаров: Здравствуйте, Насколько я понимаю, сейчас карты заказов там идут вообще без какой-либо сортировки. В порядке создания. Как они появляли ...
Порядок строк приходной накладной - Интерфейс программы
Alex-220781: 13 Константин Чилингаров написал: Хорошо, понятно. Запишу отдельным пунктом в список предложений и пожеланий. Спасибо! Добрый день! На ...
Отсутствие РЦ в дашборде - Терминалы
Константин Чилингаров: Здравствуйте, Да, верно. На дашборде показываются данные по «текущей смене». Которая идёт непосредственно сейчас. Если таковой нет для с ...

Медленная работа - работа над ошибками

- Установка/настройка - Старые разделы форума
Страницы: 1
Медленная работа - работа над ошибками
 
После трех месяцев эксплуатации скорость работы заметно понизилась. Стали разбираться, обратились к разработчикам. Получили следующие рекомендации:
Из-за проблем с созданием темы на форуме попробую написать несколькими сообщениями
 
Продолжение...

Получили следующие рекомендации:
1. Выполнять пересчет статистики.
2. Очищать рабочую базу от устаревшей подробной истории всех действий пользователей (чистить "сеансы").
3. Очищать рабочую базу от устаревшей подробной информации о ходе производства.
4. Установить для базы данных свойство TRUSTWORTHY

При выполнении рекомендаций выяснились некоторые подробности, которыми хочу поделиться с сообществом.
1.Пересчет статистики – нужная и полезная операция. Ее полезно выполнять по планировщику, а не вручную. У нас при установке Vogbit в Maintenance Plans на сервере SQL был добавлен план под названием «VOGBIT defrag». План выполняет ребилд индексов базы данных Vogbit с коэффициентом заполнения 80%, попутно и статистика пересчитывается и данные пересортировываются в соответствии с кластерными индексами. Не помню, откуда он взялся (внедрение было сумбурным), вроде бы был создан автоматически, но может я и сам его сделал. В любом случае план полезен, рекомендую его включить или создать и выполнять раз в месяц. Надо только проследить, чтобы на сервере SQL Agent запускался автоматически. Однако выяснились и некоторые жуткие подробности:

a. По умолчанию после установки в свойствах базы данных Vogbit отключены автосоздание и автообновление статистики. Зачем это сделано совершенно не понятно. Но зато это как раз и приводит к заметному снижению производительности, если по какой-либо причине вышеуказанный ребилд индексов не выполняется. Настоятельно рекомендую включить эти опции и настроить по планировщику либо ребилд индексов 1 раз в месяц, либо пересчет статистики 1 раз в неделю (а хоть и каждую ночь).

b. По умолчанию после установки в свойствах базы данных Vogbit включено автоматическое сжатие (auto shrink) базы данных. Разработчик рекомендует выполнять эту операцию время от времени и в ручном режиме для улучшения производительности. Плохая рекомендация. Никогда так не делайте на промышленном развертывании!!! Сжатие базы данных, особенно если на ней не настроен правильный FillFactor, приводит только к фрагментации файла базы данных по физическому диску и к фрагментации страниц данных внутри файла базы данных. Такая двойная фрагментация может только замедлить работу, причем значительно, особенно, если сервер баз данных совмещает в себе прочие службы, например файловый сервер. Рекомендую:
    1) Отключить auto shrink (и забыть эту практику)
    2) Включить автосоздание и автообновление статистики. Выполнять ребилд индексов либо пересчет статистики по расписанию.
    3) Настроить для сервера FillFactor (хотя бы 80%) и выполнить ребилд индексов Vogbit. После этого FillFactor сервера можно вернуть к прошлым значениям. В дальнейшем индексы Vogbit будут использовать настроенный FillFactor, если явно его не менять.
    4) Установить для файла данных Vogbit размер с учетом прироста производственных данных + логи сеансов из расчета на период эксплуатации + FillFactor.
    5) Настроить для файла данных Vogbit ограничение на размер файла данных и размер автоприращения (лучше в мегабайтах, чем в процентах, лучше в размере месячного прироста данных + сеансы).

2.Чистить сеансы надо, но тут нам еще предстоит с разработчиком поломать копья.
  a. Во первых, я уже поднимал вопрос о правах SA для этой операции. Почему-то для администратора Vogbit эта функция закрыта и работает только для SA.
  b. Во вторых, нам бы хотелось автоматизировать данную процедуру. Какие для этого имеются возможности?
  c. В-третьих, на нашей базе сеансы занимают какое-то значительное место. Из 2.6 Гб после очистки половины сеансов освободилось 800 мб. Получается, что данные сеансов занимают в базе более половины. Хотелось бы понять, что такое пишется в эти сеансы в таком количестве, ведь это не производственные данные. Можно ли как-то настраивать уровень логирования сеансов?

3.Очистка базы от устаревшей производственной информации – тот же вопрос, как автоматизировать?

4.По поводу включения небезопасной и не рекомендуемой Microsoft опции TRUSTWORTHY я создам отдельную тему, но пока рекомендация вызывает сомнения и вопросы.
Изменено: Андрей Кравцов - 06.04.2017 09:43:05
 
За информацию спасибо. Изучим.
Другим пользователям тоже, возможно, будет полезно.

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

Уровень логгирования не настраивается. По всем изменениям пишется автоматом.
В прошлой программе, которую мы писали, настраивался. Было штуки 4 разных уровня, по моему. Не помню уже. Оказалось, бесполезная штука получилась. И вопросы постоянно возникали типа" а надо ещё вот это в лог добавить", "надо и вот это чтобы учитывалось" и т.п.
Тут поэтому сделали по другому.

По поводу автоматизации "очистки" сеансов и, тем более, производственной информации: представляется крайне затруднительным т.к. непонятно, как без участия человека, в данном случае определять, какая информация в данном конкретном случае ценная, а какая нет? Что удалять, а что нет? И в какой момент лучше удалять. Это крайне субъективная вещь, индивидуальная для каждого предприятия и случая.
Всяческие пересчёты статистики, планы обслуживания и т.п. - это можно делать в автоматическом режиме. Т.к. это не ведёт к изменениям в пользовательских данных.
А тут совсем другой коленкор....
 
Константин, я вижу, что ваша база данных хорошо структурирована и обвязана хранимыми процедурами. Процедуры даже избыточны, например некоторые из блока Health дублируют функционал инструментов MSSQL. Это говорит о том, что вы заложили в систему хорошие возможности автоматизации, наверное не хотели привязываться к версии сервера баз данных и упростить требования к квалификации персонала. Хочется этими возможностями пользоваться, поэтому я и задаю свои вопросы.

Логика подробного логирования понятна.
Уточню, что говоря ниже про лог я имею в виду внутреннее логирование Vogbit, а не лог SQL.
Не понятно влияние объема лога на производительность. Я не знаю деталей вашей реализации, поэтому могу только предполагать.
По идее лог - это такая структура, в которую данные много и последовательно пишутся и редко, только в случае инцидентов, читаются. Для того, чтобы он быстро отрабатывал запись, ему нужно упростить структура (возможно за счет избыточности уменьшить количество взаимосвязанных таблиц) и минимизировать количество индексов, триггеров и правил. Пусть уж чуть медленнее происходят редкие разборы полетов, чем тормозит основной функционал. В любом случае набор таблиц для логирования не пересекается же с таблицами для производственных данных. Как же его объем может влиять на скорость манипуляций с производственными данными? На мой взгляд в двух случаях:
1) Лог сам по себе так реализован, что медленно отрабатывает запись, поэтому тормозять и прочие операции, которые ждут записи в лог. Тут уж надо что-то в системе кардинально менять...
2) Лог занимает в базе значительное место, а база сильно фрагментирована. В нашем случае, как я предполагаю, это и было основной причиной. Про исправление данной ситуации я все подробно написал выше.

Давайте теперь порассуждаем про обслуживание лога. Тут, как мне кажется у вас есть перекос в логике.
С одной стороны вы говорите, что без человека не обойтись при очистке. С другой стороны функционал очистки вешаете на SA. У него может быть в обслуживании несколько десятков серверов и сотня баз данных. Что этот человек должен знать о сеансах Vogbit? Как принимать решение об очистке? Придется пригласить кого-нибудь из пользователей Vogbit, того, кто в Vogbit является администратором, но почему-то как раз сеансы чистить и не может, хотя это полностью внутренняя кухня Vogbit. Это мне напоминает анекдот на тему "Сколько программистов нужно, чтобы выкрутить лампочку". Такой подход провоцирует на удаление всего закрытого без разбора при возникновении тормозов в работе. Ну и в чем тогда ценность лога?

На мой взгляд, если уж в систему заложена возможность автоматизации, то замечательно работала бы схема:
1) Администратор Vogbit имеет право чистить сеансы
2) Можно настроить задание SQL Agent на запуск хранимой процедуры (у вас там даже есть какие-то заглушки General.CleanEvents, General.CleanObject), которая бы удаляла данные из лога, например так: все закрытые операции, дата закрытия которых произошла более 1 года назад. Срок давности можно задавать параметром.

В сочетании с правильно настроенным размером базы, FillFactor-ом и ребилдом индексов это создаст хорошо обслуживаемую, стабильную систему.

Очистку устаревших производственных заданий можно реализовать по этой же схеме.

Для особых случаев можно очищаемые данные не просто удалять, а выгружать в архив (хоты бы простой CSV) для тех, кому и очистить базу для производительности надо и данные необходимо хранить лет 10 по каким-либо требованиям законодательства.

Мне кажется, что возможности к автоматизации вы заложили, но сами же их и отключили своим завышенным требованием к работе от SA.
 
Спасибо, за ваше мнение и рекомендации.
Мы учтём. Но не сразу :)
Сейчас пока другие немного приоритеты.

Цитата
Андрей Кравцов пишет:
можно очищаемые данные не просто удалять, а выгружать в архив (хоты бы простой CSV) для тех, кому и очистить базу для производительности надо и данные необходимо хранить лет 10 по каким-либо требованиям законодательства.
Можно просто backup базы перед "очисткой" хранить для таких случаев. Нужно - развернул, там есть все данные.
 
Можно конечно и бэкапами на безрыбье пользоваться для архивирования, но попутно в бэкап попадет куча ненужной информации типа сеансов и это может сильно увеличить объем. Все-таки архив и бэкап - это разные вещи. Ну да ладно, об архиве я просто к слову упомянул, как вариант развития на будущее.

А вообще печально - если сказать коротко, то на все свои вопросы я получил ответ "может быть сделаем, когда-нибудь".

Мне кажется, что решение концептуальных вопросов по безопасности, производительности и управляемости системы по остаточному принципу к добру не приводит.
 
Специалист организации, у которой стоит на обслуживании наше компьютерное оборудование, запросил:
1. Официальные рекомендации ( от разработчиков ПО Vogbit ) по составу и порядку проведения работ на сервере SQL
2. Скрипт переиндексации таблиц базы данных Vogbit
3. Рекомендуемую конфигурацию компьютера, на котором база должна быть развернута. Для того, чтобы обеспечить достаточно быструю работу.
Изменено: Ростислав Осипов - 28.06.2017 15:13:43
 
Если клиент на сервере установить - ускорится работа?
 
Нет.

Если только сравнивать с тем, когда соединение с этим сервером идёт через интернет, откуда-нибудь издалека, или сеть локальная, но совсем мёртвая какая-нибудь. Тогда да.
 
Поставили последнее обновление - стало ощутимее быстрее работать.
В режиме Новые задания.
 
А после обслуживания базы (сжатие, восстановить индекс и прочнее) вроде опять медленнее стало...
 
Совет: в первую очередь почистите задания ненужные в базе. У вас там таких много. Может заметно ускорить.
 
Да уж почистили почти уже.
465 часов невыданых сейчас
Страницы: 1
Сейчас на форуме (гостей: 22)
Всего зарегистрированных пользователей: 3204
Приняло участие в обсуждении: 369
Всего тем: 804
Всего сообщений: 6067

Полезные ссылки:
Себестоимость Видео-презентация подготовка производства складской учет Полная версия VOGBIT Создание новой базы данных VOGBIT управление данными Планирование мелкосерийного производства Техническая Подготовка Производства электронный архив управление качеством деактивации VOGBIT активация VOGBIT управление производством Производственный заказ Установка VOGBIT управление ремонтами Трудоёмкость Деактивация VOGBIT планирование производства базы данных VOGBIT инструкция Начало работы Расчёт комплектации Складской учёт загрузка оборудования расчет себестоимости ТПП Демонстрационный режим VOGBIT Обновление VOGBIT График производства технологическая подготовка производственный учет Тип нормирования Заказ на производство производство металлоконструкций Нормирование пост руководство администраторов VOGBIT Планирование производства разработчика отчетов vogbit состав изделия демоверсия технология Состав изделия Обзор обновления Генератор отчетов склад Сменное задание Задания для производства Выбор уровня учёта новая база данных Расчёт общей стоимости материалов Заявки покупателей Управляемый расчёт материалов Парт
×
Вход на сайт