CommonSettings в 1С: что это за таблица и зачем она нужна

CommonSettings — это системная таблица информационной базы 1С:Предприятие, в которой платформа хранит общие настройки, не привязанные к конкретному пользователю или объекту метаданных. Администраторы чаще всего сталкиваются с ней при работе с базой на SQL Server, PostgreSQL или в файловом варианте через структуру хранения, а также при диагностике ошибок вида «Ошибка СУБД» или при анализе неожиданно разросшихся таблиц.

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

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

Что именно хранится в таблице CommonSettings

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

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

Как найти таблицу в базе и оценить её размер

В клиент-серверном варианте таблица видна в списке объектов базы данных под именем, содержащим CommonSettings (точное имя зависит от схемы именования платформы). В файловом варианте таблица находится внутри файла 1Cv8.1CD, и увидеть её можно только через инструменты просмотра структуры хранения или косвенно — через рост размера файла.

Первый признак проблем — аномальный рост таблицы. Если база на SQL Server, размер конкретной таблицы проверяется стандартным отчётом по размерам таблиц в SQL Server Management Studio (отчёт «Disk Usage by Table») или запросом к системным представлениям. Рост в сотни мегабайт и гигабайты для CommonSettings — повод разбираться, что именно туда пишет конфигурация.

SELECT t.NAME AS TableName, SUM(a.total_pages) * 8 AS SizeKB FROM sys.tables t JOIN sys.indexes i ON t.object_id = i.object_id JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id JOIN sys.allocation_units a ON p.partition_id = a.container_id WHERE t.NAME LIKE '%CommonSettings%' GROUP BY t.NAME

Почему таблица разрастается и чем это опасно

Наиболее частые причины раздувания CommonSettings: накопление записей очередей обмена данными, неочищенные кэши, ошибки в коде конфигурации, который циклически пишет данные без удаления старых, а также «зависшие» данные отложенных обработчиков обновления, которые не смогли завершиться. В некоторых случаях виноваты регламентные задания, которые при каждом запуске добавляют новую порцию записей.

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

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

Правильная последовательность начинается с диагностики: сначала определите, какой механизм пишет данные. Для этого полезно посмотреть, связаны ли записи с планами обмена (проверьте очереди сообщений обмена), с отложенным обновлением (проверьте прогресс обновления в консоли отложенных обработчиков) или с конкретным регламентным заданием.

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

1. 1
   Сделайте резервную копию базы (выгрузку dt или бэкап СУБД)
2. 2
   Определите размер таблицы и динамику роста
3. 3
   Найдите источник записей: обмены, отложенное обновление, регламентные задания
4. 4
   Выполните штатную очистку через интерфейс конфигурации
5. 5
   Проверьте размер повторно и убедитесь, что рост остановлен
6. 6
   Если рост продолжается — анализируйте код, пишущий в общие настройки

Типичные ошибки администраторов

Самая распространённая ошибка — попытка «почистить» таблицу напрямую в SQL без анализа содержимого. Даже если база после этого запускается, часть механизмов (обмены, обновление, версионирование) может начать вести себя некорректно, и причина будет неочевидна.

Вторая ошибка — игнорирование первопричины: администратор очищает таблицу, она снова растёт, цикл повторяется. Очистка без устранения источника записей (зависшего обмена, ошибочного задания) не решает проблему. Третья ошибка — работа без резервной копии: даже штатная очистка на рабочей базе требует бэкапа.

Чем CommonSettings отличается от других таблиц настроек

В структуре базы 1С есть несколько похожих по назначению таблиц, и их часто путают. Пользовательские настройки отчётов, вариантов и форм хранятся отдельно и привязаны к конкретным пользователям; системные таблицы параметров сеанса и соединений вообще обслуживают работу сервера. CommonSettings занимает нишу общих, межпользовательских данных конфигурации.

Как проверить, что проблема решена

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

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

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