Ситуация, когда после разделения единой информационной базы на бухгалтерскую и управленческую одна из них начинает работать значительно медленнее, является классической проблемой для администраторов и программистов «1С». Зачастую «под удар» попадает именно бухгалтерская составляющая. Разберем по шагам, почему это происходит, как провести диагностику и какие конкретные действия помогут вернуть системе былую скорость.
Проанализируем ситуацию: само по себе разделение баз не должно приводить к деградации производительности, если объем данных уменьшился. Однако на практике возникают скрытые факторы. Выясним причину, используя системный подход. Первым делом нам необходимо исключить влияние «битых» ссылок и логических ошибок, о которых упоминалось в начале обсуждения. Хотя поврежденные движения могут вызывать ошибки при проведении документов, основной причиной «тормозов» они становятся редко.
Рассмотрим более вероятные факторы:
Прежде чем что-то исправлять, нам нужно понять, где именно система тратит время. Для этого используем встроенный инструмент «Замер производительности». Посмотрим на пример его использования: необходимо запустить отладчик, включить замер и выполнить ту операцию, которая «тупит» (например, открытие ОСВ или проведение реализации).
В результатах замера мы должны обратить внимание на колонку «Чистое время». Если основное время уходит на выполнение запросов (Запрос.Выполнить()), проблема кроется в базе данных или индексах. Если же время тратится на циклы обработки данных в коде, проблему нужно решать оптимизацией алгоритмов.
В «1С:Бухгалтерии» расчет остатков и оборотов напрямую зависит от таблицы итогов. Разберем подробнее: если период рассчитанных итогов значительно отстает от текущей даты, система вынуждена вычислять данные «на лету», суммируя все движения из таблицы регистра. Это колоссальная нагрузка.
Для исправления ситуации выполним следующие действия в режиме «1С:Предприятие»:
Если база данных работает на SQL-сервере, то после разделения (когда было удалено много данных) индексы и статистика приходят в негодность. Проанализируем ситуацию: SQL-сервер строит план запроса на основе статистики. Если статистика говорит, что в таблице миллион записей, а их там осталось сто тысяч, план будет неоптимальным.
Выполним обязательный комплекс работ на стороне сервера БД:
Если стандартные методы не помогают, перейдем к «тяжелой артиллерии». Настроим сбор Технологического журнала (ТЖ) для поиска длительных запросов. Нас интересует событие DBMSSQL (или DBPOSTGRS) с длительностью более нескольких секунд.
Пример настройки logcfg.xml для отлова долгих запросов может выглядеть так:
<config xmlns="http://v8.1c.ru/v8/config/logcfg">
<log location="C:\LOGS\SLOW_QUERIES" history="24">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="1000000"/>
</event>
<property name="All"/>
</log>
</config>
После анализа логов мы увидим конкретные SQL-запросы, которые выполняются долго. Часто это помогает выявить отсутствие нужного индекса или некорректное использование временных таблиц в коде.
В бухгалтерских базах часто включают RLS по организациям. Посмотрим, как это влияет на скорость: к каждому запросу пользователя Платформа неявно добавляет огромный кусок кода, проверяющий права на каждую запись. Если база «тупит» только у обычных пользователей, а у администратора «летает» — причина в RLS.
Рассмотрим варианты решения:
Как упоминалось в сообщениях форума, запуск ТестированиеИИсправление (ТиИ) — палка о двух концах. Рассмотрим правильный порядок действий:
Иногда «тормоза» субъективны и связаны с кэшем конфигурации на конкретном компьютере. Проанализируем: если после обновления или разделения структуры базы кэш не очистился, формы могут открываться крайне медленно. Рекомендуем очистить папки %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8. Это заставит платформу заново считать структуру объектов и ускорит отрисовку интерфейса.
Подведем итог: Борьба с медленной работой базы — это всегда комплекс мер. Начнем с УправлениеИтогами, продолжим ОбновлениеСтатистики на SQL, и закончим ЗамерПроизводительности для выявления узких мест в коде. Только такой подход гарантирует стабильный результат.