Часто возникает ситуация, когда после переноса базы 1С:Бухгалтерия с файлового варианта на SQL-сервер, стандартные операции, такие как групповое перепроведение документов, начинают выполняться недопустимо долго или "зависают" на несколько часов. При этом в файловом режиме та же операция могла занимать всего 10-15 минут. Давайте подробно разберем, почему это происходит и как диагностировать и устранить проблему.
Проанализируем типичный сценарий: база не очень большая, около 3000 документов за месяц, на том же сервере работают другие базы без нареканий, но именно эта конкретная база "висит" при массовой обработке. Это указывает не на общую слабость сервера, а на проблему, специфичную для этой информационной базы или настроек её взаимодействия с СУБД. Грамотная оптимизация работы 1С на SQL позволяет избежать таких ситуаций.
Первое, что нужно сделать, — это понять, что на самом деле происходит в момент "зависания". Фраза "сервер загружен меньше чем на четверть" может быть обманчивой. Общая загрузка процессора (CPU) может быть низкой, но это не исключает узких мест.
Анализ загрузки по ядрам процессора. Откройте диспетчер задач (или более продвинутый монитор ресурсов) на сервере и посмотрите на загрузку каждого ядра CPU. Если вы видите, что один из процессорных потоков (например, рабочий процесс сервера 1С rphost.exe) утилизирует одно ядро на 100%, а остальные простаивают, — это явный признак "однопоточного" узкого места. Для более глубокого мониторинга состояния системы и управления процессами можно использовать детализированный менеджер задач 1С, который позволяет видеть детальные параметры баз и владельцев процессов.
Мониторинг дисковой подсистемы. Проверьте активность дисков. Высокая нагрузка на диски может свидетельствовать о нехватке оперативной памяти (и активном использовании файла подкачки) или о неоптимальных запросах, которые заставляют SQL-сервер считывать с диска огромные объемы данных.
Анализ журнала регистрации 1С. В момент зависания посмотрите в журнал регистрации. Если, как в описанном случае, там в течение часов не появляется никаких новых записей, это может говорить о выполнении одной очень длинной транзакции. В таких ситуациях профессиональный замер производительности контура 1С и поиск узких мест поможет выявить причину, по которой система "замерла" в ожидании завершения операции.
Проверка стабильности рабочих процессов. Убедитесь, что рабочий процесс rphost.exe, обслуживающий сеанс, не перезапускается циклически. Если процесс падает и перезапускается, со стороны пользователя это может выглядеть как зависание.
Отсутствие регулярного обслуживания базы данных на стороне SQL-сервера — основная причина деградации производительности 1С в клиент-серверном варианте. В файловом режиме платформа 1С сама управляет структурой данных, а в SQL этим должен заниматься администратор СУБД. Если этого не делать, база данных "захламляется". Предварительно стоит провести расчет размера таблиц базы данных, чтобы понять, какие именно объекты метаданных занимают больше всего места и требуют особого внимания при обслуживании.
Критически важно настроить и регулярно выполнять два вида операций:
Обновление статистики (Update Statistics). Статистика — это информация о распределении данных в таблицах. SQL-сервер использует её, чтобы выбрать наилучший способ выполнения запроса (например, какой индекс использовать, в каком порядке соединять таблицы). Со временем данные меняются, статистика устаревает, и сервер может выбрать катастрофически медленный план запроса. Поэтому обновлять статистику нужно регулярно, для активно меняющихся баз — ежедневно.
Реиндексация и дефрагментация индексов (Rebuild/Reorganize Index). Индексы ускоряют поиск данных. Из-за постоянных вставок, обновлений и удалений данных индексы фрагментируются — их структура становится неоптимальной, и поиск замедляется. Регулярная (например, еженедельная) реиндексация приводит индексы в порядок.
Как это сделать? В MS SQL Server Management Studio для этого существуют Планы обслуживания (Maintenance Plans). Создайте план, который будет автоматически по расписанию выполнять задачи обновления статистики и реорганизации/перестроения индексов для вашей базы 1С. Это первый и самый важный шаг к стабильной работе.
Групповое перепроведение документов в 1С выполняется в рамках одной большой транзакции. Это значит, что система сначала "захватывает" все необходимые для изменения таблицы, вносит в них все изменения, и только в самом конце фиксирует результат. Если документов много, такая транзакция может длиться очень долго и блокировать огромное количество ресурсов.
Здесь может возникнуть проблема эскалации блокировок. Когда одна операция накладывает слишком много блокировок на отдельные строки, SQL-сервер для экономии памяти может "укрупнить" их до блокировки всей таблицы. Если это произойдет с ключевой таблицей (например, с таблицей итогов регистра бухгалтерии), вся дальнейшая работа с ней в других сеансах остановится, что и будет выглядеть как полное зависание системы.
Для поиска таких проблем главным инструментом является Технологический журнал (ТЖ) 1С. Настроив сбор событий SDBL (длительные запросы к БД) и TLOCK (ожидания на блокировках), вы сможете точно определить, на каком запросе система "спотыкается" и какие объекты блокируются.
Даже при идеально настроенном SQL-сервере, массовые операции можно и нужно оптимизировать средствами самой платформы 1С. Это не только ускорит процесс, но и снизит нагрузку на сервер.
Рассмотрим два основных подхода:
Временное отключение итогов регистров. При проведении документа система не только записывает данные в таблицы движений, но и сразу пересчитывает итоги в таблицах итогов. Этот пересчет — ресурсоемкая операция. Для ускорения массового перепроведения можно использовать метод управления итогами регистров:
Пример программного управления итогами:
// Отключение итогов для регистра накопления "Продажи"
РегистрыНакопления.Продажи.УстановитьИспользованиеИтогов(Ложь);
// ... здесь код массового перепроведения документов ...
// Включение итогов и запуск пересчета
РегистрыНакопления.Продажи.УстановитьИспользованиеИтогов(Истина);
Порционное перепроведение. Вместо того чтобы запускать перепроведение сразу 3000 документов за месяц, разбейте задачу на части. Перепроводите документы по дням или по неделям. Это приведет к созданию нескольких небольших транзакций вместо одной гигантской. В этом поможет универсальная обработка для перепроведения документов, позволяющая гибко настраивать периоды. А если стоит задача восстановить последовательность в крупной базе БП 3.0, стоит рассмотреть автоматическое фоновое восстановление последовательности в многопоточном режиме, что кардинально ускоряет процесс за счет параллельной обработки данных.
Проблема "зависания" при перепроведении документов на SQL — комплексная, но решаемая. Проанализировав ситуацию, составим четкий план действий:
Следование этим шагам поможет не только решить текущую проблему, но и обеспечить стабильную и быструю работу вашей 1С в клиент-серверном режиме в будущем.