Настройка MS SQL Server под 1С: планирование и развёртывание (Часть вторая)

[Maxpiter]

Комментарий от НЛО принимаю с благодарностью :)) .. каюсь грешен.. «Не пьянства окаянного ради, а токмо пользы для» )))

[VenbergV]

Все же тип конфигурации, ERP и бухгалтерия должны быть не первоочередным вопросом рассмотрения. Рассматривать надо фактический тип нагрузки в весь период предполагаемой эксплуатации.
Недавно пришла бухгалтерша в одну фирму. Так пришлось удваивать ресурсы серверу приложения 1C. Благо он виртуальный. Т.к. она постоянно занималась пересчетом итогов и полным перепроведением своей пары баз, из двух десятков. Остальным бухгалтерам не хватало мощностей для спокойной работы по вводу первички и мелких отчетов. После ее ухода все вернули назад.
А у одного заказчика (правда очень давно) был вообще эпичный случай. Он за год дважды обновил сервер. И его пять бухгалтеров все равно жаловались на тормоза в работе. При этом новый сервер он взял со своей торговой компании. Где работало более сотни сотрудников и даже онлайн кассы. При детальном разбирательстве, эти пятеро бухгалтеров, по факту, оказались аудиторами большого количества разных компаний. Количество обслуживаемых компаний конечно же неуклонно росло, как и размеры передаваемых баз 1С. Все закончилось стойкой с серверами. По которой распихивали нагрузку, в зависимости от задач на тяжелые и длительные операции 1С с базами.

[Scank]

Если код изначально гамно, то никакой сервер не поможет.
Зачастую код пишется многими годами, появляются костыли и временно-постоянные решения, а кол-во сотрудников компании растет.. Работал в логистической компании, около 200 сотрудников. Новые версии 1с и настройки СУБД по бест практис помогали ускорить ее только на 10-15%, что конечно же не ощущалось в работе. Так как каждый запрос логиста в БД выгружал ВСЮ информацию по клиенту одним жирным запросом за несколько лет. А разработчики никак не хотели оптимизироваться, потому что не было времени на это

[mixsture]

Версионирование объясняет и внезапные вопросы к tempdb.

У меня нет статистики, но, думаю, что нет.

Основным источником нагрузки являются временные таблицы.

Они используются потому, что в язык SQL не завезли вообще никакой вариант отладки - ну т.е. не существует никакого варианта прогнать сложный запрос по шагам и где-то там найти баг. Отсюда каждый шаг сохраняют во временную таблицу. Это неправильное состояние информационной системы (будто бы всегда включен режим отладки и расширенных логов), но другого просто нет.

От сложности запросов тоже никуда не уйти. По шкале OLTP-OLAP - 1с исторически система сильно сдвинутая в OLAP, т.е. в аналитическую часть. Для них характерны большие sql запросы с агрегациями. Если вот 1с принудительно разделить на OLTP (ввод доков) и OLAP (отчеты и аналитически-сложные вещи вроде партионного учета) - то в OLTP базе не будет сильного использования tempdb.

Это вообще один из хороших и простых советов по улучшению работы с базой - максимально разнести нагрузку OLAP и OLTP. Потому что эти 2 вида систем не могут прийти к компромиссу: то, что хорошо для одной (больше индексов! больше денормализации и витрин данных!) - очень сильно убивает производительность второй. И так с любым тюнингом (в том числе и СУБД) - улучшим в одну сторону, во второй много потеряем. Отсюда вынос всех “пользователей-аналитиков” в отдельную базу с обновлением раз в сутки - очень действенное решение. Оно может прям в разы улучшить ситуацию с тормозами.