Константин Чилингаров: Да, судя по картинке, какая-то проблема с самим Excel'ем.
VOGBIT создаёт при формировании отчёта Excel файл в папке "Документы", а Excel (ну и ...
Константин Чилингаров: Здравствуйте,
Если речь про стандартный модуль импорта из Excel, то нет. Не зависит. Можно использовать на нескольких рабочих местах. Нет ...
Константин Чилингаров: Здравствуйте,
Спасибо за замечание,
Да, знаем, что там не очень в этом месте, когда разные единицы измерения параллельно используются. ...
Константин Чилингаров: Ответ, на самом деле, в предыдущем сообщении:
13 Константин Чилингаров написал:
Чтобы была возможность применять такую систему не повс ...
Константин Чилингаров: Здравствуйте,
3520 Alex-220781 написал:
Чтобы отредактировать значение минимального остатка
Я, когда хочу отредактировать "неснижаемый ...
Константин Чилингаров: Технически в следующей версии такая возможность предусмотрена. Успеем или нет её подключить в графический интерфейс (колонка чтобы поя ...
Константин Чилингаров: В заказной спецификации (дереве) указывается количество на единицу того, что делаем. Если меряется это, что делаем, метрами, то на 1 м "и ...
Константин Чилингаров: 19032 Илья написал:
изначально втулки делают именно под конкретный заказ
Тут у нас с вами некоторое терминологическое расхождение.
П ...
Константин Чилингаров: Я так понимаю, «подгонка толкателей» в данном случае это не заранее предусмотренная технологией операция, а некая дополнительная работ ...
Константин Чилингаров: Судя по сообщению, данная позиция используется в складском документе (в спецификации учётного документа).
Немного странно, что "где и ...
------------------------------------ ms-sql server: intel i7 8gb памяти, 1 Гб сеть OS win7 x64
клиентский (вогбит) компьютер(в настоящее время, с базой работает один компьютер, для теста): intel pentium 3Ghz, 4 gb памяти 1Гб сеть версия вогбит 1.1.300.71(94) OS win 7 x64 ------------------------------------ когда заходим в производство - задания(например), то очень все долго происходит, выдача заданий и другие действия, задержки порядка 30-60 секунд. При этом нет загрузки сети/процессора/памяти, у клиентской машины (согласно диспетчера задач)
как я понимаю, все дело в sql сервере, возможно какие-то настройки его влияют на такое падение производительности?
ms-sql server компьютер по диспетчеру задач так-же не тормозит. Хотя время от времени sql зависает и перестает работать, при этом дико нагружает дисковую подсистему .
Сейчас подумываем о переходе на свежую версию, но хотелось бы разобраться с причиной таких тормозов. Есть ли какие-то рекомендации с этим? SQL сервер был установлен как есть, без произведения каких-либо дополнительных настроек.
Чтобы база данных работала без потери производительности, её необходимо периодически обслуживать.
1. Выполнять пересчёт статистики. Если один человек работает и не интенсивно, то можно и раз в несколько недель или даже реже. Если работа с базой интенсивная, то можно хоть каждый день.
2. Очищать рабочую базу данных от устаревшей подробной истории всех действий пользователей (чистить "сеансы"). Это при интенсивной работе хорошо бы делать несколько раз в год хотя бы.
3. Очищать рабочую базу данных от устаревшей подробной информации о ходе производства (удалять задания по старым заказам, чистить расписание старое). Это раз в год хорошо бы делать при интенсивной работе.
Перед пп.2 и 3, естественно, в обязательном порядке делать резервную копию базы данных. Это вообще настоятельно рекомендуется делать регулярно. Каждый день можно, если реально программа для управления производством используется.
После массового удаления чего-либо (пп.2,3) нужно обязательно проводить в определённой последовательности определённые регламентные действия с базой (иначе резко (вплоть до нуля) снизится эффект от этого удаления): - почистить базу от информации связанной с логом массового удаления; далее на SQL сервере: - выполнить процедуру пересчёта зависимостей; - выполнить сжатие базы; - выполнить пересчёт статистики.
Если все эти действия по обслуживанию базы выполнять, то как показывает опыт, можно годами (пока статистика есть за 5 лет примерно) очень интенсивно работать, и производительность особо не падает. Если обслуживанием базы не заниматься, то постепенно размер её будет увеличиваться, и увеличиваться, а производительность падать, и падать. Всё больше и больше... Теоретически, можно, конечно, всё решить наращиванием мощностей сервера, но зачем? Достаточно просто поддерживать базу в "здоровом" состоянии.
Разница может быть очень большой. Пример из реальной жизни: Недавно "чистили" с клиентом одну "замусоренную" за пару лет интенсивной работы базу. Причём п.1 и 2 регулярно выполнялись. п.3 - нет. В качестве SQL сервера для измерений использовали мой слабенький компьютер 8-ми летней давности с 6GB RAM. Разница во времени отклика при выполнении некоторых функций до и после "чистки" базы: было - 5-7мин, стало - около 1 сек*.
Цитата
Станислав Залозный пишет: время от времени sql зависает и перестает работать, при этом дико нагружает дисковую подсистему
Это, как раз, косвенное свидетельство. Возможно, дело было так: Базу долго не обслуживали. За счёт хранения всей истории за всё время, огромных разросшихся логов, "дефрагментации" и т.п. она постепенно разрослась до пределов в разы (или на порядок) больше разумных. Серверу при работе с этой базой тупо не хватает физической памяти. Он начинает использовать диск вместо RAM. Результат - ОС на сервере начинает отчаянно крутить HDD, всё начинает дико тормозить. Рецепт спасения выше.
*Не ко всем действиям, безусловно, относится. Есть некоторые не очень быстрые сами по себе по определению. Например, создание заданий.
P.S. На форуме, если поискать, по разным темам разбросано множество обсуждений и советов на эту тему. Тут я просто всё собрал в одном месте.
Станислав Залозный пишет: так понимаю большинство пунктов рассмотрено в этой теме
В том числе. Таких похожих тем несколько можно найти
Цитата
Станислав Залозный пишет: вот это оно?
Оно Нужно делать так: - зайти в SQL Server Management Studio - выбрать свою базу - "Создать запрос" (кнопка или в контекстом меню) - в текст запроса написать exec [Health].[UpdateStatistics] - "Выполнить"
Цитата
Станислав Залозный пишет: как сделать перерасчет зависимостей
P.S. Если реально используете программу в производстве, то очень заметный (в разы) прирост производительности даёт чистка ненужной подробной истории по старым заказам (удаление заданий по старым заказам из рабочей БД - п.3). Особенно, если используется "высокий" или "максимальный" уровень учёта.
спасибо, все получилось и помогло, не получается лишь один пункт:
Цитата
Очистить журнал событий (меню Администрирование - Сеансы, всё кроме незакрытых удалить).
во-первых не совсем ясно что значит незакрытые, а во-вторых, после выделения любых сеансов - кнопка удалить неактивна(под пользователем SA и пользователь единственный в базе)
10 минут, конечно, многовато... Но так, в целом, нормально, что небыстро удаляются. Тем более, что, я так понимаю, до этого момента вообще никто не чистил сеансы не разу.
Скорость удаления ещё зависит и от количества событий за время сеанса. Если вы что-то удаляли массово перед этим, то эти последние сеансы - десятки тысяч событий могут быть. А они, как раз, наверное, первые среди выделенных были.
Дальше быстрее пойдёт
Не забудьте после удаления сеансов сделать пересчёт зависимостей, сжатие базы и пересчёт статистики. Обязательно.
с 6 гб база ужалась до 1.3 Гб. Основное место было под сеансами, и таки да, первые удалялись на много дольше чем середина-последние. Спасибо. Оптимизация полностью сработала.