Приветствуем вас, уважаемые коллеги! При администрировании и обслуживании информационных баз «1С:Предприятие» системные администраторы и программисты нередко сталкиваются с ситуацией, когда штатный процесс резервного копирования прерывается критической ошибкой. Одной из наиболее коварных и распространенных проблем является ошибка следующего вида: «Нарушение целостности информационной базы. Ошибка в размере файла ХХХХХ-ХХХХ-ХХХХ-хххх.pfl при выгрузке таблицы files. Ожидаемое значение 0, а значение в таблице 123456».
Данная неполадка полностью блокирует возможность создания файла резервной копии (формата .dt), что ставит под угрозу регулярность бэкапов и безопасность данных. В этой статье мы подробно разберем природу этого сбоя, выясним причины его возникновения и рассмотрим пошаговые практические методы его устранения как для файлового, так и для клиент-серверного вариантов работы информационной базы.
Для того чтобы эффективно решить проблему, нам необходимо понимать, с чем именно мы имеем дело. Внутренняя структура базы данных «1С:Предприятие» (будь то файловая база 1Cv8.1CD или таблицы в СУБД MS SQL/PostgreSQL) содержит служебные таблицы. Одной из ключевых системных таблиц является таблица Files (в некоторых случаях — Params).
В этой таблице платформа хранит различные служебные файлы конфигурации, внешние обработки, а также профили настроек пользователей — файлы с расширением .pfl (User Profiles). Имя такого файла (например, 0070d942-3a6c-43e2-a265-b76c6943d100.pfl) представляет собой уникальный идентификатор (GUID) конкретного пользователя в списке пользователей информационной базы.
Внутри таблицы Files для каждого объекта заведено несколько полей, среди которых для нас критически важны два поля:
Рассогласование возникает тогда, когда значение в колонке DataSize перестает соответствовать фактическому размеру бинарных данных, хранящихся в BinaryData. Чаще всего в бинарном поле данные оказываются пустыми (размер равен 0), в то время как в служебном поле размера по-прежнему записано старое ненулевое значение (например, 123456). Платформа 1С, начиная с релиза 8.3.7, выполняет строгую валидацию соответствия этих параметров перед выгрузкой в .dt. Если обнаруживается расхождение, процесс мгновенно прерывается ошибкой нарушения целостности.
Давайте проанализируем, почему корректная до определенного момента база внезапно начинает выдавать подобную ошибку. Выделим основные технологические причины:
1cv8.exe через Диспетчер задач, СУБД может не успеть корректно закрыть транзакцию записи файла профиля.Files и Params.Перейдем к практическому рассмотрению способов исправления этой ошибки. Мы подготовили несколько вариантов решения, от самых простых и безопасных до продвинутых низкоуровневых операций.
Прежде чем приступать к сложным хирургическим операциям над таблицами базы данных, мы рекомендуем воспользоваться самым простым решением — обновлением технологической платформы. Фирма «1С» со временем признала наличие системной проблемы с файлами настроек и доработала механизмы проверки и исправления ошибок.
Как показывает практика администрирования, переход на стабильные релизы платформы (начиная с версий 8.3.9.2033, 8.3.10 и выше) во многих случаях автоматически решает эту проблему. Более новые версии платформы научились корректно обрабатывать или игнорировать незначительные расхождения в служебных файлах настроек пользователей при выгрузке базы. Просто установите актуальный релиз платформы, запустите базу в режиме Конфигуратора и попробуйте выполнить выгрузку заново.
Если обновление платформы не помогло или у вас нет возможности оперативно сменить версию платформы, мы можем пойти путем очистки поврежденных профилей. Поскольку файлы .pfl — это всего лишь настройки окон, отчетов и интерфейса, их удаление абсолютно безопасно для учетных данных (проводки, документы и справочники останутся нетронутыми). Единственный побочный эффект — у пользователей сбросятся индивидуальные настройки внешнего вида панелей и сохраненные варианты отчетов.
Для того чтобы очистить кэш настроек, мы можем воспользоваться встроенным языком 1С.
Для реализации этого способа мы можем создать простую внешнюю обработку и запустить в ней следующий код:
МассивПользователей = ПользователиИнформационнойБазы.ПолучитьПользователей();
Для Каждого ТекущийПользователь Из МассивПользователей Цикл
Сообщить("Выполняется очистка настроек для пользователя: " + ТекущийПользователь.Имя);
ОчиститьНастройкиПользователя(ТекущийПользователь);
КонецЦикла;
Сообщить("Очистка завершена. Попробуйте выполнить выгрузку базы.");
Если база данных насчитывает сотни пользователей, сбрасывать настройки всем сотрудникам крайне нежелательно. Мы можем идентифицировать конкретного «виновника» по уникальному идентификатору (GUID), указанному в тексте ошибки.
Предположим, в тексте ошибки фигурирует имя файла: 071523a4-516f-4fce-ba4b-0d11ab7a1893.pfl. Данный буквенно-цифровой код — это и есть GUID пользователя. Напишем код для точечного удаления:
ИмяФайлаPFL = "071523a4-516f-4fce-ba4b-0d11ab7a1893"; // Вставляем GUID из вашей ошибки
Попытка
УникальныйИд = Новый УникальныйИдентификатор(ИмяФайлаPFL);
ПроблемныйПользователь = ПользователиИнформационнойБазы.НайтиПоУникальномуИдентификатору(УникальныйИд);
Если ПроблемныйПользователь <> Неопределено Тогда
ОчиститьНастройкиПользователя(ПроблемныйПользователь);
Сообщить("Успешно очищены настройки для пользователя: " + ПроблемныйПользователь.Имя);
Иначе
Сообщить("Пользователь с таким уникальным идентификатором не найден в базе.");
EndIf;
Исключение
Сообщить("Произошла ошибка при обработке GUID: " + ОписаниеОшибки());
КонецПопытки;
После выполнения данного кода поврежденный файл настроек будет удален из таблицы Files, и при следующем входе пользователя в систему платформа создаст этот файл заново с корректными параметрами. Попробуйте запустить выгрузку в .dt — в большинстве случаев она пройдет успешно.
Если ваша информационная база работает в клиент-серверном варианте под управлением СУБД MS SQL Server или PostgreSQL, мы имеем возможность напрямую отредактировать поврежденные записи в таблице Files. Это наиболее профессиональный подход, позволяющий точечно устранить ошибку за секунды без сброса настроек других пользователей.
Внимание! Перед проведением любых манипуляций непосредственно в СУБД в обязательном порядке создайте резервную копию базы данных средствами самой СУБД (сделайте SQL-бэкап базы в файл .bak).
Запустим среду Microsoft SQL Server Management Studio (SSMS) и выполним подключение к нашему серверу баз данных. Рассмотрим два варианта SQL-скриптов для решения проблемы.
Вариант 1: Установка размера файла в 0 (как того ожидает платформа)
Мы принудительно изменяем значение в колонке размера, приводя его в соответствие с пустым бинарным полем:
UPDATE [Имя_Вашей_Базы_Данных].[dbo].[Files]
SET [DataSize] = 0
WHERE [FileName] = '0070d942-3a6c-43e2-a265-b76c6943d100.pfl';
Вариант 2: Полное удаление сбойной записи из таблицы
Этот вариант также является безопасным, поскольку при отсутствии записи настроек в СУБД платформа просто создаст их с нуля при следующем старте сеанса пользователя:
DELETE FROM [Имя_Вашей_Базы_Данных].[dbo].[Files]
WHERE [FileName] = '0070d942-3a6c-43e2-a265-b76c6943d100.pfl';
Если база развернута на СУБД PostgreSQL, мы используем утилиту pgAdmin или консольный клиент psql. Учитывая чувствительность PostgreSQL к регистру имен таблиц и полей, запрос на исправление будет выглядеть следующим образом:
UPDATE files
SET datasize = 0
WHERE filename = '0070d942-3a6c-43e2-a265-b76c6943d100.pfl';
После выполнения запроса обязательно перезапустите службу сервера «1С:Предприятие» (или конкретный рабочий процесс), чтобы сбросить кэш соединений и кэш метаданных сервера 1С. После этого запускайте Конфигуратор и выполняйте выгрузку.
Что делать, если база данных файловая (файл 1Cv8.1CD), программный метод очистки настроек не сработал, а разворачивать СУБД ради одной выгрузки слишком долго? В этой ситуации нам на помощь придет специализированный низкоуровневый инструмент — утилита Tool_1CD.
Сразу отметим важный нюанс: стандартные общедоступные версии утилиты Tool_1CD обычно работают только в режиме чтения. Для внесения изменений нам потребуется специальная версия с возможностью редактирования (например, альфа-версии 0.3.0/0.4.0 или версия 3.0 Beta).
Выполним процедуру исправления по шагам:
1Cv8.1CD в отдельную папку.Tool_1CD с поддержкой записи и откройте в ней файл вашей базы данных.FILENAME содержит имя проблемного файла настроек (например, 071523a4-516f-4fce-ba4b-0d11ab7a1893.pfl). Используйте встроенный поиск по таблице.Ctrl + E).DATASIZE для этой строки. Измените текущее некорректное числовое значение на 0 (как того требует система валидации платформы 1С).Ctrl + S) и закройте утилиту.Запустите Конфигуратор 1С и попробуйте выполнить выгрузку в .dt. База должна выгрузиться без единой ошибки.
Появление ошибок целостности служебных таблиц в файловых базах часто сигнализирует о том, что база данных близка к технологическому пределу стабильности файлового формата. В таблице Files со временем накапливается огромное количество конфигурационных данных и настроек. Чтобы минимизировать риск повторного возникновения подобных сбоев, мы рекомендуем выполнить оптимизацию структуры файла базы данных.
Начиная с платформы 8.3.8, разработчики 1С поставляют полезную консольную утилиту cnvdbfl.exe (она находится в каталоге установки платформы bin). Данная утилита позволяет изменить размер страницы данных файловой базы. По умолчанию размер страницы равен 4 Кб, но мы можем увеличить его до 64 Кб, что существенно повышает скорость работы с диском и стабильность базы данных.
Синтаксис команды для конвертации выглядит следующим образом:
cnvdbfl.exe -c -f 8.3.8 -p 64k "C:\Путь_К_Вашей_Базе\1Cv8.1CD"
Выполнение этой процедуры оптимизирует размещение бинарных данных в таблице Files и снизит вероятность повреждения файлов .pfl при непредвиденных сбоях работы сети или электропитания.
Подведем итоги. Ошибка целостности СУБД с файлами настроек пользователей больше не должна вызывать у вас панику. Мы детально разобрали причины проблемы и вооружились полным арсеналом методов лечения: от простого обновления платформы и точечного запуска скриптов очистки до прямого редактирования таблиц через SQL-запросы или утилиту Tool_1CD. Выбирайте наиболее подходящий для вашей ситуации способ, соблюдайте правила создания резервных копий перед началом работ, и ваши базы данных всегда будут находиться в исправном и работоспособном состоянии!