Разбор информационной базы 1С 8.3 по шагам: журнал, блокировки, таблицы, индексы

Проанализировать базу 1С — значит последовательно проверить четыре слоя: журнал регистрации и технологический журнал (что падает), замер производительности (что тормозит), блокировки (кто кого ждёт) и физическую структуру в СУБД (размер таблиц, индексы, статистика). Начинать стоит с технологического журнала: в нём остаются ошибки, длинные запросы и конфликты блокировок с точным временем и пользователем.

Типичная ситуация: главбух жалуется, что «проведение реализации с утра идёт по минуте, а вчера было мгновенно». Без анализа ответ один — «перезагрузим сервер». С анализом через полчаса видно, что виноват регламентный обмен, который держит блокировку на регистре взаиморасчётов. Порядок работы эксперта как раз и переводит разговор из догадок в факты.

Подготовка к анализу базы 1С: что собрать до первого замера

Анализ без исходных данных превращается в гадание. До того как что-то включать, зафиксируйте картину.

📌 Что записать:

• точный симптом: какая операция, у каких пользователей, во сколько, сколько секунд;
• вариант работы: файловая база или клиент-серверная, какая СУБД (MS SQL Server, PostgreSQL);
• номер платформы (Справка → О программе) и релиз конфигурации;
• число активных пользователей в момент проблемы;
• что менялось накануне: обновление, новая доработка, перенос на другой сервер, включение обмена.

📌 Какие права нужны:

• администратор информационной базы — для журнала регистрации и замеров;
• доступ к каталогу установки платформы на сервере 1С — для технологического журнала;
• доступ к СУБД с правом чтения системных представлений — для анализа индексов.

Отдельно договоритесь, где будет лежать технологический журнал. За час активной работы с полным набором событий он легко вырастает до гигабайтов, поэтому нужен диск с запасом и не системный.

Инструменты анализа: от встроенных в 1С до профессиональных

Под каждую задачу — свой инструмент. Ни один из них не закрывает всё сразу.

💡 Для файловой базы набор беднее: консоли кластера и СУБД нет, зато есть утилита chdbfl.exe в каталоге bin платформы. Она проверяет физическую целостность файла 1Cv8.1CD, но запускать её можно только когда в базе никто не работает .

Технологический журнал 1С: как включить и найти критичные ошибки

Технологический журнал включается файлом logcfg.xml. Его кладут в каталог conf установленной платформы, например C:\Program Files\1cv8\conf\. Платформа перечитывает настройку сама, перезапускать службу не нужно: запись начинается примерно через минуту.

Рабочий минимальный конфиг для поиска ошибок, долгих запросов и проблем с блокировками:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <gt property="duration" value="1000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Что здесь важно:

• 🔹 history="24" — журнал хранится 24 часа, старые файлы удаляются автоматически;
• 🔹 duration в платформе 8.3 задаётся в микросекундах, поэтому 1000000 — запросы дольше одной секунды;
• 🔹 EXCP — исключения, TTIMEOUT — превышение времени ожидания блокировки, TDEADLOCK — взаимоблокировка;
• 🔹 событие DBMSSQL пишется для MS SQL Server, DBPOSTGRS — для PostgreSQL; лишнее можно убрать.

Не оставляйте полный журнал включённым на неделю — он забьёт диск и сам станет причиной торможения. Собрали материал за проблемный период — переименуйте logcfg.xml или удалите его.

Как читать технологический журнал

Каждый процесс пишет в свой подкаталог (rphost_1234, rmngr_5678), внутри — файлы по часам вида 26100709.log. Строка начинается со времени и длительности, дальше идёт имя события и свойства.

Быстрый поиск без специальных программ:

:: все исключения за период
findstr /s /c:",EXCP," D:\techlog\*.log > excp.txt

:: все взаимоблокировки
findstr /s /c:",TDEADLOCK," D:\techlog\*.log > deadlocks.txt

На Linux то же самое делает grep -r ",EXCP," /var/techlog > excp.txt.

В найденных строках смотрите свойства Usr (пользователь), Context (стек вызовов встроенного языка) и Descr (текст ошибки). Именно Context показывает модуль и строку, где упало.

💡 Для больших объёмов удобнее разбор скриптом: сгруппировать события DBMSSQL по контексту и сложить длительности. Пять-шесть контекстов, которые дают основную сумму времени, — это и есть список задач на оптимизацию.

Диагностика производительности: ищем узкое место

Когда медленная операция известна, переходите к замеру производительности. Он показывает, какая строка кода сколько времени заняла.

Пошагово: замер в конфигураторе

1. Откройте базу в конфигураторе и запустите её в режиме отладки (F5).
2. В конфигураторе включите замер: меню Отладка → Замер производительности.
3. В пользовательском режиме выполните проблемную операцию, например проведите документ.
4. Снова выберите Отладка → Замер производительности — замер остановится, откроется результат.
5. Отсортируйте строки по проценту времени. Двойной щелчок по строке открывает модуль на этом месте.

Строка, которая забирает 60–80% времени, почти всегда оказывается одним из трёх: запрос в цикле, обращение через точку к реквизитам ссылки (Документ.Контрагент.ИНН внутри перебора) или запрос без условий по индексируемым полям.

Если замер не показывает виновника

Бывает, что код быстрый, а операция всё равно долгая. Тогда время уходит вне кода:

• ⏳ ожидание блокировки — ищите TTIMEOUT и TLOCK в технологическом журнале;
• 🗄️ медленный запрос на стороне СУБД — смотрите план запроса в средствах СУБД;
• 🌐 сеть между клиентом и сервером — сравните время той же операции, запущенной на самом сервере;
• 💾 диск — проверьте очередь диска на сервере СУБД в момент проблемы.

Для постоянного наблюдения включите подсистему оценки производительности. В типовых конфигурациях на БСП её флажок находится в Администрирование → Обслуживание. Она копит время ключевых операций и считает индекс APDEX. Падение индекса с 0,9 до 0,7 за неделю — повод разбираться до того, как пожалуются пользователи.

Блокировки и взаимоблокировки: как выявить и снять причину

Классический текст ошибки, с которым приходят пользователи:

Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки

Это значит: одна транзакция держит данные, вторая ждёт и по истечении таймаута падает.

Как найти, кто держит блокировку

1. В технологическом журнале найдите событие TTIMEOUT — у него есть свойство WaitConnections с номерами соединений, которые мешали.
2. По номеру соединения в событиях TLOCK того же времени найдите контекст — код, который захватил блокировку.
3. Посмотрите свойство Regions — какое пространство блокировок (регистр, справочник) стало предметом конфликта.

Для взаимоблокировок (TDEADLOCK) то же самое: в свойстве DeadlockConnectionIntersections перечислены пары соединений и ресурсы, на которых они сцепились.

💡 Для сбора TLOCK добавьте в logcfg.xml отдельный блок <event> с этим именем, но включайте его коротким окном — событие очень частое.

Что обычно оказывается причиной

Анализ структуры базы данных: размер таблиц, фрагментация и индексы

В клиент-серверной базе часть проблем живёт не в 1С, а в СУБД: разросшиеся таблицы, фрагментированные индексы, устаревшая статистика.

Какие таблицы занимают место

Таблицы в СУБД называются техническими именами: _AccumRg123, _InfoRg45, _Document67. Чтобы сопоставить их с объектами конфигурации, в 1С есть метод встроенного языка ПолучитьСтруктуруХраненияБазыДанных(). Он возвращает таблицу с колонками «ИмяТаблицыХранения» и «ИмяТаблицы».

Размер таблиц в MS SQL Server:

SELECT TOP 20
    t.name AS table_name,
    SUM(p.rows) AS rows_count,
    SUM(a.total_pages) * 8 / 1024 AS size_mb
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id AND p.index_id IN (0,1)
JOIN sys.allocation_units a ON p.partition_id = a.container_id
GROUP BY t.name
ORDER BY size_mb DESC;

Частая находка — огромные таблицы регистрации изменений с окончанием ChngR. Это значит, что обмен с каким-то узлом давно не работает, а изменения для него копятся. Помогает восстановить обмен или удалить неиспользуемый узел плана обмена.

Фрагментация индексов в MS SQL Server

SELECT OBJECT_NAME(s.object_id) AS table_name,
       i.name AS index_name,
       s.avg_fragmentation_in_percent,
       s.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') s
JOIN sys.indexes i ON s.object_id = i.object_id AND s.index_id = i.index_id
WHERE s.page_count > 1000 AND s.avg_fragmentation_in_percent > 10
ORDER BY s.avg_fragmentation_in_percent DESC;

Ориентир из рекомендаций Microsoft:

Маленькие индексы (до 1000 страниц) не трогайте: у них высокий процент фрагментации ни на что не влияет.

Статистика и PostgreSQL

Устаревшая статистика ломает планы запросов сильнее, чем фрагментация. В MS SQL обновить её по всей базе можно командой EXEC sp_updatestats;.

В PostgreSQL смотрите «мёртвые» строки, которые копятся после изменений:

SELECT relname, n_live_tup, n_dead_tup, last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

Если у крупных таблиц n_dead_tup сопоставим с n_live_tup, а last_autovacuum пустой или старый, автоочистка не справляется. Тогда выполняют VACUUM ANALYZE по таблице и пересматривают настройки autovacuum.

Логическая целостность

Структура данных в СУБД может быть в порядке, а внутри 1С — битые ссылки и неверные итоги. Для этого в конфигураторе есть Администрирование → Тестирование и исправление. Флажки «Проверка логической целостности», «Проверка ссылочной целостности» и «Пересчёт итогов» закрывают большую часть случаев. Режим требует монопольного доступа — все пользователи должны выйти.

Регулярный мониторинг и автоматизация анализа

Разовый анализ находит проблему. Регулярный — ловит её раньше, чем пользователи.

📊 Что поставить на расписание:

• обслуживание индексов и статистики — задание SQL Server Agent или план обслуживания раз в неделю, ночью;
• для PostgreSQL — контроль autovacuum и еженедельный ANALYZE крупных таблиц;
• архивирование и отправку журнала регистрации, если он разросся;
• выгрузку показателя APDEX и сравнение с прошлой неделей.

🔔 Какие события делать триггерами для оповещения:

• появление TDEADLOCK в технологическом журнале;
• более N событий TTIMEOUT за час (порог подберите по своей базе, например 10);
• запросы к СУБД дольше 30 секунд;
• рост размера базы больше чем на 10% за сутки;
• остаток места на диске с журналами меньше 20%.

Для технологического журнала на постоянной основе оставляют облегчённый конфиг: только EXCP, TDEADLOCK, TTIMEOUT и запросы дольше нескольких секунд. Такой журнал весит в разы меньше и не мешает работе.

Простейшая автоматизация — скрипт по расписанию, который раз в час ищет TDEADLOCK в свежих файлах и отправляет письмо или сообщение в мессенджер. Для крупных баз удобнее связка сбора журналов в систему анализа логов и дашборд с графиками.

Ошибки, которые искажают результат анализа

• ❌ Анализ на тестовой копии без нагрузки. Блокировки и конкуренция за ресурсы проявляются только при одновременной работе. На пустой копии виден лишь медленный код.
• ❌ Журнал без фильтра по длительности. Тысячи быстрых запросов прячут несколько медленных. Фильтр duration обязателен.
• ❌ Перестроение всех индексов подряд. Время уходит на маленькие таблицы, а сервер получает нагрузку без пользы.
• ❌ Вывод по одному замеру. Первое выполнение медленнее из-за пустого кэша. Замеряйте операцию 2–3 раза.
• ❌ Поиск виновника по жалобе, а не по журналу. Жалуется тот, кто ждёт, а не тот, кто держит блокировку.

Частые вопросы