Каждый администратор баз данных или программист 1С рано или поздно сталкивается с загадочным поведением отчетов. Одной из самых частых и неприятных проблем является внезапное зависание отчета «Оборотно-сальдовая ведомость по счету» (ОСВ) при попытке сформировать его за определенный период. При этом складывается парадоксальная ситуация: отчет за полный месяц формируется мгновенно, смежные отчеты (например, «Карточка счета» или «Анализ счета») за этот же "проблемный" период открываются без каких-либо задержек, но стоит выбрать в ОСВ интервал внутри месяца (например, с 1 по 15 число) — и система намертво зависает.
В этой статье мы подробно и пошагово разберем, почему возникает эта проблема, чем отличается логика работы разных бухгалтерских отчетов с точки зрения СУБД, и как реанимировать работу системы с помощью различных инструментов диагностики: от ручной локализации до анализа технологического журнала и оптимизации SQL-сервера.
Прежде чем переходить к практическим действиям, давайте проанализируем внутреннее устройство платформы 1С и поймем физическую разницу между этими отчетами. Это поможет нам осознать, где именно происходит сбой.
Отчет КарточкаСчета работает напрямую с таблицей движений регистра бухгалтерии (основная таблица проводок). Ему не нужно агрегировать и группировать данные за весь период. Он последовательно выбирает записи, упорядоченные по времени и регистратору, и выводит их на экран. Запрос получается линейным и простым для оптимизатора СУБД.
Отчет ОборотноСальдоваяВедомостьПоСчету устроен иначе. Для его формирования платформа обращается к сложной виртуальной таблице ОстаткиИОбороты регистра бухгалтерии. Чтобы выдать начальный остаток, обороты за период в разрезе субконто и конечный остаток, СУБД выполняет соединение нескольких физических таблиц: таблицы реальных движений, таблицы итогов (которая хранит рассчитанные остатки на начало каждого месяца) и таблиц субконто (справочников). Если в этих таблицах нарушена логическая целостность, повреждены индексы или СУБД выбирает неоптимальный план выполнения запроса, происходит лавинообразное падение производительности, перерастающее в "вечное" ожидание ответа от сервера.
---
Если зависание происходит только на определенном отрезке времени, наша первоочередная задача — максимально сузить этот интервал. Самый простой и быстрый способ сделать это без привлечения сложных инструментов — метод половинного деления (дихотомии).
Рассмотрим этот алгоритм по шагам:
Этот метод позволяет быстро понять, связано ли зависание с конкретным документом (например, некорректно проведенной транзакцией, которая «сломала» итоги конкретного дня) или же проблема носит глобальный системный характер (когда зависает абсолютно любой день внутри месяца).
---
Если ручной поиск не дал результатов и отчет виснет на любом произвольном интервале, нам необходимо заглянуть "под капот" взаимодействия платформы 1С и СУБД. Для этого мы настроим Технологический журнал (ТЖ).
Наша цель — поймать тяжелый SQL-запрос, который отправляет платформа при формировании ОСВ, и зафиксировать его длительность. Для этого выполним следующие действия:
C:\Program Files\1cv8\conf для 64-битной версии) создадим текстовый файл с именем logcfg.xml.DBMSSQL или DBPOSTGRS в зависимости от вашей СУБД) и запросы на уровне платформы (SDBL). Установим порог фиксации, например, более 10 секунд (10 000 000 микросекунд):
Убедитесь, что у пользователя, под которым запускается служба сервера 1С:Предприятия, есть полные права на запись в каталог C:\v8_logs\db_queries. После создания файла конфигурации перезапускать службу сервера не требуется — платформа считывает изменения файла logcfg.xml автоматически в течение минуты.
Теперь воспроизведем ошибку: запустим формирование ОСВ за проблемный период, дождемся зависания, снимем сеанс через консоль администрирования или диспетчер задач и откроем сформированные файлы логов в каталоге C:\v8_logs\db_queries. Ищем в файлах лога записи с наибольшей длительностью Duration. Там мы увидим точный SQL-текст запроса. Обратите внимание на имена таблиц, которые фигурируют в запросе (например, таблицы с префиксами _AccRg) — именно они требуют нашего внимания.
---
Очень часто причиной того, что ОСВ за весь месяц строится быстро, а за часть месяца зависает, является механизм Parameter Sniffing (чувствительность к параметрам) в СУБД (MS SQL Server или PostgreSQL).
Когда отчет ОСВ запускается впервые (например, за весь месяц), оптимизатор SQL-сервера анализирует переданные параметры дат, строит под них оптимальный план выполнения (например, использует поиск по индексам — Index Seek) и кэширует его. При последующих запусках отчета, но уже за другие даты (например, с 1 по 14 число), СУБД пытается применить тот же самый кэшированный план. Однако из-за изменения диапазона дат этот план становится катастрофически неэффективным, и вместо быстрого поиска по индексам СУБД начинает построчное сканирование всей многомиллионной таблицы регистра (Table Scan / Index Scan), что приводит к зависанию.
Чтобы решить эту проблему, выполним комплекс мероприятий по обслуживанию СУБД:
USE [Имя_Вашей_Базы_Данных];
GO
EXEC sp_updatestats;
GO
_AccRg0123):
UPDATE STATISTICS _AccRg0123 WITH FULLSCAN;
DBCC FREEPROCCACHE;
---
Если СУБД работает корректно, а статистика обновлена, но зависание продолжается, велика вероятность физического или логического повреждения таблиц итогов регистра бухгалтерии. Такое случается при аварийном завершении работы сервера, сбоях сетевого оборудования во время транзакций или некорректно выполненных обменах данными.
Обычное перепроведение документов в режиме Предприятия здесь не поможет, так как оно не пересчитывает саму структуру таблиц итогов. Нам необходимо прибегнуть к системным процедурам.
Выполним тестирование и исправление базы данных по следующему алгоритму:
Реиндексация таблиц информационной базы (помогает перестроить разрушенные индексы СУБД);Проверка логической целостности (находит некорректные связи между таблицами);Проверка ссылочной целостности (выявляет "битые" ссылки и пустые GUID);Пересчет итогов (полностью очищает таблицы сохраненных итогов регистра бухгалтерии и рассчитывает их заново на основе реальных проводок документов).Очищать ссылки (или Создавать объекты на усмотрение администратора для последующего разбора причин).Если база данных файловая или небольшого объема, отличным альтернативным решением будет полная перевыгрузка базы через файл резервной копии .dt. В процессе импорта файла .dt платформа 1С автоматически перестраивает индексы и физически пересчитывает все итоги с нуля, что часто решает проблему зависания без дополнительных усилий.
---
Иногда корень проблемы лежит на самой поверхности и не связан с базой данных или СУБД. Поскольку зависает только один конкретный отчет (ОСВ по конкретному счету), велика вероятность повреждения сохраненных пользовательских настроек этого отчета. Система компоновки данных (СКД), на которой построена ОСВ, сохраняет пользовательские отборы, группировки и условное оформление в системные таблицы базы данных. Если эти настройки записались с ошибкой, при попытке рендеринга (вывода) таблицы на экран платформа уходит в бесконечный цикл.
Для исправления ситуации выполним сброс настроек:
Администрирование — Настройки пользователей и прав — Очистка настроек. Найдем проблемного пользователя, выберем отчет «Оборотно-сальдовая ведомость по счету» и удалим все его сохраненные настройки.Также не стоит забывать про локальный кэш конфигурации на компьютере пользователя. Повреждение файлов локального кэша часто вызывает необъяснимые зависания интерфейса. Для полной очистки кэша достаточно удалить базу из списка в стартере 1С и добавить её заново под тем же путем подключения.
---
Еще один важный аспект, который мы должны проанализировать — это права доступа. Ограничение доступа на уровне записей (RLS — Record Level Security) заставляет платформу модифицировать исходный SQL-запрос, накладывая на него дополнительные условия (например, фильтрацию по разрешенным организациям, складам или группам доступа контрагентов).
Если отчет зависает у обычного пользователя, проведем простой эксперимент: сформируем этот же отчет за абсолютно аналогичный "проблемный" период под учетной записью с Полными правами (Администратор).
Если под Администратором отчет формируется за секунды, а под рядовым пользователем зависает — дело гарантированно в механизме RLS. В данном случае необходимо оптимизировать правила ограничения доступа в конфигурации или пересмотреть структуру прав пользователя (например, временно отключить избыточные ограничения для проверки производительности).
---
Мы подробно разобрали, как локализовать и устранить зависание ОСВ в 1С. Решение подобных проблем требует комплексного подхода. Сначала мы локализуем проблему во времени методом половинного деления, затем проверяем самые простые гипотезы (кэш настроек и локальный кэш платформы), после чего переходим к системным действиям: пересчету итогов через тестирование и исправление и оптимизации работы СУБД (обновление статистики и очистка кэша планов запросов). Использование этих методов гарантированно вернет работоспособность вашим отчетам и обеспечит стабильную работу пользователей в системе.