Пополнение в разделе «Документация» - Складской учёт, упрощённые операции

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

Тёмная тема - Прочее
Сергей: Здравствуйте! В этом окне сейчас нет настроек отображения. Цвет текста починим в новой версии. Если ещё где-то сталкиваетесь с подобным ...
Движение за период CurrentQuery - Отчёты
Сергей: Здравствуйте! Запрос в файле.
Сменный график - Общие вопросы
Константин Чилингаров: Да, список для выбора получится так поменьше. Но зато сначала то нужно будет ещё составить этот "список поменьше" из общего. Причем ...
Альтернативное обозначение отправочных марок - Отчёты
Константин Чилингаров: Здравствуйте,  Нужно в шаблоне отчёта поменять, чтобы вместо обозначения номенклатуры выводилось значение параметра этой номенклату ...
Пример создания плагина - Плагины
Константин Чилингаров: Не вижу смысла писать в таком случае свои "удалялки". Потеря времени. Проще и быстрее штатными функциями все поудалять в данном конк ...
Создание заказа на производство с учетом остатков/задела - Прочее
Константин Чилингаров: Здравствуйте, В современных версиях VOGBIT есть (где-то в прошлом году появилось впервые) "Автоматическое" заполнение (раззворачиван ...
Типовой технологический процесс - Состав и технология
Константин Чилингаров: Здравствуйте, Можно, например, создать стандартными средствами «Производственный заказ» (там как раз «разматывается» всё изделие по ...
График производства. Текущие работы - Производство
Sidneyanton: Спасибо за ответ, действительно не было связей, наверное при запуске стояла другая настройка последовательности.
Статистика - Производство
Алексей Пономарев: Благодарю за помощь все поправил.
Складской учет - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: написал: Еще бы поиск допилить в обеспеченности по заказам, чтоб искал не только номер, но и материал Будет. В ближайшем обновлении, на ...
Предварительные заявки - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Я посмотрел Ваш ролик. Спасибо! Только с обновлением это, по-моему, никак не связано.   Давайте поясню один момент: ...
Новая документация "График производства" - Прочее
Константин Чилингаров: Движок форума не разрешает напрямую Excel файлы в сообщения вставлять. Ну ладно. Понятно, в общем, о чем речь. на будущее: если нужно Excel фа ...
Ошибка отчёта "Недостаточно памяти" - Отчёты
Константин Чилингаров: Тут ещё знаете, в чем может быть дело... Не в размере даже, а во внутренностях конкретного файла с картинкой. Ошибка может озвучиваться си ...
Дублирование приходных ордеров - Прочее
Константин Чилингаров: Здравствуйте, Очень странная картина... Не сталкивались никогда с таким. Копию базы данных можете дать нам посмотреть? Если есть техни ...
Распределение работ. Дискретность настройки - Прочее
Константин Чилингаров: Здравствуйте, В этом окне, насколько я помню, сохраняется только список "постов" выбранных. При закрытии/открытии окна. Порядок сл ...
«Шаблон техпроцесса» - Состав и технология
Sidneyanton: Спасибо, за подробное разъяснение!
VOGBIT Онлайн - Общие вопросы
Владимир Белов: написал: Добрый день! Такой вопрос. Могу я установить базу данных на съемный диск и пользоваться на разных компьютерах - переставляя то ...
Создание нового производственного задания - Производство
Константин Чилингаров: Здравствуйте, написал: еперь при создании заказа в окне "Производственные заказы" этот самый заказ "дублируется" в окне " ...
Вопрос на тему "Технология подробно" - Состав и технология
Zms.komissarov: Нужно открыть, какой-нибудь (из какого удобно печатать) вариант "подробного" графика производства, там выбрать соответствующую опе ...
Не отображается выпадающий список, а также неактивна кнопка "Импорт" - Ошибки в работе
Сергей: написал: Не отображается выпадающий список при нажатии на стрелочку Напишите на mailto:info@vogbit.ru info@vogbit.ru Попробуем починить

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

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

×
Вход на сайт