Константин Чилингаров: Здравствуйте,
Обычно, непосредственно с терминала выгружают управляющие программы какие-нибудь, к заданию, которое берется в работу. Н ...
Константин Чилингаров: К сожалению, проблема хронического отсутствия времени пока не позволила сделать.
Лежит заготовка под второй ролик с лета. Пока отложена ...
Константин Чилингаров: написал:
Честно говоря, "средний" уровень как-то никогда не рассматривали для работы.
Всё меняется...
10 лет назад там действитель ...
Константин Чилингаров: написал:
Можно, пожалуйста, выложить скрины, как это реализовано
Пожалуйста:
Рис.1 - Параметры в справочнике. Которые я использовал, ка ...
Константин Чилингаров: Здравствуйте!
Да, встречали такую ситуацию. Но, к сожалению, пока никак не можем научиться её стабильно повторять. Не можем пока найти к ...
Константин Чилингаров: Здравствуйте,
На совсем понял, если честно вопрос в Вашей терминологии.
Давайте попробуем ещё раз разложить всё по полочкам…
Вы ...
Константин Чилингаров: Здравствуйте,
Вместе с расчетом материала на 7 шт. еще и штучное время поделилось на 7
В этом есть логика.
Обычно эту "единицу нормир ...
Константин Чилингаров: Здравствуйте,
Не совсем понятно. Если речь идёт об окне, где отражается график работы и загрузки постов по дням и сменам (высокий/максим ...
Константин Чилингаров: Здравствуйте,
Чтобы изделию «назначился» в программе некий «склад», куда такие именно изделия из производства сдавать, для этого д ...
Владимир Белов: Добрый день!
Попробуйте выполнить установку еще раз, MSSQLLocalDB, установленный в первую попытку, должен подхватиться программой установки ...
Константин Чилингаров: Здравствуйте!
Не совсем понятно. Не могли бы Вы приложить скриншот, пожалуйста?
Вообще, если речь идёт о вкладке меню "Правка" (в л ...
------------------------------------ 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 Гб. Основное место было под сеансами, и таки да, первые удалялись на много дольше чем середина-последние. Спасибо. Оптимизация полностью сработала.