Аудит базы 1С: проверка данных, прав и производительности

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

Минимальный набор инструментов зависит от того, как развёрнута база. Для файловой достаточно chdbfl.exe и штатного «Тестирования и исправления» в Конфигураторе. Для клиент-серверной добавляются средства SQL Server (проверка DBCC CHECKDB, бэкап через СУБД) и консоль администрирования серверов. Производительность в обоих случаях оценивают через технологический журнал и оценку APDEX.

Ниже — порядок действий, который закрывает всю базу: от физической целостности файла до анализа медленных запросов.

Подготовка: резервная копия и фиксация состояния

Первый шаг — бэкап. Для файловой базы закройте все сеансы и скопируйте файл 1Cv8.1CD целиком. Для клиент-серверной сделайте резервную копию средствами СУБД (в MS SQL — полный backup базы), а не выгрузку .dt — выгрузка не гарантирует согласованности при большой базе.

Перед проверками зафиксируйте точку отсчёта, чтобы потом было с чем сравнивать:

• 📦 размер файла базы или базы данных на СУБД;
• 👥 число активных пользователей в пике (Администрирование → Активные пользователи);
• ⏱ среднее время открытия типовых документов и проведения;
• 💾 свободное место на диске с базой и с файлом подкачки.

Если база клиент-серверная, заодно посмотрите список информационных баз кластера. В командной строке это rac infobase summary list; если не уверены в синтаксисе конкретной версии — смотрите rac help.

Проверка целостности файла на уровне хранилища

Это самый нижний слой аудита — проверка того, что сам файл или база СУБД не повреждены. Логические проверки 1С бессмысленны, пока не закрыт этот уровень.

Для файловой базы используют утилиту chdbfl.exe из каталога bin установленной платформы (например, C:\Program Files\1cv8\<номер версии>\bin). База при этом должна быть закрыта во всех сеансах.

1. Запустите chdbfl.exe.
2. Укажите путь к файлу 1Cv8.1CD.
3. Поставьте флажок «Исправлять обнаруженные ошибки» только после того, как сделали копию файла.
4. Запустите проверку и дождитесь отчёта.

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

Тестирование и исправление информационной базы

Главный штатный инструмент аудита данных — «Тестирование и исправление» в Конфигураторе: Администрирование → Тестирование и исправление. Он проверяет внутреннюю структуру базы независимо от того, файловая она или серверная.

В окне доступны отдельные проверки — включайте их по задаче:

Режимов работы два: «только тестирование» и «тестирование и исправление». Аудит всегда начинайте с первого — он ничего не меняет и показывает, что нашлось. Исправление включайте осознанно, по результатам проверки.

При проверке ссылочной целостности платформа предлагает, как поступить с битыми ссылками: создавать объекты, очищать ссылки или не изменять. Выбор зависит от причины — очистка подходит, когда объект удалён намеренно, а ссылка осталась «висеть».

Результаты проверки читайте по смыслу, а не только по итогу «найдено/исправлено». Нарушения ссылочной целостности обычно говорят о некорректных прямых удалениях в базе. Расхождение итогов — о сбое при проведении или обмене. Долгая реиндексация с большим приростом места — о том, что индексы давно не перестраивались. Каждый такой сигнал стоит довести до причины, а не просто «починить и забыть».

Аудит прав доступа и ролей

Проверка прав — обязательная часть аудита с точки зрения безопасности. Задача: убедиться, что у пользователей нет лишних полномочий, а административный доступ есть только у тех, кому он положен.

Список пользователей смотрят в двух местах. В режиме 1С:Предприятие (интерфейс «Такси») это Администрирование → Настройки пользователей и прав → Пользователи. На уровне платформы — в Конфигураторе: Администрирование → Пользователи, там же видно, у кого установлена аутентификация ОС и кто имеет роль с полными правами.

На что смотреть при аудите прав:

• 🔑 кто обладает ролью «Полные права» или «Администратор» — таких учётных записей должно быть минимум;
• 👤 нет ли активных учёток уволенных сотрудников;
• 🧩 совпадают ли профили групп доступа с реальными обязанностями;
• 🔐 включена ли проверка сложности пароля (Настройки пользователей и прав → Политика паролей);
• 🚪 не осталось ли пользователей без пароля с аутентификацией 1С.

Активные сеансы проверяют в Администрирование → Активные пользователи, а в клиент-серверном варианте — через консоль администрирования серверов или командой rac session list. Это помогает увидеть, кто реально работает в базе и не висят ли «мёртвые» сеансы.

Аудит сервера: ресурсы, служба и операционная система

Для клиент-серверной базы отдельно проверяют инфраструктуру — часто «тормоза 1С» оказываются нехваткой памяти или медленным диском, а не проблемой конфигурации.

Что проверить по серверу:

• 🧠 Память рабочих процессов. Посмотрите потребление rphost в диспетчере задач или через консоль администрирования. Если процесс упирается в лимит и часто перезапускается — это видно по журналу и по обрывам сеансов.
• 💽 Дисковая подсистема. База и tempdb SQL должны лежать на быстрых дисках. Проверьте очередь к диску и свободное место — переполнение диска с базой приводит к аварийному завершению.
• ⚙️ Служба сервера 1С и агент SQL. Убедитесь, что служба 1C:Enterprise Server запущена от корректной учётной записи, а регламентные задания СУБД (бэкап, обновление статистики) выполняются. Устаревшая статистика SQL — частая причина внезапных замедлений: оптимизатор строит плохой план запроса.
• 🖥 Операционная система. Актуальные обновления, правильно настроенный файл подкачки, антивирус с исключениями для каталогов 1С и файлов базы.

Размер кластера и его рабочие процессы можно посмотреть командой rac cluster list и далее по процессам; точный набор подкоманд для вашей версии платформы уточняйте через rac help, чтобы не опираться на устаревший синтаксис.

Анализ производительности и медленных запросов

Производительность оценивают не «на глаз», а по двум штатным механизмам: оценке APDEX и технологическому журналу.

Оценка производительности (APDEX) включается в конфигурации в разделе Администрирование → Обслуживание → Оценка производительности (точный путь зависит от конфигурации — ориентир даёт поиск по форме настроек). Механизм измеряет время ключевых операций и сводит их в индекс от 0 до 1: чем ближе к 1, тем лучше. Операции с индексом ниже целевого — первые кандидаты на разбор.

Технологический журнал собирает низкоуровневые события платформы. Его настраивают файлом logcfg.xml в каталоге conf платформы. Для поиска медленных запросов включают события обращения к СУБД и задают порог длительности — в журнал попадут только долгие запросы.

Типовой порядок анализа производительности:

1. Снимите оценку APDEX за рабочий день и найдите операции ниже порога.
2. Включите технологический журнал с фильтром по длительности на время воспроизведения проблемы.
3. Найдите в журнале самые долгие запросы и операции ожидания на блокировках.
4. По тексту запроса определите проблемный объект: отчёт, проведение документа, обмен.
5. Проверьте индексы и объёмы соответствующих таблиц.

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

Отдельно обратите внимание на управляемые блокировки: длинные ожидания в технологическом журнале часто говорят не о медленном железе, а о конкуренции документов за одни и те же данные. Если несколько пользователей одновременно проводят документы, затрагивающие один регистр, они встают в очередь — и это видно именно по событиям ожидания на блокировках, а не по загрузке процессора.

Журнал регистрации: кто и что менял

Журнал регистрации — инструмент аудита действий пользователей. Он отвечает на вопросы «кто провёл документ», «кто изменил настройку», «когда был сбой».

Откройте его в режиме 1С:Предприятие: Администрирование → Журнал регистрации. Для аудита полезны фильтры:

• 🔴 по важности «Ошибка» — технические сбои и аварийные завершения;
• 👤 по конкретному пользователю — что делал за период;
• 📄 по объекту или событию — кто менял критичный справочник или документ;
• 🕐 по дате и времени — что происходило в момент сбоя.

Если журнал разросся, его можно сократить регламентом, но для аудита важно, чтобы глубина хранения покрывала проверяемый период. Проверьте настройку хранения заранее — удалённые записи восстановить нельзя.

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