Изменения в лицензионном соглашении - Согласно условиям действующего Лицензионного соглашения уведомляем Вас об изменениях в Лицензионном соглашении, которые вступят в силу, начиная с версии VOGBIT 20.8 (1.1.54861). Согласно условиям действующего Лицензионного соглашения, обновление пользователем своей программы до версии VOGBIT 20.8 (1.1.54861) будет означать его полное согласие с условиями новой редакции Лицензионного соглашения

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

Ошибка при планировании производства - Демо версия
Константин Чилингаров: Здравствуйте, База развернута из стандартного дистрибутива? Если да, то скорее всего, не хватает запчасти от Windows под названием vcredist_VS2 ...
Удаление категории номенклатура - Прочее
Константин Чилингаров: Здравствуйте, "Удалить из папки" (см. рис.)
Ошибка при замене материала - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Может быть, документ (ЛЗК или Требование), в котором пытаетесь "замену" сделать, "проведён" ("оприходован") ?
Ошибка на экране после получения задания - Терминалы
Константин Чилингаров: Ок. Спасибо. Посмотрим. 
Поменять технологию - Производство
Илья: 13 Константин Чилингаров написал: И придется как-то сжиться с тем, что она есть. По другому не получится. Понятно, будем тогда сначала п ...
Изменение временных интервалов на терминале. - Терминалы
Константин Чилингаров: Здравствуйте, Пока не настраивается. Со временем нужно будет делать какие-то настройки, да. Уже накапливаются потихоньку всякие пожел ...
Вопрос на тему "Технология подробно" - Состав и технология
Константин Чилингаров: Здравствуйте,   Можно теоретически заморочиться с «объединёнными» заданиями. Недавно на форуме где-то обсуждалось про них (объедине ...
Упрощенная сдача на склад - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Время, которое затрачивается на обновление, зависит от размера базы данных, сервера, компьютера, с которого выполняется, и соединения ме ...
Совместная обработка - Производство
Константин Чилингаров: Со сборкой - сваркой - окраской, то всё понятно. В плане технологии - тут всё просто. Есть Балка. Есть техпроцесс на неё. Три операции: с ...
Плагин на форму отчета - Новые возможности
Константин Чилингаров: Здравствуйте, Пока нет, к сожалению.
Календарный план - Производство
Константин Чилингаров: Не очень понятно, что вы имеете в виду под словами "сделать планирование по номенклатуре в соответствии с уровнями". Вообще, как я ...
Учет комплектующих изготовленных по фактическому количеству материала. - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Не совсем… 19032 Илья написал: для контроля "задела" необходимо создать свою заказную спецификацию Нет. Никакую специальную «за ...
Нажатие Enter в поле поиска при поступлении по заявке. - Ошибки в работе
Константин Чилингаров: Ок. Принимается. По мере возможности посмотрим, что там можно сделать.
Удаление позиции из номенклатуры - Прочее
Константин Чилингаров: Если она нигде не используется (в заказах, спецификациях, документах и т.п.), то есть утилита "Генератор удаление" (в меню "Настройк ...
Копирование спецификаций с комментариями - Интерфейс программы
Константин Чилингаров: Здравствуйте, Записал в список пожеланий.
Экспорт в Vogbit - Состав и технология
Константин Чилингаров: Здравствуйте, Понятно. Проблема из-за того возникла, что папку с файлами сложили прямо в C:\Program Files\VOGBIT. Откуда файлы добавляли. Програм ...
Пустой бланк - Демо версия
Константин Чилингаров: Бывает такой эффект, говорят, когда по какой-то причине завис в Windows в процессах Excel. Если так, то соответственно, перезагрузка помогает.
Не могу создать технологию подробно - Состав и технология
Minicnc14: Отбой, настройки поправил и заработало
О номенклатуре и технологии - Состав и технология
Vdovin-g: Здравствуйте! Спасибо, Вы подтвердили мои мысли
Расчёт потребности - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, В контексте данной задачи не нужно "заказных спецификаций" на входящие компоненты. "Заказная спецификация" ну ...

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

- Установка/настройка - Старые разделы форума
Страницы: 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
Сейчас на форуме (гостей: 27)
Всего зарегистрированных пользователей: 3339
Приняло участие в обсуждении: 376
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт